前端系統設計是什麼？前端系統設計的思考架構

本篇詳細解說本收錄在 E+ 的前端系統設計專題

過去兩篇前端系統設計主題內容，我們分別討論了前端系統設計 - 設計聊天系統 (Chat System)，以及前端系統設計 - 設計即時共編文件系統 (Collaborative Editor) 。這一篇我們將往後退一步，來聊聊前端的系統設計，有哪些應該要思考的點當能掌握這些思考點，未來面對不同的前端要設計，都能夠更有架構地思考與應對。

前端系統設計是什麼?

一般提到系統設計，多數人可能第一時間會想到軟體工程師面試常見的系統設計，這類系統設計會需要針對某個場景 (例如設計短網址服務、設計臉書的動態牆、設計 YouTube)，去設計可擴展、高可用、高效能的分散式系統。在這類系統設計中，具體會牽涉到我們在系統設計五大心法：水平擴張、快取、非同步、避免單點故障、監控一文談到的水平擴張、快取、非同步、避免單點故障、監控等概念。

而這類面試通常會是通用軟體工程師 (general software engineer)，或者後端工程師、全端工程師，相對比較常會遇到。而對於前端工程師，則是更常會遇到前端系統設計。

前端系統設計某部分與上述的軟體工程系統設計重疊，問的問題也是類似 (例如設計臉書動態牆、設計 YouTube)，但又有其獨特的部分。舉例來說，前端的架構、前端的技術取捨，以及前端要特別側重的前端效能、使用體驗、無障礙 (a11y)、國際化 (i18n)，這些對前端工程師重要，但一般通用系統設計不會問到的問題。

關於前端要側重的面向，非常推薦 React 核心團隊 Dan Abramov 之前寫的《The Elements of UI Engineering》一文，該文詳盡地解析了重點面向。

前端系統設計的思考架構

在了解完側重點後，接著來聊如何展開前端的系統設計。不論是在實際工作上，或者是在面試，能夠主動去引導並完成前端系統設計，是邁向資深不可或缺的。

目前業界比較多使用的前端系統設計框架是由 GreatFrontEnd 作者提出的 RADIO 框架，該思考架構如下

Requirement 需求探索
Architecture 架構建立
Data 資料模型
Interface 接口定義
Optimization 深入優化

需求探索

如同後端系統設計，前端系統設計也推薦從需求探索開始，根據不同的問題，要去釐清任何不清楚的地方。比較推薦的做法，是戴上產品經理的帽子，試著從產品經理的角度去思考。

前端系統設計在問釐清問題時，會分為功能需求與非功能需求。以動態牆為例，功能需求會包含動態牆具體要有的元素，例如動態是純文字或支援多媒體，或者是純展示或會支援留言與按讚。

而非功能需求則是即使沒做，產品還是能用，只是可能體驗不會是最好。以動態牆來說，非功能需求可能包含無限滾動 (infinite scrolling) 、虛擬化展示 (virtualization)，或者要不要支援離線瀏覽。

在這個階段，是在檢驗你「是否能有效面對模糊情境」。在實際工作上，很多時候產品經理的思考會需要工程端的協助，來考慮更全面，這時需要工程端協助釐清問題，或者更深入去想執行細節要考量的面向。理想上，在跟產品經理過需求時，前端工程師要詳讀需求，然後把任何不夠具體、不夠清楚的地方，都留言提問。

而在面試，面試官則會刻意不在一開始就給所有資訊，因為會想測驗候選人是否會主動去釐清。因此在遇到要設計的系統時，這個步驟千萬不能省略！

總結來說，在需求探索，請務必確保自己有做到

能對要解決的問題有清楚的理解，任何模糊不清的地方都會追問
功能與非功能需求，都需要涵蓋到
有進一步收斂什麼是最重要的問題 (確保接下來的討論都能在核心上)

架構建立

在釐清完需求後，接著要做的，會是根據需求提出前端設計。而要能夠有效溝通，在最開始推薦先從架構面著手。所謂的架構，就是要展開一個系統中所需要的元素、各個元素扮演什角色，以及各元素彼此如何交互，以讓系統能完整運行。

從前端的角度來看，常見的架構包含 MVC，Model 是存放資料的地方，View 是展示的地方，而 Controller 是控制邏輯的地方。而除了前端的 MVC 彼此的互動外，還需要有跟後端伺服器的交互 (例如常見的 HTTP 或者 WebSocket)。

或者是單一資料流的 Flux 架構，Flux 架構有存放資料的 Store，以及展示 UI 的 View，透過在畫面上的操作，會由 Dispatcher 發送 Action 來改動資料存放的 Store，而 View 在根據更新後的 Store 來展示新的內容。

不論是 MVC 或 Flux 或其他常見的架構，沒有哪個絕對比其他架構好。需要在了解完需求後，根據需求提出最合適的架構方式。

更進一步說，如果要讓架構完整，就會需要去考量更廣的元素，例如前端要做監控，如果有任何 JavaScript 錯誤，或者畫面變成白屏，會需要第一時間觸發監控的警告，而這就需要有前端監控的元素在架構圖中。

又或者有些前端的控制，不想要寫死在前端的應用中，希望用配置的方式 (config-driven)，那就會需要有一個鍵值的外部機制 (key-value store) 能夠輕鬆地去操作 (例如社群中許多人用的 LaunchDarkly )。

架構圖要廣可以到很廣，像是現代許多前端開發也都會導入 A/B 測試，或者是使用者行為資料的蒐集 (例如 Google Analytics)，都可能是前端架構圖中的一個元素。至於究竟要包含到什麼元素，就需要在最開始去釐清，這也是為什麼說需求釐清是非常非常重要的。

特別注意，工作時開發新產品，可以先就大方向進行討論，確保整體邏輯通順後，再往下進行深入討論 (詳後面會提到的深入優化)。如果是在面試中，可以先跟面試官討論要展開到什麼程度，然後再把完整的架構圖畫出來。

總結來說，在架構建立，請務必確保自己有做到

有針對上一步驟的需求，提出相對應的解決方案
提出的架構，能完整呼應需求，該有的要素都需要有
架構有考量到未來的擴展，能以複用、最小改動方式來支援新需求

本文為 E+ 成長計畫的深度內容，截取前三分之一開放免費閱讀。歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)