阿裏的同事，寫的程式碼真 TMD 優雅！

大家好，我是鵬磊。

本篇文章是<<程式碼整潔之道>>的學習總結, 透過這篇文章你將了解到整潔的程式碼對計畫、公司和你的重要性,以及如何書寫整潔的程式碼.

透過命名、類、函式、測試這四個章節,使我們的程式碼變得整潔.

1.為什麽要保持程式碼整潔?

不整潔的程式碼隨著時間的增加而增延長,生產力會隨之降低.
導致的結果就是:

一圖勝千言

1.1 所以從一開始就要保持整潔

所以在一開始就要寫整潔的程式碼,如果有不整潔的程式碼就要及時的整改. 絕對不要有以後再改,以後再說的想法， 因為！

later equal never


想想是不是這個道理,你有多少以後再說、以後再改的東西都拋諸腦後了.

如果是一定要做的事情,那就趁早做!

1.2 如何寫出整潔的程式碼?

那麽現在的問題就是,怎樣的程式碼才算是整潔的程式碼呢:

2.命名

好的命名可提高程式碼的可讀性,讓人見碼知意, 降低理解成本,提高效率, 減少加班.

插播一條：如果你近期準備面試跳槽，建議在ddkk.com線上刷題，涵蓋 1萬+ 道 Java 面試題，幾乎覆蓋了所有主流技術面試題。

2.1 不好的命名方式

1、 沒有任何意義的命名方式；

publicinterfaceAnimal{
voidabc();
}


現在我們有一個動物的介面, 裏面有一個方法abc(),看了讓人一頭霧水, 呼叫這個方法的人也完全不知道這個方法是幹什麽的,因為他的命名毫無意義

有意義的命名方式:

publicinterfaceAnimal{
voidcry();
}


我們將方法名命名為cry(喊叫,呼喊),呼叫的人就知道這個方法的作用是什麽了.

所以命名一定要有意義且讓人見碼知意.

1、 命名前後不一致；
這種情況體現在明明是同一行為,但是卻有不同的命名,前後不一致,讓人造成混淆.

publicinterfaceStudentRepositoryextendsJpaRepository<AlertAll, String> {
Student findOneById(
@Param("id") String id
);
List<Student> queryAllStudent(
);
}


上面兩個方法都是查詢xxx, 但是命名一會叫query一會叫find,這種情況應該加以規範,保持一致, 修改後:

publicinterfaceStudentRepositoryextendsJpaRepository<AlertAll, String> {
Student findOneById(
@Param("id") String id
);
List<Student> findAll(
);
}


1、 命名冗余；
體現在命名有很多沒必要的成分在裏面, 並且這些"廢話"並不能幫助區分它們的區別, 例如在變量命名中添加了Variable這個詞, 在表名中添加了Table這個詞.

所以命名中不要出現冗余的單詞, 並且提前約定好命名的規範.

// 獲取單個物件的方法用get做字首
getXxx();
//獲取多個物件用list做字首
listXxxx();


3.類

整潔的類應滿足一下內容:

3.1單一職責

類應該短小,類或模組應有且只有一條加以修改的理由, 如果一個類過於龐大的話,那麽說明它承擔的職責過多了.

插播一條：如果你近期準備面試跳槽，建議在ddkk.com線上刷題，涵蓋 1萬+ 道 Java 面試題，幾乎覆蓋了所有主流技術面試題。

優點:

如何判定類是否足夠短小?
透過計算類的職責來判斷是否夠短小,類的名稱描述其全責, 如果無法為某個類命以準確的名稱, 這個類大概就太長了, 類名越含糊,可能擁有越多的職責.

職責過多的例子,可以看到以下類有兩個職責:

publicabstract classSql{
// 操作SQL的職責
publicabstractvoidinsert();
// 統計SQL操作的職責
publicabstractvoidcountInsert();
}

將統計的職責抽取到另一個類

publicabstract classCountSql{
publicabstractvoidcountInsert();
}


3.2 開閉原則

開閉原則: 面向修改關閉, 面向擴充套件開放.

面向修改關閉意味著增加新的邏輯不會修改原有的程式碼,降低了出錯的可能性.

面向擴充套件開放則是提高了程式碼的可延伸性,可很容易的增加新的程式碼邏輯.

不滿足開閉原則的例子:

publicabstract classSql{
publicabstractvoidinsert();
publicabstractvoidupdate();
publicabstractvoiddelete();
}


如果我們現在要新增查詢的操作,就需要修改Sql這個類,沒有做到面向修改關閉

重構後:

publicabstract classSql{
publicabstractvoidgenerate();
}
public classCreateSqlextendsSql{
@java.lang.Override
publicvoidgenerate(){
// 省略實作
}
}
public classUpdateSqlextendsSql{
@Override
publicvoidgenerate(){
// 省略實作
}
}



當我們要增加刪除方法時可以很容易的擴充套件.

使用大量的短小的類看似比使用少量龐大的類增加了工作量(增加了更多的類),但是真的是這樣嗎? 這裏有一個很好的類比:

