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

2024年9月29日

💎 加入 E+ 成長計畫 與超過 400+ 位軟體工程師一同在社群中成長,並且獲得更多的軟體工程學習資源

本篇詳細解說本收錄在 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+ 的詳細介紹)

🧵 如果你想收到最即時的內容更新,可以在 FacebookInstagram 上追蹤我們