大部分程序員對于一致性本身的重要性是有認(rèn)知的。但通常來說，大家理解的一致性都表現(xiàn)在比較大的方面，比如，數(shù)據(jù)庫訪問是叫 DAO還是叫 Mapper，Repository？在一個(gè)團(tuán)隊(duì)內(nèi)，這是有統(tǒng)一標(biāo)準(zhǔn)的，但編碼的層面上，要求往往就不是那么細(xì)致了。所以，我們才會看到在代碼細(xì)節(jié)上呈現(xiàn)出了各種不一致。我們還是從一段具體的代碼來分析問題。

命名中的不一致

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

enum DistributionChannel {
  ​WEBSITE
  ​KINDLE_ONLY
  ​AL
}

使用標(biāo)記作品的分發(fā)渠道，從這段代碼的內(nèi)容上，我們可以看到，目前的分發(fā)渠道包括：

• 網(wǎng)站（WEBSITE）
• 只在Kindle（KINDLE_ONLY）
• 全渠道（ALL）

面對這段代碼，我有些疑惑，于是我提了一個(gè)問題：

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

WEBSITE 表示作品只會在我們自己的網(wǎng)站發(fā)布，KINDLE_ONLY 表示這部作品只會在 Kindle 的電子書商店里上架。

• 二者是不是都表示只在單獨(dú)一個(gè)渠道發(fā)布？

是??！

• 既然二者都有只在一個(gè)平臺上架發(fā)布的含義，為什么不都叫 XXX 或者 XXX_ONLY？

呃，你說得有道理。

問題原因就是這里 WEBSITE 和 KINDLE_ONLY 兩個(gè)名字不一致。

表示類似含義的代碼應(yīng)該有一致的名字，比如，很多團(tuán)隊(duì)里都會把業(yè)務(wù)寫到服務(wù)層，各種服務(wù)的命名也通常都是 XXXService。
一旦出現(xiàn)不一致名字，通常都表示不同含義。比如，對于那些非業(yè)務(wù)入口的業(yè)務(wù)組件，它們的名字就會不一樣，會更符合其具體業(yè)務(wù)行為，像BookSender ，它表示將作品發(fā)送到翻譯引擎。

一般枚舉值表示的含義應(yīng)該都有一致的業(yè)務(wù)含義，一旦出現(xiàn)不同，我就需要確定不同的點(diǎn)到底在哪里，這就是我提問的緣由。

顯然，這段代碼的作者給這兩個(gè)枚舉值命名時(shí)，只是分別考慮了它應(yīng)該起什么名字，卻忽略了這個(gè)枚舉值在整體中扮演的角色。

理解這一點(diǎn)，改動(dòng)是很容易，后來，代碼被統(tǒng)一成了一個(gè)形式：

enum DistributionChannel {
  ​WEBSITE
  ​KINDLE
  ​AL
}

方案中的不一致

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

當(dāng)一個(gè)系統(tǒng)向另外一個(gè)系統(tǒng)發(fā)送請求時(shí)，需要帶一個(gè)時(shí)間戳過去，這里就是把這個(gè)時(shí)間戳按照一定格式轉(zhuǎn)成了字符串類型，主要就是傳輸用，便于另外的系統(tǒng)進(jìn)行識別，也方便在開發(fā)過程中進(jìn)行調(diào)試。

這段代碼本身的實(shí)現(xiàn)是沒有問題的。它甚至考慮到了 SimpleDateFormat 這個(gè)類本身存在的多線程問題，所以，它每次去創(chuàng)建了一個(gè)新的 SimpleDateFormat 對象。

那我為什么還說它是有問題的呢？因?yàn)檫@種寫法是 Java 8 之前的寫法，而我們用的 Java 版本是 Java 8 之后的。

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

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

我們現(xiàn)在的這個(gè)項(xiàng)目是一個(gè)全新的項(xiàng)目，我們使用的版本是 Java 11，這就意味著我們完全可以使用這套從 Java 8 引入的日期時(shí)間解決方案。所以，我們在項(xiàng)目里的約定就是所有的日期時(shí)間類型就是使用這套新的解決方案。

現(xiàn)在你可能已經(jīng)知道我說的問題在哪里了，在這個(gè)項(xiàng)目里，我們的要求是使用新的日期時(shí)間解決方案，而這里的 SimpleDateFormat 和 Date 是舊解決方案的一部分。所以，雖然這段代碼本身的實(shí)現(xiàn)是沒有問題的，然而，放在項(xiàng)目整體中，這卻是一個(gè)壞味道，因?yàn)樗鼪]有和其它的部分保持一致。

后來使用了新的解決方案：

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

之所以會這樣，因?yàn)橐粋€(gè)項(xiàng)目中，應(yīng)對同一個(gè)問題出現(xiàn)了多個(gè)解決方案，如果沒有統(tǒng)一約定，項(xiàng)目成員會根據(jù)自己寫代碼時(shí)的感覺隨機(jī)選擇方案，導(dǎo)致方案不一致。