你是想把工具歸置到有許多抽屜、每個抽屜中裝有定義和標記良好的元件的工具箱呢, 還是想要少數幾個能隨便吧所有東西扔進去的抽屜?

最終的結論:

系統應該由許多短小的類而不是少量巨大的類組成,每個小類封裝一個權責,只有一個修改的原因,並與少數其他類一起協同達成期望的系統行為.


3.3 內聚

方法操作的變量越多,就約粘聚到類上. 如果一個類中的每個變量都被每個方法所使用, 則該類具有最大的內聚性.
我們應該將類的內聚性保持在較高的位置. 內聚性高意味著方法和變量互相依賴, 互相結合成一個邏輯整體.

插播一條：如果你近期準備面試跳槽，建議在ddkk.com線上刷題，涵蓋 1萬+ 道 Java 面試題，幾乎覆蓋了所有主流技術面試題。

為什麽要保持高內聚?
保持內聚性就會得到許多短小的類,就越滿足單一職責.

內聚性低怎麽辦?
如果類的內聚性就不夠高,就將原有的類拆分為新的類和方法.

4.函式

要想讓函式變得整潔,應保證:

4.1 只做一件事

what?
函式的第一規則是短小 第二規則是更短小 短小到只做一件事情. (沒錯和類的原則很像)

why?
函式越短小,越能滿足單一職責.

how?
以下是重構前的程式碼, 這個方法有三個職責,並且該方法很長達到了80+50+5 = 135行

public classPicService{
public String upload(){
// 校驗圖片的方法 虛擬碼80行
// 壓縮圖片的方法 虛擬碼50行
// 返回成功或失敗標識 0,1 虛擬碼5行
return"0";
}
}



原有的upload方法做了很多的事情, 重構後只做了一件事情: 把大一些的概念(換言之,函式的名稱)拆分為另一抽象層上的一系列步驟:

public String upload(){
// 校驗圖片的方法
check();
// 壓縮圖片的方法
compress();
// 返回成功或失敗標識 0,1
return"0";
}


而裏面的每個方法,也都有著自己各自的職責(校驗圖片 、壓縮圖片 、返回結果).

4.2 函式命名

1、 函式名應見名知意；
函式擁有描述性的名稱，不要害怕長名稱.

不好的命名方式:

public String addCharacter(String originString, char ch);


這個函式，一咋看，還不錯，從函數位面意思看是給某個字串添加一個字元。但是到底是在原有字串首部添加，還是在原有字串末尾追加呢？亦或是在某個固定位置插入呢？從函式名字完全看不出來這個函式的真正意圖，只能繼續往下讀這個函式的具體實作才知道。

而下面這幾個名字就比上面要好得多：

// 追加到末尾
public String appendCharacter(String originString, char ch);
// 插入指定位置
public String insertCharacter(String originString, char ch, int insertPosition); 

1、 函式應該無副作用；
函式應該無副作用， 意思就是函式應該只做一件事，但是做這件事的時候做了另一件有副作用的事情.

例如:校驗密碼時會初始化session，導致會話遺失。如果無法移除這種副作用，應該在方法名中展示出來，避免使用者誤用 checkPasswordasswordAndInitializeSession, 從命名上就要體現副作用.

4.3 參數

1、 參數越少越好；
參數越少，越容易理解，參數超過三個可以將參數進行封裝，要按參數的語意進行封裝，不一定封裝成一個大而全的參數，可以封裝為多個，原則是按語意補充;

範例:

public List<Student> findStudent(int age, String name, String country, int gender);
//封裝參數
public List<Student> findStudent(Student student);

1、 不要使用標識參數；
標識參數是參數為Boolean 型別, 使用者傳遞true or false . 不要使用標識參數因為這意味著你的函式違背了單一職責(true false 兩套邏輯).

正確的做法是拆分為兩個方法:

//標識參數方法
render(Boolean isSuite);
//重構為兩個方法
reanderForSuite();
renderForSingleTest();

1、 不要使用輸出參數；

什麽是輸出參數?

將變量作為參數傳入方法,並且將變量輸出, 這就是輸出參數

publicvoidfindStudent(){
Student student = new Student();
doSomething(student);
return student;
}
intdoSomething(Student student){
// 省略一些student邏輯
return student;
}

為什麽不應該有輸出參數?
因為增加了理解成本在裏面,我們需要檢視doSomething到底對student 做了什麽. student是輸入還是輸出參數? 都不明確.

重構:

// 將doSomething()方法內聚到student物件本身
student.doSomething();


4.4 返回值

1、 分離指令與訊問；
範例程式碼:

Pulic Boolean addElement(Element element)


指令為增加某個元素,詢問是否成功,

這樣做的壞處是職責不單一，所以應該拆分為兩個方法

publicvoidaddElement(Element element);
public Boolean isAdd(Element element);


1、 使用異常替代返回錯誤碼；
直接丟擲異常,而不是返回錯誤碼進行判斷, 可以使程式碼更簡潔. 因為使用錯誤碼有可能會進行多層巢狀片段

程式碼範例:

