聊聊代碼目錄結構
本文寫於 2020 年 11 月 20 日
為什么需要糾結目錄結構
好的代碼結構最重要的目的，就是讓人看着舒服。
如果不需要人看的舒服，對代碼結構、目錄結構的思考根本沒有任何必要。但代碼是給人看的，我們讀代碼需要一個好的結構才能讓我們更好的在腦子里對項目進行拆解和組裝。
例如一個 1000 行的代碼文件，和 5 個 200 行的互相關聯的代碼文件，你覺得誰更好理解呢？
因此我們要做的，就是讓項目的目錄結構變得像瑞士軍刀一樣，清晰明了。
好的結構是怎么樣的？
牆裂推薦《Unix 編程藝術》，里面講述了很多工程師編寫代碼的寶貴經驗，例如：功能單一原則。
如果我們已有代碼實現了 A 功能，那么當需要添加 B 功能時請重新寫新的代碼，而不是在 A 的代碼中“添磚加瓦”。
我認為，好的目錄結構應該有三條：
- 好的結構應該保持單一職責；
- 好的結構應該是通用的；
- 好的結構應該是有明確定義的。
util 目錄
util 是工具的意思，該目錄可以用來放一些公共的工具函數、工具類。
當代碼的私有方法越多時，代碼就會顯得越亂，更有可能出現功能重復的不同函數。這時候就應該進行整理，抽離出公共的函數，放入 util 中。
util 是最好做單元測試的目錄，因為里面的函數、方法、類都是有明確的輸入和輸出的。
service 目錄
service 是服務的意思，用來提供一個服務，該服務可能包括數據處理、發送請求，或是調用別的服務。
和 util 的區別在於，service 會包含有項目邏輯，而 util 中的代碼往往是所有項目都通用的。
不是所有的功能都能抽離成為一個 service，service 需要相對獨立，是一個獨立的功能模塊。例如：身份驗證、文件儲存、請求數據……
controller 目錄
controller 是控制器的意思。所有的指令、調度都從這里發出，哪一個 service 做什么事情，獲得的數據提供給誰，都是 controller 來實現。
這里最容易產生臟代碼，所以需要時常清理，將公用的代碼邏輯提升到 util 或者 service 中去。
但是對於前端來說，一般也不存在這個目錄，因為我們的邏輯一般都是由用戶觸發的。
model 目錄
model 是模型的意思。該目錄承載的功能就是負責數據的抽象，即描述一個個數據的定義。
在前端項目中，這個目錄幾乎不會出現。
model 應該是一個純數據的集合，通常項目會有很多 model，一條業務流就是對應一條或者多條數據流。
拿知乎為例：
- 文章是一個 Model，一般叫 Article，包括 Title，Summary，Author，Content 等等；
- 評論也是一個 Model，一般叫 Comment，包括 Content，userID 等等。
dao 目錄
這個目錄前端真的不會用，因為這是用來存放和底層數據庫通信代碼的目錄，負責對數據庫增刪改查。其中不含判斷邏輯，dao 只關心增刪改查，而不在乎是否存入正確的數據。
service 會和 dao 相對應，有人認為一個 service 對應一個 dao 為最佳——service 檢查數據，dao 存取數據。
但是從本質上來說，dao 並不需要和數據庫有什么必然的聯系，他只是 data access object 的縮寫。所以，只要是需要持久化數據，並包裝成一個對象，這個對象都可以稱之為 dao。
views / components 目錄
這是前端會有的兩個目錄，分別用來存放頁面與組件。
通常我傾向於在 components 中再進行分類：
- 一類以頁面名字分類，里面存放該頁面的獨立組件；
- 公共組件直接放在 components 目錄中，如果是一系列的組件，例如 modal 模態窗、button 按鈕，就存放於 uikit 目錄中。
assets 目錄
用於存放各種素材，png、jpg、svg 圖片等等。
如果一個素材圖片是一個組件獨有的，那么建議和該組件放在一個目錄中。
擁有這些結構就是一個好的項目嗎？
項目中是否包含這些目錄或者模塊，和項目結構是否完善根本沒有關系！！！
但是當你的項目結構相對完善的時候，你就會發現有他們的存在。不要弄反了！
目錄結構就是項目架構么？
是，但是只是一點點。項目架構還涉及到 service 的具體設計，互相之間如何調用、解耦……等等等很多東西。良好的目錄結構只是皮毛中的皮毛罷了。
但這是第一步，養成好習慣，理解設計的本來目的，而不是不停的模仿。持之以恆，才是進步。
參考文獻：
https://www.zhihu.com/question/58410621/answer/156868800
https://www.zhihu.com/question/58410621
（完）