隨著項目功能越來越多，代碼量越來越龐大。隨之而來的就是項目本身變得有點難以維護和理解了。比如：

• 一開始沒有定開發(fā)規(guī)范，每個人都有自己不同的寫法。
• 創(chuàng)建和存放代碼文件的方式不同，導(dǎo)致目錄結(jié)構(gòu)開始混亂。
• 為了適應(yīng)某些需求，寫了一些臨時代碼。這種代碼一多后期維護就變得難以理解。
• 頁面、組件都有業(yè)務(wù)邏輯，到處是業(yè)務(wù)邏輯導(dǎo)致后期看代碼就像是捉迷藏。
• 頁面、組件之間耦合性太強。比如通過十幾個 props 和十幾個 event 來連接某個組件。

這些問題在項目初期還好。但是如果功能越堆越多。于是我就在想，如何去維護好這個項目呢。我想到了一句話：

高內(nèi)聚、低耦合

所以，我對于我現(xiàn)在的 React 項目，做了以下設(shè)計。

• assets 目錄里面放所有的資源文件。雖然在某些頁面里面放上一些圖片資源引用起來很方便，但是頁面一多就會發(fā)現(xiàn)有很多圖片是一樣的。這時候統(tǒng)一存放資源文件就可以復(fù)用一些文件。避免不必要的重復(fù)文件占空間。
• components 目錄里存放公共的組件。我對于組件的定義是盡量只實現(xiàn) UI 呈現(xiàn)方面的事情，業(yè)務(wù)邏輯可以通過事件傳遞出去，交給 page 和 module 來實現(xiàn)。
• pages 目錄里存放路由級別的頁面。
  • 由于項目中使用了 redux，所以每個頁面會有一個 container 用來獲取 redux 數(shù)據(jù)和定義 dispatch 事件。
  • index 里面承載了大部分頁面邏輯的處理，以及頁面結(jié)構(gòu)的呈現(xiàn)。
  • model 用于定義 redux state 以及數(shù)據(jù)操作方式。
  • components 目錄用于存放僅僅在本頁面中會用到的組件。
• modules 目錄里面存放了非路由級別的功能模塊。它的目錄結(jié)構(gòu)和 pages 目錄完全一致。只不過這個目錄下的模塊不能被路由直接訪問到。
• service 目錄用于配置和定義 API 接口。
• utils 用于定義公共工具函數(shù)。

并且，想了一些原則：

• 所有資源都要存放在同一 assets 目錄下，方便復(fù)用和查找。
• component 組件（不管是公共的還是頁面私有的）盡量不接觸業(yè)務(wù)，僅僅用于 UI 展現(xiàn)。
• page 和 module 通過 container 和 model 來連接 redux 數(shù)據(jù)，通過 index 來處理大多數(shù)頁面邏輯。
• 通過 props 和回調(diào)函數(shù)傳遞數(shù)據(jù)盡量不要超過三層。如果一個 prop 屬性會存在 A -> B -> C -> D -> E，并且回調(diào)函數(shù)是從 E 到 A 的，這必然不合理。
• 為了低耦合，盡量少的使用 props 和 events。定義 events 的參數(shù)也是也少越好。
• page 不存在 props，module 盡量少定義 props，降低耦合性。
• 一般只在 page 中使用 module，避免 module 中使用其他 module 形成套娃。

最后

以上都是我自己基于高內(nèi)聚、低耦合的一些項目優(yōu)化的想法。我去網(wǎng)上找也沒有找到太適合我當前項目的方案。暫且一試。
如果有更好的最佳實踐，歡迎留言交流溝通。