五分鐘學前端系統設計面試（二）- RADIO Framework 上

系列文第二篇文章會介紹如何系統性回答前端系統設計面試的問題

前端系統設計面試時，我們要把系統當成做一個產品來看待，RADIO框架由五個英文字所組成，分別是：

下面我們會逐點詳細展開，以及他們應所佔的面試時間比例

系統設計面試問題通常都是很廣泛、沒有標準答案的問題，因此面試者需要不斷問問題確認好需求的範圍，把你的面試官當成日常工作時的PM，把系統設計面試當成你日常要打造一個產品的感覺

不斷問問題除了可以幫助釐清需求範圍外，也可以確認面試官到底對這需求最有興趣的部分在哪裡，這部分需求也正是該花最多時間探討的，下面列出幾個常見你該問的問題：

這產品的主要使用情境是？

想像一下，你被要求”設計一個Facebook”，一個如此大的平台，包含了一堆功能，如：動態牆、個人主頁、朋友、群組、限時動態…，短短的面試時間內是不可能全部都回答到的，面試官其實心中有希望你回答的部分，但希望你問他我要回答什麼，俗稱的傲嬌（？

通常來說，要回答該產品最獨特的功能，例如Facebook可能就是動態牆、動態的分頁和建立新貼文；YouTube可能就是觀賞影片的體驗，系列文一的應用元件表格詳細列出了回答不同類型應用重要的部分

在本文我們會以"設計Facebook”來作為主要的例子，並套用RADIO Framework去回答它

功能性需求和非功能性需求分別是？

功能性需求（Functional requirements）：讓使用者可以完成一個核心的使用流程的最基本功能需求，俗稱的能動
非功能性需求（Non-functional requirements）：可以提升產品品質的功能，如效能（頁面載入、交互多快）、擴展性（能顯示多少物件）、更好的使用者體驗…，俗稱的動得好

顯而易見，我們應先達成所有功能性需求（能動），有多餘的時間才更去探討非功能性需求（動得好）

而有兩個你可以得到這問題答案的方法；

有哪些核心 features 和 good-to-have？

即使你定義好了功能性需求，但這需求仍包含一堆小features，舉例來說，建立一則Facebook貼文，要支援哪些貼文格式，除了最常見的文字外，使用者是否可以上傳圖片、影片、建立投票、打卡…，你應該先確認好核心features後，才去討論那些額外features

其他問題

上述問題是一些你可以視需要問的問題，但不是菜單不需要全問一輪，不同類型的問題往往還需要確認 domain-specific 的問題，在之後 case studies 的系列文會再介紹

確認好需求後，下一步是定義出產品的關鍵元件 & 這些元件間的關聯互動，記得要專注在 client-side 的架構，而不是 server-side

流程圖這時候很好用，每個元件可以表示為一個長方形盒子（如下圖），元件間的互動資料流用箭頭表示，元件裡面也可以有多個子元件，表示上為一個大長方形盒子裡面有許多小盒子

上圖為一個動態牆 high-level 前端架構設計的例子，分成幾個部分

Server：前端系統設計面試中，可以將其視為一個黑箱，並假設它有一些API可以call，透過 HTTP / WebSockets
View：使用者看到的部分，通常包含許多 subviews
Controller：回應使用者的互動，以及將 store / model 的資料處理成 View 預期的格式，如果產品比較小且元件間沒有太多的資料傳遞，這部分不一定需要
Model / Client Store：Data所在處，實務上一個應用內你可以包含多個 stores，stores 也可以包含其他 stores

以動態牆這例子來說，回答可以是這樣：

畫流程圖的工具推薦 diagrams.net 和 Excalidraw，筆者自己用的是前者

篇幅長度關係，剩下的 Data Model、Interface、Optimizations 留在下篇文章介紹

本篇文章中，我們介紹了前端系統設計面試中如何確認需求的範圍，以及如何定義 high-level 的架構

And that’s a wrap! Enjoy. 🎆

👏

Articles by Jordan