寫代碼就像寫文章, 好的代碼就像好的文章,結構嚴謹,構思清晰。寫代碼就像寫文章, 一不留神就成流水賬，為避免這種情況作為軟件開發工程師，重要的是設計而不是實現。
在一個團隊中,由於不同經驗的開發導致編程風格可能會出現非常混亂的情況,從而導致開發成本上升。難以維護。所以代碼規範就顯得異常重要了。
本篇文章就是給出編程命名的建議,僅供參考,但是其目的是為了統一規範,提高編程能力,降低開發成本,減少代碼維護成本。
契約精神: 做到有法可依，有章可循。
一、類命名1. 抽象類適用的設計模式為模板模式。抽象是自下往上的設計。由具體實現推斷出抽象方法。建議以Abstract開頭。
2. 枚舉類- 枚舉是由JVM來保證的單例。可以用來做單例類。
- 枚舉類長用作值判斷,不建議每次進行循環判斷得到實例。建議由內部維護一個map類型,當做cache。此方法建議放在static靜態代碼塊中實現
public enumProtocolEnum {
/**
* ECHO協議
*/
ECHO(1, null),
/**
* mojito協議
*/
MOJITO(2, MojitoProtocol.class);
privatebyte type;
privateClassextends
private staticMap<Byte, ProtocolEnum> cache = newHashMap<>();
static {
for(ProtocolEnum protocolEnum : values()) {
cache.put(protocolEnum.type, protocolEnum);
}
}
public staticProtocolEnum byType(byte type) {
returncache.get(type);
}
}
3. 工具類
工具類常為無狀態對象,無狀態對象都是線程安全對象,建議使用 final 修飾。
工具類中避免出現業務屬性, 如果出現業務屬性,抽象出領域層
4. 異常類建議保持異常鏈。
5. 接口實現類眾所周知
6. 設計模式相關類
其主要的目的是代碼可重複使用。
8. 測試類參考於網絡。
1. 布爾判斷方法注：Prefix-前綴，Suffix-後綴，Alone-單獨使用
注：Prefix-前綴，Suffix-後綴，Alone-單獨使用
3. 按需求才執行的方法注：Prefix-前綴，Suffix-後綴，Alone-單獨使用
注：Prefix-前綴，Suffix-後綴，Alone-單獨使用
注：Prefix-前綴，Suffix-後綴，Alone-單獨使用
注：Prefix-前綴，Suffix-後綴，Alone-單獨使用
注：Prefix-前綴，Suffix-後綴，Alone-單獨使用
注：Prefix-前綴，Suffix-後綴，Alone-單獨使用
注：Prefix-前綴，Suffix-後綴，Alone-單獨使用
注：Prefix-前綴，Suffix-後綴，Alone-單獨使用
三、方法編程建議1. 方法複雜度凡事邏輯判斷語句均為複雜度。當一個方法中出現了大於等於10個複雜度。建議根據
方法實現進行業務抽離。兩個建議點(1. 方法單一職責 2. 方法可重複利用 3. 是否能用策略模式或者命令模式)
2.方法長度及寬度長度: 方法的長度建議控制在80-120行以內。滿足一屏可以放下。 寬度: 當方法超過3個及以上入參,建議使用對象封裝(對象容易後期擴展,且不會出現眼花繚亂現象)
3.關注方法優化編輯器提示減少出現黃色警告⚠️, 最好不要出現警告。編輯器的警告都是優化點,需要在編程時候考慮進去。
eg: 性能優化、命名不規範、重複代碼
img
4.方法重複代碼貧血模型的標誌性問題
重複代碼編輯器會提出警告,此種現象,強烈建議不要出現
5. 方法註釋註釋是必須要做的(先寫註釋再做實現)，重在設計。
代碼是公司財產, 要對自己對公司對後人負責,先寫註釋再做實現。
四、項目依賴模型1. 領域設計的認識領域劃分,用另外一個詞形容也非常的合適,就是業務模塊化。所有能力都進行能力化抽象,形成模塊,形成領域。 當遇到新的業務邏輯,底層的數據結構和數據關係肯定也是一樣的。那麼就可以像堆積木一樣,根據這些模塊快速的組裝成新的業務邏輯。快速的實現業務的迭代和升級。
關於這個問題,需要結合自己的業務系統來進行抽象和設計。
設計核心: 用面向對象的設計思想對業務進行解耦來做到領域劃分。
2. 層次劃分基礎層(外部調用,db操作)注意: 基礎層只做適配不做業務
- db操作以dao結尾
- 外部調用以Client(Http協議)/Instruction(Rpc協議) 該層僅僅做數據適配,不做業務處理。
以Manager
業務層(對領域層的業務編排)以Service結尾
外觀層(可以提供能力,可以提供視圖)。以Resource、Facade結尾
有一個完善的領域層,可以方便快速便捷的對業務進行擴展。與其對立的就是貧血模型。沒有領域層只有業務層,業務邏輯都堆積在業務層。典型的面向過程設計。
img
3. 層次依賴模型maven多模塊應用和單模塊應用通用。
一定要控制項目的依賴情況。
①service只能出現領域層的依賴, 領域層只能存在dao層和第三方服務層。
②各個層代碼不能平行調用(出現平行調用邏輯,要抽象出領域層來封裝)。
img
具體代碼體現就是
- 以Service命名的類,裏面只能存在Manager
- 以Manager命名的類,裏面只能存在Dao和Client(Http協議)/Instruction(Rpc協議)封裝的第三方調用
- 以Dao命名的類是對數據庫的操作
- 以Client(Http協議)/Instruction(Rpc協議)命名的類,作為適配層與第三方API進行交互封裝
代碼編程時候要向以下這6大原則,進行向其靠攏。
1. 開閉原則一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
代碼設計建議
用抽象構建框架，用實現擴展細節因為抽象靈活性好，適應性廣，只要抽象的合理，可以基本保持軟件架構的穩定。
2. 單一職責不要存在多於一個導致類變更的原因通俗的説，即一個類只負責一項職責。
代碼設計建議
在具體方法編寫或者類編寫時候,類編寫時候業務要單一,方法編寫時候實現要單一
反例:
UserService 類中提供了獲取商品信息的接口
setUserName(String name)方法的時候,對name的值進行了二次處理。
3. 里氏替換原則所有引用基類的地方必須能透明地使用其子類的對象。
代碼設計建議
面向接口編程, 子類能透明替換父類。
4. 依賴倒置原則高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。
代碼設計建議
要根據接口或者抽象去設計,不要依賴於細節,eg.項目中要換數據庫,不用重新寫底層的數據庫代碼. 就是使用了hibernate一樣,替換方言就好了,因為hibernate是根據接口設計的,不同數據庫有不同的實現,可以直接使用. eg2: 我生病了要去買藥,如果A藥鋪,沒有我就用B藥鋪買. 因為他們都是藥鋪,都有一樣的功能,可以友好的替換
5. 接口隔離原則客户端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
代碼設計建議
保持最小的責任。
eg: 接口ConfigurableApplicationContext實現了Lifecycle和Closeable接口。他們其中每個裏面定義的接口都很少,為什麼不定義到一起呢?
首先第一責任清晰單一,第二做到接口隔離。
當某一個方法只用到生命週期的方法,那麼方法就可以寫成。
public void stop(Lifecycle lifecycle); 調用時候用->public void stop(new ConfigurableApplicationContext());
public void close(Closeable closeable); 調用時候用->public void close(new ConfigurableApplicationContext());
stop裏面的實現就只能調用Lifecycle裏面的方法,而不能調用ConfigurableApplicationContext裏面的方法。從而來達到接口隔離原則
6. 迪米特法則一個對象應該對其他對象保持最少的瞭解。
代碼設計建議
減少類與類之間的關係,接口隔離也可以做到。
六、版本迭代- master分支版本後綴 ${大版本號}.${0進位}.${迭代版本號}.RELEASE
- test分支版本號 ${大版本號}.${0進位}.${迭代版本號}.SNAPSHOP
迭代版本可追蹤，避免出現jar包覆蓋無法追蹤
迭代版本升級,必須升級迭代版本號。避免出現jar包覆蓋無法追蹤
1. 大版本定義APP1.0 APP2.0 APP3.0
2. 迭代版本號APP1.0.1 APP1.0版本的第一個迭代
APP1.1.0 APP1.0版本的第十個迭代
APP2.0.2 APP2.0版本的第二個迭代
APP2.1.0 APP2.0版本的第十個迭代
七、代碼格式化統一格式化模板,解決多人共同開發場景,代碼格式化導致的git提交衝突問題
【來源：軟件編程指南】
聲明：轉載此文是出於傳遞更多信息之目的。若有來源標註錯誤或侵犯了您的合法權益，請作者持權屬證明與本網聯繫，我們將及時更正、刪除，謝謝。 郵箱地址：[email protected]