打造可規模化前端應用的 6 個原則

本篇最早收錄於《ExplainThis 全端雙週報》第 6 期

Vercel 現任 CTO (同時是前 Google 首席工程師) Malte Ubl 先前給了一個《Principles for Scaling Frontend Application Development》講座，談前端應用規模化的六個原則。

排除障礙 (Tear down the barriers)：

在規模化的過程中，會遇到多個團隊要共用元件的情境。過去可能用 NPM 來管理共用的元件，但這種方式不僅麻煩且難管理。Malte 的建議是採用 monorepo，可以讓共享的阻礙變低

讓刪除程式碼變簡單 (Make it easy to delete code)：

大型程式碼庫很長會變難以維護的原因在於，新接手的人不敢刪掉一些沒有在用的程式碼，因為擔心影響到其他有關連的程式碼。要緩解這問題，Malte 推薦盡可能用共置的形式，例如用 TailwindCSS 會把 CSS 跟元件寫一起，這樣要刪就能確保相關的東西會一併處理掉，不擔心刪了某個 CSS 結果影響到其他元件。

漸進式遷移 (Migrate incrementally)：

一次行大規模遷移往往容易導致遷移失敗，而且可能會遇到發現某個錯誤，整個大規模遷移都要回滾的問題。逐步的遷移可能會因為時間拉長而在過程中被質疑遷移成效，面對這狀況要儘早用範例來證明遷移是有價值的。

永遠變更好就不會變更差 (Always get better, never get worse)：

要維持程式碼的品質，可以引入一些工具，例如 Linting 工具。越早引入工具，會讓未來寫的新程式碼，越早被檢查，同時讓引入工具的價值提高。

擁抱缺乏知識 (Embrace lack of knowledge)：

新加入團隊的人，對於大型程式碼庫一定會缺少相關的背景脈絡，作為團隊領導人要做的是接受這個事實，並打造一個讓人即使有缺乏的背景知識，仍能做對事的系統。前一點提到的 Linting 工具就是一種方式，新加入的人不用有程式碼寫法的背景脈絡，但如果有不符團隊的寫法，系統中會有機制來自動提醒。

減少系統複雜度 (Eliminate systematic complexity)：

在 Google 這類的大廠很常會有版本偏差 (version skew) 的問題，例如後端做了某個改動，但前端還沒有更新相對應的改動，導致兩者之間有偏差。這種問題不是單一元件的問題，而是需要系統性的解決。舉例來說設計機制，確保前端永遠會請求到相對應版本的後端。