Java雜談之如何優化寫出漂亮高效的代碼

大部分程序員對於一致性本身的重要性是有認知的。但通常來說，大傢理解的一致性都表現在比較大的方面，比如，數據庫訪問是叫 DAO還是叫 Mapper，Repository？在一個團隊內，這是有統一標準的，但編碼的層面上，要求往往就不是那麼細致瞭。所以，我們才會看到在代碼細節上呈現出瞭各種不一致。我們還是從一段具體的代碼來分析問題。

命名中的不一致

有一次，我在代碼評審中看到瞭這樣一段代碼：

enum DistributionChannel {
  ​WEBSITE
  ​KINDLE_ONLY
  ​AL
}

使用標記作品的分發渠道，從這段代碼的內容上，我們可以看到，目前的分發渠道包括：

• 網站（WEBSITE）
• 隻在Kindle（KINDLE_ONLY）
• 全渠道（ALL）

面對這段代碼，我有些疑惑，於是我提瞭一個問題：

• WEBSITE 和 KINDLE_ONLY 分別表示的是什麼？

WEBSITE 表示作品隻會在我們自己的網站發佈，KINDLE_ONLY 表示這部作品隻會在 Kindle 的電子書商店裡上架。

• 二者是不是都表示隻在單獨一個渠道發佈？

是啊！

• 既然二者都有隻在一個平臺上架發佈的含義，為什麼不都叫 XXX 或者 XXX_ONLY？

呃，你說得有道理。

問題原因就是這裡 WEBSITE 和 KINDLE_ONLY 兩個名字不一致。

表示類似含義的代碼應該有一致的名字，比如，很多團隊裡都會把業務寫到服務層，各種服務的命名也通常都是 XXXService。
一旦出現不一致名字，通常都表示不同含義。比如，對於那些非業務入口的業務組件，它們的名字就會不一樣，會更符合其具體業務行為，像BookSender ，它表示將作品發送到翻譯引擎。

一般枚舉值表示的含義應該都有一致的業務含義，一旦出現不同，我就需要確定不同的點到底在哪裡，這就是我提問的緣由。

顯然，這段代碼的作者給這兩個枚舉值命名時，隻是分別考慮瞭它應該起什麼名字，卻忽略瞭這個枚舉值在整體中扮演的角色。

理解這一點，改動是很容易，後來，代碼被統一成瞭一個形式：

enum DistributionChannel {
  ​WEBSITE
  ​KINDLE
  ​AL
}

方案中的不一致

// 生成時間戳
public String nowTimestamp() {
  DateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
  Date now = new Date();
  return format.format(now);
}

當一個系統向另外一個系統發送請求時，需要帶一個時間戳過去，這裡就是把這個時間戳按照一定格式轉成瞭字符串類型，主要就是傳輸用，便於另外的系統進行識別，也方便在開發過程中進行調試。

這段代碼本身的實現是沒有問題的。它甚至考慮到瞭 SimpleDateFormat 這個類本身存在的多線程問題，所以，它每次去創建瞭一個新的 SimpleDateFormat 對象。

那我為什麼還說它是有問題的呢？因為這種寫法是 Java 8 之前的寫法，而我們用的 Java 版本是 Java 8 之後的。

在很長的一段時間裡，Java 的日期時間解決方案一直是一個備受爭議的設計，它的問題很多，有的是概念容易讓人混淆（比如：Date 和 Calendar 什麼情況下該用哪個），有的是接口設計的不直觀（比如：Date 的 setMonth 參數是從 0 到 11），有的是實現容易造成問題（比如：前面提到的 SimpleDateFormat 需要考慮多線程並發的問題，需要每次構建一個新的對象出來）。

這種亂象存在瞭很長時間，有很多人都在嘗試解決這個問題（比如 Joda Time）。從 Java 8開始，Java 官方的 SDK 借鑒瞭各種程序庫，引入瞭全新的日期時間解決方案。這套解決方案與原有的解決方案是完全獨立的，也就是說，使用這套全新的解決方案完全可以應對我們的所有工作。

我們現在的這個項目是一個全新的項目，我們使用的版本是 Java 11，這就意味著我們完全可以使用這套從 Java 8 引入的日期時間解決方案。所以，我們在項目裡的約定就是所有的日期時間類型就是使用這套新的解決方案。

現在你可能已經知道我說的問題在哪裡瞭，在這個項目裡，我們的要求是使用新的日期時間解決方案，而這裡的 SimpleDateFormat 和 Date 是舊解決方案的一部分。所以，雖然這段代碼本身的實現是沒有問題的，然而，放在項目整體中，這卻是一個壞味道，因為它沒有和其它的部分保持一致。

後來使用瞭新的解決方案：

public String nowTimestamp() {
  ​LocalDateTime now = LocalDateTime.now()
  return now.format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"));
}

之所以會這樣，因為一個項目中，應對同一個問題出現瞭多個解決方案，如果沒有統一約定，項目成員會根據自己寫代碼時的感覺隨機選擇方案，導致方案不一致。

為什麼一個項目中會出現多個解決方案？

• 時間

時間消逝，技術發展，人們會主動意識到原方案的問題，就會提出新方案，像這裡 Java 日期時間的解決方案，就是 JDK 本身隨時間演化造成的。有的項目時間比較長，也會出現類似問題。

• 因為自己的原因引入

比如，在代碼中引入做同一件事情類似的程序庫。比如判斷字符串是否為空或空串，就有 Guava 和 Apache Commons Lang，都能做同樣事情，所以，程序員也會根據自己的熟悉程度選擇其中之一來用，造成代碼不一致。

