阿裡的同僚，寫的代碼真 TMD 優雅！

通過這篇文章你将了解到整潔的代碼對項目、公司和你的重要性,以及如何書寫整潔的代碼.

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

1、為什麼要保持代碼整潔?

不整潔的代碼随着時間的增加而增加時,生産力會随之降低.

導緻的結果就是:

• 代碼不易擴充或擴充容易引發其他問題
• 程式崩潰
• 加班
• 增加公司成本(加人)
• 甚至可能造成公司倒閉

一圖勝千言

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

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

later equal never

           

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

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

1.2、如何寫出整潔的代碼?

那麼現在的問題就是,怎樣的代碼才算是整潔的代碼呢:

• 可讀性要高: 代碼要像散文一樣優雅易讀,見碼知意
• 拒絕重複代碼
• 滿足設計模式原則
• 單一職責
• 開閉原則
• 裡氏替換原則
• 依賴倒轉原則
• 接口隔離原則
• 迪米特法則
• 合成複用法則

2、命名

好的命名可提高代碼的可讀性,讓人見碼知意, 降低了解成本,提高效率, 減少加班。

2.1、不好的命名方式

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

public interface Animal {
    void abc();
}

           

現在我們有一個動物的接口, 裡面有一個方法abc(),看了讓人一頭霧水, 調用這個方法的人也完全不知道這個方法是幹什麼的,因為他的命名毫無意義

有意義的命名方式:

public interface Animal {
    void cry();
}

           

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

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

1、命名前後不一緻；

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

public interface StudentRepository extends JpaRepository<AlertAll, String> {
    Student findOneById(
            @Param("id") String id
    );

    List<Student> queryAllStudent(
    );

}

           

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

public interface StudentRepository extends JpaRepository<AlertAll, String> {
    Student findOneById(
            @Param("id") String id
    );

    List<Student> findAll(
    );

}

           

1、命名備援；

展現在命名有很多沒必要的成分在裡面, 并且這些"廢話"并不能幫助區分它們的差別, 例如在變量命名中添加了Variable這個詞, 在表名中添加了Table這個詞.

是以命名中不要出現備援的單詞, 并且提前約定好命名的規範.

// 擷取單個對象的方法用get做字首
getXxx();
//擷取多個對象用list做字首
listXxxx();

           

3、類

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

• 單一職責
• 開閉原則
• 高内聚性

3.1、單一職責

類應該短小,類或子產品應有且隻有一條加以修改的理由, 如果一個類過于龐大的話,那麼說明它承擔的職責過多了。

優點:

• 降低類的複雜度
• 提高類的可讀性
• 提高系統的可維護性
• 降低變更引起的風險

如何判定類是否足夠短小?

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

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

public abstract class Sql {
    // 操作SQL的職責
    public abstract void insert();
    // 統計SQL操作的職責
    public abstract void countInsert();

}

           

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

public abstract class CountSql {

    public abstract void countInsert();

}

           

3.2、開閉原則

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

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

面向擴充開放則是提高了代碼的可擴充性,可很容易的增加新的代碼邏輯.

不滿足開閉原則的例子:

public abstract class Sql {
    public abstract void insert();
    public abstract void update();
    public abstract void delete();
}

           

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

重構後:

public abstract class Sql {
    public abstract void generate();
}

public class CreateSql extends Sql {

    @java.lang.Override
    public void generate() {
        // 省略實作
    }
}
public class UpdateSql extends Sql {

    @Override
    public void generate() {
        // 省略實作
    }
}

           

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

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

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

最終的結論:

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

           

3.3、内聚

方法操作的變量越多,就約粘聚到類上. 如果一個類中的每個變量都被每個方法所使用, 則該類具有最大的内聚性.

我們應該将類的内聚性保持在較高的位置. 内聚性高意味着方法和變量互相依賴, 互相結合成一個邏輯整體.

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

為什麼要保持高内聚?

保持内聚性就會得到許多短小的類,就越滿足單一職責.

内聚性低怎麼辦?

如果類的内聚性就不夠高,就将原有的類拆分為新的類和方法.

4、函數

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

• 隻做一件事
• 好的命名
• 整潔的參數
• 注意傳回内容

4.1、隻做一件事

what?

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

why?

函數越短小,越能滿足單一職責.

how?

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

public class PicService {

    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、不要使用輸出參數；

什麼是輸出參數?

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

public void findStudent(){
Student student = new Student();
doSomething(student);
return student;
}

int doSomething(Student student){
// 省略一些student邏輯
return student;
}

           

為什麼不應該有輸出參數?

因為增加了了解成本在裡面,我們需要檢視doSomething到底對student 做了什麼. student是輸入還是輸出參數? 都不明确.

重構:

// 将doSomething()方法内聚到student對象本身
student.doSomething();

           

4.4、傳回值

1、分離指令與訊問；

示例代碼:

Pulic Boolean addElement(Element element)

           

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

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

public void addElement(Element element);
public Boolean isAdd(Element element);

           

1、使用異常替代傳回錯誤碼；

直接抛出異常,而不是傳回錯誤碼進行判斷, 可以使代碼更簡潔. 因為使用錯誤碼有可能會進行多層嵌套片段

代碼示例:

// 使用錯誤碼導緻多層嵌套...
public class DeviceController{

 public void sendShutDown(){
  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 class DeviceController{

 public void sendShutDowm(){ 
  try{
   tryToShutDown();
  } catch (DeviceShutDownError e){ 
   logger.log(e);
  }

 private void tryToShutDown() throws DeviceShutDownError{
   DeviceHandle handle =getHandle(DEV1);
   retrieveDeviceRecord(handle);
   pauseDevice(handle);
   clearDeviceWorkQueue(handle);
   closeDevice(handle);
 }

 private DeviceHandle getHandle(DeviceID id){
              // 省略業務邏輯
  throw new 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
public void shouldReturnItemNameInUpperCase() {
 
    // 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自動生成單測的插件

• Squaretest插件（收費）
• TestMe插件(免費)

6、結束語

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

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

再重複一次,我們應該及時的寫出整潔的代碼,而不是想着事後采取補救