為什么一個(gè)項(xiàng)目中會出現(xiàn)多個(gè)解決方案？

• 時(shí)間
  

時(shí)間消逝，技術(shù)發(fā)展，人們會主動(dòng)意識到原方案的問題，就會提出新方案，像這里 Java 日期時(shí)間的解決方案，就是 JDK 本身隨時(shí)間演化造成的。有的項(xiàng)目時(shí)間比較長，也會出現(xiàn)類似問題。

• 因?yàn)樽约旱脑蛞?br />

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

這兩個(gè)程序庫是很多程序庫的基礎(chǔ)，經(jīng)常因?yàn)橐肓似渌绦驇?，相?yīng)的依賴就出現(xiàn)在我們的代碼中。所以，我們必須約定，哪種做法是我們在項(xiàng)目中的標(biāo)準(zhǔn)做法，以防出現(xiàn)各自為戰(zhàn)的現(xiàn)象。比如，在我的團(tuán)隊(duì)中，我們就選擇 Guava 作為基礎(chǔ)庫，因?yàn)橄鄬碚f，它的風(fēng)格更現(xiàn)代，所以，團(tuán)隊(duì)就約定類似的操作都以 Guava 為準(zhǔn)。

代碼中的不一致

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)
}

在翻譯引擎中創(chuàng)建作品的代碼：

• 首先，根據(jù)要處理的作品 ID，獲取其中已審核通過的作品
• 然后，發(fā)送一個(gè) HTTP 請求在翻譯引擎中創(chuàng)建出這個(gè)作品

有什么問題？
這段代碼的不一致，這些代碼不是一個(gè)層次的代碼！

首先是獲取審核通過的作品，這是一個(gè)業(yè)務(wù)動(dòng)作，接下來的三行其實(shí)是在做一件事，也就是發(fā)送創(chuàng)建作品的請求，這三行代碼：

• 創(chuàng)建請求的參數(shù)
• 根據(jù)參數(shù)創(chuàng)建請求
• 最后把請求發(fā)送出去

三行代碼合起來完成了一個(gè)發(fā)送創(chuàng)建作品請求這么一件事，而這件事才是一個(gè)完整的業(yè)務(wù)動(dòng)作。

所以，這個(gè)函數(shù)里的代碼并不在一個(gè)層次上，有的是業(yè)務(wù)動(dòng)作，有的是業(yè)務(wù)動(dòng)作的細(xì)節(jié)。理解到這，把這些業(yè)務(wù)細(xì)節(jié)的代碼提取到一個(gè)函數(shù)：

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)
}

結(jié)果上看，原來的函數(shù)（createBook）里都是業(yè)務(wù)動(dòng)作，而提取出來的函數(shù)（createRemoteBook）則都是業(yè)務(wù)動(dòng)作的細(xì)節(jié)，各自語句都在一個(gè)層次。

分清代碼處于不同層次，基本功還是分離關(guān)注點(diǎn)！

一旦分解出不同關(guān)注點(diǎn)，還可進(jìn)一步調(diào)整代碼的結(jié)構(gòu)。
像前面拆分出來的這個(gè)方法，我們已經(jīng)知道它的作用是發(fā)出一個(gè)請求去創(chuàng)建作品，本質(zhì)上并不屬于這個(gè)業(yè)務(wù)類的一部分。
所以，還可通過引入一個(gè)新模型，將這個(gè)部分調(diào)整出去：

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)
  ​
  ​..
}

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

我們在做的依然是模型分層，只不過，這次的出發(fā)點(diǎn)是函數(shù)的語句。“分離關(guān)注點(diǎn)，越小越好”的意義所在。觀察代碼的粒度足夠小，很多問題自然就會暴露出來。

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

很多程序員糾結(jié)的技術(shù)問題，其實(shí)是一個(gè)軟件設(shè)計(jì)問題，不要通過奇技淫巧去解決一個(gè)本來不應(yīng)該被解決的問題。

總結(jié)

對于一個(gè)團(tuán)隊(duì)來說，一致是非常重要的，是降低集體認(rèn)知成本的重要方式。我們分別見識了：

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

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

方案中的不一致：

• 由于代碼長期演化造成的
• 項(xiàng)目中存在完成同樣功能的程序庫

無論是哪種原因，都需要團(tuán)隊(duì)先統(tǒng)一約定，保證所有人按照同一種方式編寫代碼。

代碼中的不一致常常是把不同層次的代碼寫在了一起，最典型的就是把業(yè)務(wù)層面的代碼和實(shí)現(xiàn)細(xì)節(jié)的代碼混在一起。解決這種問題的方式，就是通過提取方法，把不同層次的代碼放到不同的函數(shù)里，而這一切的前提還是是分離關(guān)注點(diǎn)，這個(gè)代碼問題的背后還是設(shè)計(jì)問題。

保持代碼在各個(gè)層面上的一致性。

到此這篇關(guān)于Java雜談之如何優(yōu)化寫出漂亮高效的代碼的文章就介紹到這了,更多相關(guān)Java 代碼優(yōu)化內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論