這兩個程序庫是很多程序庫的基礎，經常因為引入瞭其它程序庫，相應的依賴就出現在我們的代碼中。所以，我們必須約定，哪種做法是我們在項目中的標準做法，以防出現各自為戰的現象。比如，在我的團隊中，我們就選擇 Guava 作為基礎庫，因為相對來說，它的風格更現代，所以，團隊就約定類似的操作都以 Guava 為準。

代碼中的不一致

public void createBook(final List<BookId> bookIds) throws IOException {
  ​List<Book> books = bookService.getApprovedBook(bookIds)
  ​CreateBookParameter parameter = toCreateBookParameter(books)
  ​HttpPost post = createBookHttpRequest(parameter)
  ​httpClient.execute(post)
}

在翻譯引擎中創建作品的代碼：

• 首先，根據要處理的作品 ID，獲取其中已審核通過的作品
• 然後，發送一個 HTTP 請求在翻譯引擎中創建出這個作品

有什麼問題？
這段代碼的不一致，這些代碼不是一個層次的代碼！

首先是獲取審核通過的作品，這是一個業務動作，接下來的三行其實是在做一件事，也就是發送創建作品的請求，這三行代碼：

• 創建請求的參數
• 根據參數創建請求
• 最後把請求發送出去

三行代碼合起來完成瞭一個發送創建作品請求這麼一件事，而這件事才是一個完整的業務動作。

所以，這個函數裡的代碼並不在一個層次上，有的是業務動作，有的是業務動作的細節。理解到這，把這些業務細節的代碼提取到一個函數：

public void createBook(final List<BookId> bookIds) throws IOException {
  ​List<Book> books = bookService.getApprovedBook(bookIds)
  ​createRemoteBook(books)
}

private void createRemoteBook(List<Book> books) throws IOException {
  ​CreateBookParameter parameter = toCreateBookParameter(books)
  ​HttpPost post = createBookHttpRequest(parameter)
  ​httpClient.execute(post)
}

結果上看，原來的函數（createBook）裡都是業務動作，而提取出來的函數（createRemoteBook）則都是業務動作的細節，各自語句都在一個層次。

分清代碼處於不同層次，基本功還是分離關註點！

一旦分解出不同關註點，還可進一步調整代碼的結構。
像前面拆分出來的這個方法，我們已經知道它的作用是發出一個請求去創建作品，本質上並不屬於這個業務類的一部分。
所以，還可通過引入一個新模型，將這個部分調整出去：

public void createBook(final List<BookId> bookIds) throws IOException {
  List<Book> books = this.bookService.getApprovedBook(bookIds);
  this.translationEngine.createBook(books);
}


class TranslationEngine {
  public void createBook(List<Book> books) throws IOException {
    ​CreateBookParameter parameter = toCreateBookParameter(books)
    ​HttpPost post = createBookHttpRequest(parameter)
    ​httpClient.execute(post)
  ​
  ​..
}

一說到分層，大多數人想到的隻是模型的分層，很少有人會想到在函數的語句中也要分層。各種層次的代碼混在一起，許多問題也就隨之而來瞭，最典型莫過長函數。

我們在做的依然是模型分層，隻不過，這次的出發點是函數的語句。“分離關註點，越小越好”的意義所在。觀察代碼的粒度足夠小，很多問題自然就會暴露出來。

程序員開始寫測試時，有一個典型的問題：如何測試一個私有方法。有人建議用一些特殊能力（比如反射）去測試。我給這個問題的答案是，不要測私有方法。
之所以想測試私有方法，就是分離關註點沒有做好，把不同層次的代碼混在一起。前面這段代碼，如果要測試前面那個 createRemoteBook 方法還是有一定難度的，但調整之後，引入瞭 TranslationEngine 這個類，這個方法就變成瞭一個公開方法，就可以按照一個公開方法去測試瞭，所有問題迎刃而解。

很多程序員糾結的技術問題，其實是一個軟件設計問題，不要通過奇技淫巧去解決一個本來不應該被解決的問題。

總結

對於一個團隊來說，一致是非常重要的，是降低集體認知成本的重要方式。我們分別見識瞭：

• 命名中的不一致
• 方案中的不一致
• 代碼中的不一致。

類似含義的代碼應該有類似的命名，不一致的命名表示不同含義，需要給出一個有效解釋。

方案中的不一致：

• 由於代碼長期演化造成的
• 項目中存在完成同樣功能的程序庫

無論是哪種原因，都需要團隊先統一約定，保證所有人按照同一種方式編寫代碼。

代碼中的不一致常常是把不同層次的代碼寫在瞭一起，最典型的就是把業務層面的代碼和實現細節的代碼混在一起。解決這種問題的方式，就是通過提取方法，把不同層次的代碼放到不同的函數裡，而這一切的前提還是是分離關註點，這個代碼問題的背後還是設計問題。

保持代碼在各個層面上的一致性。

到此這篇關於Java雜談之如何優化寫出漂亮高效的代碼的文章就介紹到這瞭,更多相關Java 代碼優化內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：

• java集合collection接口與子接口及實現類
• Java解析xml文件和json轉換的方法(DOM4j解析)
• 新手小白學JAVA 日期類Date SimpleDateFormat Calendar(入門)
• SpringBoot @JsonDeserialize自定義Json序列化方式
• Java8-Stream流操作List去重問題