ExplainThis 全端開發雙週報 #37
前端系統設計的思考架構
嗨～ 歡迎閱讀 ExplainThis 全端開發雙週報。這期的主題是《前端系統設計的思考架構》。
一般提到系統設計，多數人可能第一時間會想到軟體工程師面試常見的系統設計，這類系統設計會需要針對某個場景 (例如設計短網址服務)，去設計可擴展、高可用、高效能的分散式系統。在這類系統設計中，具體會牽涉到我們在 系統設計五大心法：水平擴張、快取、非同步、避免單點故障、監控 一文談到的概念。
而這類面試通常會是通用軟體工程師 (general software engineer)，或者後端工程師、全端工程師，相對比較常會遇到。而對於前端工程師，以及部分全端工程師，則更常會遇到前端系統設計。
前端系統設計某部分與上述的軟體工程系統設計重疊，問的問題也是類似 (例如設計臉書動態牆、設計 YouTube)，但又有其獨特的部分，因此這期主題文，我們會來談如何有架構地做好前端系統設計。
在進入主題文前有個小更新，上一期雙週報我們提到 ExplainThis 正在製作一本海外求職指南，在經過一個月的撰寫，我們在這週完成了這本有 80 頁內容的手冊，詳盡完整地談如何有效準備海外求職。只要是 E+ 的訂閱讀者，都可以免費取得，詳細可以在 E+ 的 Discord 最新消息頻道看到 (E+ 介紹可以看這邊)。
前端系統設計的思考架構
如果你的目標是成為資深前端或資深全端工程師，不論是在實際工作上，或者是在面試，能夠主動去引導並完成前端系統設計，是不可或缺的。
目前業界比較多使用的前端系統設計框架是 RADIO 框架，該架構是由前 Meta 主任工程師，同時是 GreatFrontEnd 的創辦人 Yangshun 所提出的 (連結)。
該思考架構如下：
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)，都可能是前端架構圖中的一個元素。至於究竟要包含到什麼元素，就需要在最開始去釐清，這也是為什麼說需求釐清是非常非常重要的。
特別注意，工作時開發新產品，可以先就大方向進行討論，確保整體邏輯通順後，再往下進行深入討論 (詳後面會提到的深入優化)。如果是在面試中，可以先跟面試官討論要展開到什麼程度，然後再把完整的架構圖畫出來。
總結來說，在架構建立，請務必確保自己有做到：
有針對上一步驟的需求，提出相對應的解決方案
提出的架構，能完整呼應需求，該有的要素都需要有
架構有考量到未來的擴展，能以複用、最小改動方式來支援新需求
由於雙週報的內容篇幅有限，關於 RADIO 架構的後半部，我們在 E+ 有寫一篇完整的內容，有興趣的讀者可以在 E+ 看到。同時也推薦可以在 GreatFrontEnd 看到啟發這篇文章的英文版本 (連結)。
[本期推薦]
GitHub 的共同創辦人 Scott Chacon 最近寫了《Why GitHub Actually Won》 一文 (連結)，其中談到當年市場有更大更有錢與資源的 Google Code，但為何最終 Google 關掉 Google Code 而 GitHub 成為市場中的贏家? 這個提醒了，當你對某件事有觀點，即使科技巨頭也在做，不代表你做的就會被擊垮
過去兩年裁員潮，讓很多初階工程師找工作比較艱辛，因為多數公司想找資深的即戰力，但《Your company needs Junior devs》一文談到團隊中有初階工程師的好處，同時談到資深工程師該抱持什麼觀點來與初階工程師互動 (連結)
由於軟體開發不免會有線上事故，軟體工程師該如何做好事故檢討，是團隊中的資深工程師要面對的課題之一，先前我們寫了一篇文討論了這個議題 (連結)
Cloudflare 最近有一篇《Our container platform is in production. It has GPUs. Here’s an early look》文，談了他們開發的容器平台，包含談了架構，以及如何解決一些技術問題，寫得很精彩 (連結)
歐洲在 AI 發展的創新受法規影響，在過去幾個月一直有不小的討論。先前我們在海外求職工作坊有談到，如果想去歐洲區工作的讀者，可能要多思考這個面向。而最近這個問題似乎更顯嚴重 (連結)
DHH 最近的一場訪談，談的許多觀點發人省思，推薦一看 (連結)。同時他在 Ruby on Rails 的會議中給的主題演講，有他一慣的辛辣觀點 (連結)
最近看到一個叫 Effect 的開源專案 (連結)，這是一個協助讓你能夠更容易能寫出好維護的 TypeScript 的套件，有在寫 TypeScript 的讀者，很推薦一試
JavaScript 的 Promise 一直是許多人沒有徹底搞懂的概念，Josh Comeau 寫了一篇非常生動的《# Promises From The Ground Up》解說了 Promise 的概念 (連結)