隨著項(xiàng)目功能越來(lái)越多竟痰，代碼量越來(lái)越龐大盘榨。隨之而來(lái)的就是項(xiàng)目本身變得有點(diǎn)難以維護(hù)和理解了郊愧。比如：
- 一開(kāi)始沒(méi)有定開(kāi)發(fā)規(guī)范朴译，每個(gè)人都有自己不同的寫(xiě)法沸伏。
- 創(chuàng)建和存放代碼文件的方式不同，導(dǎo)致目錄結(jié)構(gòu)開(kāi)始混亂动分。
- 為了適應(yīng)某些需求毅糟，寫(xiě)了一些臨時(shí)代碼。這種代碼一多后期維護(hù)就變得難以理解澜公。
- 頁(yè)面姆另、組件都有業(yè)務(wù)邏輯，到處是業(yè)務(wù)邏輯導(dǎo)致后期看代碼就像是捉迷藏坟乾。
- 頁(yè)面迹辐、組件之間耦合性太強(qiáng)。比如通過(guò)十幾個(gè) props 和十幾個(gè) event 來(lái)連接某個(gè)組件甚侣。
這些問(wèn)題在項(xiàng)目初期還好明吩。但是如果功能越堆越多。于是我就在想殷费，如何去維護(hù)好這個(gè)項(xiàng)目呢印荔。我想到了一句話(huà)：
高內(nèi)聚、低耦合
所以详羡，我對(duì)于我現(xiàn)在的 React 項(xiàng)目仍律，做了以下設(shè)計(jì)。
- assets 目錄里面放所有的資源文件实柠。雖然在某些頁(yè)面里面放上一些圖片資源引用起來(lái)很方便水泉，但是頁(yè)面一多就會(huì)發(fā)現(xiàn)有很多圖片是一樣的。這時(shí)候統(tǒng)一存放資源文件就可以復(fù)用一些文件窒盐。避免不必要的重復(fù)文件占空間草则。
- components 目錄里存放公共的組件。我對(duì)于組件的定義是盡量只實(shí)現(xiàn) UI 呈現(xiàn)方面的事情蟹漓，業(yè)務(wù)邏輯可以通過(guò)事件傳遞出去炕横，交給 page 和 module 來(lái)實(shí)現(xiàn)。
- pages 目錄里存放路由級(jí)別的頁(yè)面牧牢。
- 由于項(xiàng)目中使用了 redux看锉，所以每個(gè)頁(yè)面會(huì)有一個(gè) container 用來(lái)獲取 redux 數(shù)據(jù)和定義 dispatch 事件。
- index 里面承載了大部分頁(yè)面邏輯的處理塔鳍，以及頁(yè)面結(jié)構(gòu)的呈現(xiàn)伯铣。
- model 用于定義 redux state 以及數(shù)據(jù)操作方式。
- components 目錄用于存放僅僅在本頁(yè)面中會(huì)用到的組件轮纫。
- modules 目錄里面存放了非路由級(jí)別的功能模塊腔寡。它的目錄結(jié)構(gòu)和 pages 目錄完全一致。只不過(guò)這個(gè)目錄下的模塊不能被路由直接訪(fǎng)問(wèn)到掌唾。
- service 目錄用于配置和定義 API 接口放前。
- utils 用于定義公共工具函數(shù)忿磅。
并且，想了一些原則：
- 所有資源都要存放在同一 assets 目錄下凭语，方便復(fù)用和查找葱她。
- component 組件（不管是公共的還是頁(yè)面私有的）盡量不接觸業(yè)務(wù)，僅僅用于 UI 展現(xiàn)似扔。
- page 和 module 通過(guò) container 和 model 來(lái)連接 redux 數(shù)據(jù)吨些，通過(guò) index 來(lái)處理大多數(shù)頁(yè)面邏輯。
- 通過(guò) props 和回調(diào)函數(shù)傳遞數(shù)據(jù)盡量不要超過(guò)三層炒辉。如果一個(gè) prop 屬性會(huì)存在 A -> B -> C -> D -> E豪墅，并且回調(diào)函數(shù)是從 E 到 A 的，這必然不合理黔寇。
- 為了低耦合偶器，盡量少的使用 props 和 events。定義 events 的參數(shù)也是也少越好缝裤。
- page 不存在 props屏轰，module 盡量少定義 props，降低耦合性倘是。
- 一般只在 page 中使用 module亭枷，避免 module 中使用其他 module 形成套娃。
最后
以上都是我自己基于高內(nèi)聚搀崭、低耦合的一些項(xiàng)目?jī)?yōu)化的想法。我去網(wǎng)上找也沒(méi)有找到太適合我當(dāng)前項(xiàng)目的方案猾编。暫且一試瘤睹。
如果有更好的最佳實(shí)踐，歡迎留言交流溝通答倡。