// 使用錯誤碼導致多層巢狀...
public classDeviceController{
publicvoidsendShutDown(){
DeviceHandle handle=getHandle(DEV1);
//Check the state of the device 
if (handle != DeviceHandle.INVALID){
// Save the device status to the record field 
retrieveDeviceRecord(handle);
// If nat suspended,shut down
if (record.getStatus()!=DEVICE_SUSPENDED){
pauseDevice(handle);
clearDeviceWorkQueue(handle);
closeDevice(handle);
}else{
logger.log("Device suspended. Unable to shut down"); 
}
}else{
logger.log("Invalid handle for: " +DEV1.tostring()); 
 }
} 

重構後:

// 將程式碼拆分為一小段一小段, 降低復雜度,更加清晰
public classDeviceController{
publicvoidsendShutDowm(){ 
try{
tryToShutDown();
} catch (DeviceShutDownError e){ 
logger.log(e);
}
privatevoidtryToShutDown()throws DeviceShutDownError{
DeviceHandle handle =getHandle(DEV1);
retrieveDeviceRecord(handle);
pauseDevice(handle);
clearDeviceWorkQueue(handle);
closeDevice(handle);
 }
private DeviceHandle getHandle(DeviceID id){
// 省略業務邏輯
thrownew DeviceShutDownError("Invalid handle for:"+id.tostring()); 
 }
}



4.5 怎樣寫出這樣的函式?

沒人能一開始就寫出完美的程式碼, 先寫出滿足功能的程式碼,之後緊接著進行重構

為什麽是緊接著?
因為later equal never!

4.6 程式碼品質掃描工具

使用SonarLint可以幫助我們發現程式碼的問題,並且還提供了相應的解決方案.
對於每一個問題，SonarLint都給出了範例，還有相應的解決方案，教我們怎麽修改，極大的方便了我們的開發
比如，對於日期型別盡量用LocalDate、LocalTime、LocalDateTime，還有重復程式碼、潛在的空指標異常、迴圈巢狀等等問題
有了程式碼規範與品質檢測工具以後，很多東西就可以量化了，比如bug率、程式碼重復率等.

5.測試

測試很重要,可以幫助我們驗證寫的程式碼是否沒問題,同樣的測試程式碼也應該保持整潔.

5.1 TDD

TDD是測試驅動開發（Test-Driven Development），是敏捷開發中的一項核心實踐和技術，也是一種設計方法論

優點：在任意一個開發節點都可以拿出一個可以使用，含少量bug並具一定功能和能夠釋出的產品。

插播一條：如果你近期準備面試跳槽，建議在ddkk.com線上刷題，涵蓋 1萬+ 道 Java 面試題，幾乎覆蓋了所有主流技術面試題。

缺點：增加程式碼量。測試程式碼是系統程式碼的兩倍或更多，但是同時節省了偵錯程式及挑錯時間。

how?
1、 在開發程式碼前先寫測試；
2、 只可編寫剛好無法透過的單元測試，不能編譯也算不透過；
3、 開發程式碼不可超過測試；

關於2的解釋: 單測與生產程式碼同步進行，寫到一個不可編譯的單測就開始寫生產程式碼，如此反復迴圈，單測就能包含到所有生產程式碼。

5.2 FIRST原則

FIRST 原則就是一個指導編寫單元測試的原則
fast 快速 單測執行應該快速的完成
independent 獨立 單測之間相互獨立
repeatable 可重復 單測不依賴於環境，隨處可執行
self validating 程式可透過輸出的Boolean自我驗證，而不需要透過人工的方式驗證（看日誌輸出、對比兩個檔不同等）
timely 及時 單測在生產程式碼之前編寫

單元測試是程式碼測試中的基礎測試，FIRST是寫好單元測試的重要原則，它要求我們的單元測試快速，獨立，可重復，自我校驗，及時/完整。

5.3 測試程式碼模式

開發測試程式碼可以使用given-when-then模式
given 制造模擬數據
when 執行測試程式碼
then 驗證測試結果

程式碼範例

/**
* If an item is loaded from the repository, the name of that item should 
* be transformed into uppercase.
*/
@Test
publicvoidshouldReturnItemNameInUpperCase(){
// Given
Item mockedItem = new Item("it1", "Item 1", "This is item 1", 2000, true);
when(itemRepository.findById("it1")).thenReturn(mockedItem);
// When
String result = itemService.getItemNameUpperCase("it1");
// Then
verify(itemRepository, times(1)).findById("it1");
assertThat(result, is("ITEM 1"));
}



使用give-when-then 模式可提高測試程式碼的可讀性.

5.4 自動生成單測

介紹兩款IDEA自動生成單測的外掛程式

6.結束語

編寫整潔的程式碼可以讓我們提高程式碼的可讀性,使程式碼變得更易擴充套件,提高我們的開發效率,減少加班,提高我們的level.

每個開發人員都應該去看看<<程式碼整潔之道>>,使我們的編碼能力以及編程思想都得到提升.

再重復一次,我們應該及時的寫出整潔的程式碼,而不是想著事後采取補救

來源:cnblogs.com/liuboren/p/17017421.html

🔥 磊哥私藏精品 熱門推薦 🔥