代碼結構及一些代碼規範建議

一些感悟

• 代碼結構和規範關係到項目的可持續維護以及維護的周期，非常重要，但真正重視並落地的很少

• 經典的MVC模式一般都能說出來，但真正落地到項目代碼結構的時候，卻缺少思考

• 當寫代碼和找代碼讓人感覺彆扭的時候，就該考慮如何去優化了

• 一切皆對象，在規劃代碼結構的時候也需要有面向對象的思維方式

• 很多張口就是高並發、大數據、高流量等之類高大上辭彙的人，缺很少注重代碼的基礎結構，寫出的代碼很難讓人輕易上手

• 如果代碼結構和規範做得好一點，一般項目有一兩個頂樑柱再加一些新手就完全可以搞定。這樣既可以節省人力成本，也可以快速培養新人，新加入的成員也能快速融入

以下是整理的一般類型的項目代碼結構，僅供參考。部分模塊是使用spring boot開發項目的命名，但總體結構思路是一樣的，如果不使用spring boot開發項目，只是修改一下名字即可

建議的包結構及簡單說明

說明

• 此代碼結構是使用spring boot、spring cloud作為主要開發技術。如果不使用spring boot + spring cloud，大體結構類似，比如：maven模塊的劃分、model/view/controller對應包的劃分

• model模塊可以使用工具根據資料庫表結構自動生成對應的文件

• 代碼結構中的介面是http形式的介面，如果是rpc方式，api模塊做對應調整即可

代碼規範和結構的幾點建議

• service不需要介面，直接寫java對象，區別在於spring會使用cglib作為代理的生成方式（如果是寫介面和實現類，會使用jdk代理）。理由：在應用內部的各層次（controller、service、dao）之間進行調用，每次修改都是在應用內修改，不存在介面的調用方和實現方單獨升級的情況，如果同時去修改介面和實現類，顯得很多餘；如果是應用之間的調用，必須定義介面。（個人認為原因可能是所謂的面向介面編程被過度理解和使用。應用內如果有一些複雜的業務邏輯，可適當考慮使用介面+多實現的方式，如遇這些情況，多參考設計模式的一些思想）

• 如果service需要寫介面，介面以I開頭，實現類以介面名去掉I命名。有的實現類會以impl結尾，個人認為沒有必要。理由：impl表示的是類的層次結構，這個在包名上已經體現出來，並且類名應該主要體現實現的業務（見名知義），再有service的類名已經以service結尾，體現出了分層的意義，沒有必要在命名上重複體現

• mybatis的mapper建議使用sqlid的方式調用，這樣能提高mapper.xml內代碼的重用性；如果用定義介面與mapper.xml的id對應的方式，只能一一對應，不方便公用。比如User對象的查詢功能：

使用sqlid調用方式的話，dao中的查詢可以公用同一個sqlid：

如果使用寫介面與mapper對應的方式，mapper.xml則需要寫三個select，或者通過傳入參數進行判斷處理，返回值也根據使用情況需要處理

• 關於使用eureka註冊中心，個人認為只是在原有web應用之前加了一層控制，而不應該因此將原web應用的controller寫成service，因為原web應用雖然是相當於提供服務給eureka調用，但畢竟也是通過一般web應用的http方式調用的，兩者是獨立存在的，不應該因此把類名稱耦合起來，更不應該在兩者之間定義介面來將兩者耦合在一起

• 減少事務開啟時間，建議盡量將接收到的參數的判斷、對象的初始化、vo與po的轉換等放到事務開啟之前，因為service只是調用不同dao或公用service對數據的操作來組合成controller需要的業務，並做事務控制，所以service應該只接收自己需要的並且正確的數據對象

• 方法名去掉冗餘的部分，java定義方法簽名是方法名+參數，只要根據方法簽名能夠知道其意思即可，如：

可以改為

• 寫工具類或封裝的時候考慮級聯操作，即對對象屬性的操作方法返回當前對象，如下是自己封裝的controller統一使用的返回對象

使用的時候可以這樣：

以上，純屬個人觀點，但也基本都是經過實踐後認為還不錯的一些方式

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！