Java進階編程-React 項目的架構和規範

標籤：基礎上   部分   開發人員   術語   常量   redux   項目   部署   需要   

架構和規範
架構是為瞭解決什麼問題呢？我理解是效率問題。通過一個好的架構，能讓你很容易地、具備一致性地理解一個系統，在此基礎上快速地、可持續地完成業務功能。它保證的有三點：

程式碼程式庫閱讀起來很輕鬆
添加新功能時能很快，理想情況是，僅添加跟業務有關的代碼，跟樣式、基礎設施相關的東西，在一個較為成熟的項目上，應該都比較穩定了
在演化過程中，仍然能保持添加功能的速度很快
規範是為瞭解決什麼問題呢？我理解是協作問題。大家一個團隊工作，命名習慣不同，代碼風格不同，水平參差不同，如何保證整體品質和風格面貌？靠規範唄。

那麼架構和規範分別有什麼例子呢？

架構
比如目錄結構、組件層次、狀態管理、副作用管理、路由系統、UX 系統（樣式方案）、埋點設計、測試策略、持續整合、構建方式、部署方式等屬此列。可以看到，為了開發一個業務功能，底下可能需要這麼多基礎設施支撐。而架構的目的，就是把儘可能的操作（比如路由、埋點、UX 一致性等）變成常量層級的操作、甚至預設標配的操作，這樣才能讓你開發起來順暢，做到只關心業務的部分。

目錄結構：這個問題與組件層次問題息息相關。在 APP 的情境下，它與 web 又不太一樣，APP 往往是首頁路由+卡片式堆疊頁面。怎麼將頁面結構映射到目錄結構上，怎麼保持清晰？是遵循 duck 目錄結構設計方式，還是功能式目錄結構方式？如果小型項目選擇從功能式開始，後續是否有向 duck 結構的遷移路徑？需要多少人力？
組件層次：是按照 container component -> presentation component 的結構劃分？還是不 care？
狀態管理：React Context、mobx、redux，如何選擇？
副作用管理：promise 方案？thunk 方案？saga 方案？
類型系統：TS。語言層級的類型系統所帶來的架構抽象能力
路由系統：怎麼做到讓頁面增刪變成常量層級的操作？怎麼支援多種不同的渲染模式（不卸載/卸載）？
UX 系統：怎麼做到跟 UX 設計保持高度一致？怎麼保證只需要常數層級的操作就可以達到這種一致性？如何保證只需要常數層級的操作就可以變更、嘗試新的 UX 設計？
埋點設計：資料乃產品之本，怎麼設計埋點系統，讓它對業務代碼的侵入性達到最小？怎麼保持細粒度埋點的靈活性？如何做到讓埋點變成常量層級的操作？埋點資料結構如何設計？統計如何統計？要產生什麼報表？報表的產生如何做到常量層級的操作（即不需要人工執行指令碼去統計）？
測試策略：測哪些？測什嗎？測多細？由誰測？需要制定可落地的測試策略
持續整合：開發方式（分支 or 主幹）？自動化測試分別在什麼階段運行？如何讓持續整合的配置變成常數層級（而不需要每次換機器都要手動重新搭 CI）？
構建方式：用什麼工具進行自動化構建？
持續部署：部署目的地？部署頻率？是否能做到每次提交都進行部署？是否能準備與生產環境儘可能接近的 UAT 環境？
規範
比如代碼風格、編程風格、命名風格、提交資訊、提交粒度、開發習慣、代碼整潔程度、單元測試好壞等屬此列。

代碼風格：Prettier 一鍵解決
編程風格：Eslint 盡量覆蓋
命名風格：明確基本原則後，寫入 README 做憲法 + 術語表
提交資訊：precommit hook，但沒法規範到資訊層級，而提交資訊是跟提交粒度息息相關的
提交粒度：較難以統一的部分。我還是把它放到架構部分去吧
開發習慣：自暴自棄的部分。比如 TDD 等
代碼整潔程度：基本只能用 code review + PR 來規範。這跟開發人員是謀生心態還是工匠心態有關，跟組織是技術屬性的組織還是政治屬性的組織也有關係
單元測試好壞：明確好測試的標準後，制定測試策略 + 寫入 README 做憲法 + code review 經常反饋
其他的歡迎補充。

Java進階編程-React 項目的架構和規範