第3章 架構基礎：工作流設計

前端基礎架構是一系列工具與流程的集合，它是我們在啟動一個項目時所需要制定的一系列規范和規劃。每當我們啟動一個新的項目，所要做的事情會很多。

在ThoughtWorks，我們稱這個時間段為Iteration 0，即I0或者迭代0。不同的時期，我們對于項目啟動會有不同的看法。以筆者為例：

1.0時期，迭代0就是選定一個前端框架。剛工作時，這段時間所要做的事情，就是從眾多前端框架中選一個。選定框架本身就是一件麻煩的事，要進行一堆細致的分析才能決定使用哪一個。如果組織內沒有規定好框架，那么選擇框架便相當復雜。當筆者真正去啟動一個前端項目的時候，發現迭代0并不是選一個框架、寫一個“Hello, world”那么簡單，還需要搭建一個持續集成環境。在搭建持續集成環境的過程中，仍需要編寫前端應用所需要的構建腳本。于是，迭代0所做的事情就變得更復雜。

2.0時期，迭代0應該是選定前端框架+完整的構建腳本和構建系統。在筆者隨后經歷的項目中，這個模式很好。原因是在這些項目里，筆者只是負責一個小團隊的架構。當需要負責一個更大的項目、更大的團隊時，需要從組織的層面去考慮這個問題。對于一個大的前端項目，其前端架構要讓所有的團隊都可以一起構建這個應用，但相應的代碼不能在同一個代碼庫里。此外，還有一個麻煩的問題就是規范化。在小的團隊里，規范可以口頭約定，而在大的團隊里，規范一定是可以自動化的。

3.0時期，迭代0應該是選定前端框架+完整的構建腳本和構建系統+流程規范化。在筆者接觸一些更大規模的團隊時，發現在團隊里要做的事情就更多了。從組織本身的安全和能力提升出發，我們應該開發自己的前端開發框架。從用戶體驗和開發人員的便利性上看，我們應該做出自己的前端Design System。為了降低開發成本，我們還需要擁有一些前端應用腳手架、自己的開發工具或者協作工具。于是，工作的重心便從業務轉向了構建工具。

這樣仔細一看發現：哦，這是和團隊規模密切相關的啊。為了保障團隊能順利合作開發，我們需要制定一系列的開發流程，并創建相應的開發規范。

技術在不斷演進，幫助我們不斷地提高生產力、使流程規范化。過去我們手動下載依賴，現在可以一鍵安裝依賴；過去需要單獨進行測試，現在可以在提交代碼后自動測試。隨著我們不斷地優化開發流程，這些工作越來越自動化。

原先，我們只是出臺一系列規范，期盼團隊中的成員能遵循，然而規范在這個時候只是規范而已。現在規范被硬編碼到流程中，一系列的操作都由程序來進行檢測——使用Lint工具對代碼風格進行檢驗，使用測試覆蓋率檢測測試是否測試過等。這些流程旨在通過規范代碼來提升代碼的可閱讀性，減少代碼中可能出現的bug。

當然，硬規范有好的方面也有不好的方面。好的方面是，它可以產出更規范的代碼；不好的方面是，它讓我們千篇一律。至于使用哪種方式，具體還要看情況——從兩個方案中選擇時，我們往往是從兩個不好的中選出一個較好的。

這些流程與規范，就是我們要在本章中討論的內容。