Java高級編程-React 項目的架構和規範
架構是為了解決什麽問題呢？我理解是效率問題。通過一個好的架構，能讓你很容易地、具備一致性地理解一個系統，在此基礎上快速地、可持續地完成業務功能。它保證的有三點：
代碼庫閱讀起來很輕松
添加新功能時能很快，理想情況是，僅添加跟業務有關的代碼，跟樣式、基礎設施相關的東西，在一個較為成熟的項目上，應該都比較穩定了
在演進過程中，仍然能保持添加功能的速度很快
規範是為了解決什麽問題呢？我理解是協作問題。大家一個團隊工作，命名習慣不同，代碼風格不同，水平參差不同，如何保證整體質量和風格面貌？靠規範唄。
那麽架構和規範分別有什麽例子呢？
架構
比如目錄結構、組件層次、狀態管理、副作用管理、路由系統、UX 系統（樣式方案）、埋點設計、測試策略、持續集成、構建方式、部署方式等屬此列。可以看到，為了開發一個業務功能，底下可能需要這麽多基礎設施支撐。而架構的目的，就是把盡可能的操作（比如路由、埋點、UX 一致性等）變成常量級別的操作、甚至默認標配的操作，這樣才能讓你開發起來順暢，做到只關心業務的部分。
目錄結構：這個問題與組件層次問題息息相關。在 APP 的場景下，它與 web 又不太一樣，APP 往往是首頁路由+卡片式堆疊頁面。怎麽將頁面結構映射到目錄結構上，怎麽保持清晰？是遵循 duck 目錄結構設計方式，還是功能式目錄結構方式？如果小型項目選擇從功能式開始，後續是否有向 duck 結構的遷移路徑？需要多少人力？
組件層次：是按照 container component -> presentation component 的結構劃分？還是不 care？
狀態管理：React Context、mobx、redux，如何選擇？
副作用管理：promise 方案？thunk 方案？saga 方案？
路由系統：怎麽做到讓頁面增刪變成常量級別的操作？怎麽支持多種不同的渲染模式（不卸載/卸載）？
UX 系統：怎麽做到跟 UX 設計保持高度一致？怎麽保證只需要常數級別的操作就可以達到這種一致性？如何保證只需要常數級別的操作就可以變更、嘗試新的 UX 設計？
埋點設計：數據乃產品之本，怎麽設計埋點系統，讓它對業務代碼的侵入性達到最小？怎麽保持細粒度埋點的靈活性？如何做到讓埋點變成常量級別的操作？埋點數據結構如何設計？統計如何統計？要生成什麽報表？報表的生成如何做到常量級別的操作（即不需要人工執行腳本去統計）？
測試策略：測哪些？測什麽？測多細？由誰測？需要制定可落地的測試策略
構建方式：用什麽工具進行自動化構建？
持續部署：部署目的地？部署頻率？是否能做到每次提交都進行部署？是否能準備與生產環境盡可能接近的 UAT 環境？
規範
比如代碼風格、編程風格、命名風格、提交信息、提交粒度、開發習慣、代碼整潔程度、單元測試好壞等屬此列。
代碼風格：Prettier 一鍵解決
編程風格：Eslint 盡量覆蓋
命名風格：明確基本原則後，寫入 README 做憲法 + 術語表
提交信息：precommit hook，但沒法規範到信息級別，而提交信息是跟提交粒度息息相關的
提交粒度：較難以統一的部分。我還是把它放到架構部分去吧
開發習慣：自暴自棄的部分。比如 TDD 等
代碼整潔程度：基本只能用 code review + PR 來規範。這跟開發者是謀生心態還是工匠心態有關，跟組織是技術屬性的組織還是政治屬性的組織也有關系
單元測試好壞：明確好測試的標準後，制定測試策略 + 寫入 README 做憲法 + code review 經常反饋
其他的歡迎補充。
Java高級編程-React 項目的架構和規範