[[429094]]

大家所在項目組，一定遇到同類操作，但卻有不同做法，尤其是祖傳代碼，一眼望去，可謂八仙過海各顯神通。

大部分程序員也覺得團隊開發應該保持編程習慣的一致性。但普遍理解的一致性都表現在較宏觀層面，比如，數據庫訪問是叫DAO還是叫Mapper，Repository?

團隊雖然也有一些統一標準，但落地到編碼，也沒人一直給你 CR，所以要求就不是那么嚴格了。所以，我們才能欣賞到在代碼寫法百家爭鳴。還是具體看幾個案例來體會下吧！

千奇百怪的命名

這段代碼可以了解到目前的分發渠道：

• 網站
• 只在Kindle
• 全渠道

乍一看，你可能覺得沒啥問題，可我就會好奇作者：

• WEBSITE 和 KINDLE_ONLY 分別表示什么?
• WEBSITE：作品只會在我們自己網站發布，KINDLE_ONLY：這部作品只會在 Kindle 的電子書商店里上架。
• 二者是不是都表示只能在單獨一個渠道發布?

Yes

• 既然含義類似，為何不都叫 XXX 或 XXX_ONLY?

(⊙o⊙)…好像也是哦

所以，大家也看到了吧，類似含義的代碼應該有一致的名稱，就像很多團隊都會把業務寫到服務層，各種服務類類名也都是 XXXService。

不一致的名字，一般都表示不同含義。比如，對那些非業務入口的業務組件，它們的名字就會不同，會更符合其具體業務行為，如BookSender：將作品發到翻譯引擎。

我料想，這段代碼作者給枚舉值命名時，只分別考慮了應該叫啥名，卻忽略了這個枚舉值在整體中的地位。

至此，重構途徑就很明白了：

方案不一致

現在某系統要向另外一個系統發請求，需帶一個時間戳，把這個時間戳按格式轉成

String，主要做傳輸用，便于外部系統識別，也方便開發調試。

代碼片段本身實現沒問題，甚至還考慮到了 SimpleDateFormat 這個類非線程安全，所以，每次都創建一個新的 SimpleDateFormat 對象。

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

現在這是個Java8項目，完全可以使用 Java 8 的新日期時間API。所以項目也約定所有日期時間類型使用新API。

所以，這段代碼本身實現沒問題，但放在項目整體中，卻沒有和其它部分保持一致。

重構成使用新API即可：

一個項目應對同一個問題出現多個解決方案，沒有統一約定，成員會根據自己的習慣隨機選擇方案，導致方案不一致。還比如判斷字符串是否為空或空串，就有 Guava 和 Apache Commons Lang，都能做同樣事情，所以，程序員也會根據自己熟悉程度選擇其中之一來用，造成代碼不一致。

這兩個程序庫是很多程序庫的基礎，經常因為引入了其它程序庫，相應的依賴就出現在我們的代碼中。所以，我們必須約定，哪種做法是我們在項目中的標準做法，以防出現各自為營。

代碼中的不一致

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

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

看得出來什么問題嗎?

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

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

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

所以，這個函數有的是業務動作，有的是業務動作的細節。所以重構如下：

分清代碼處于不同層次，基本功就是分離關注點。一旦分解出不同關注點，還可進一步調整代碼的結構。

像前面拆分出來的這個方法，我們已經知道它的作用是發出一個請求去創建作品，本質上并不屬于這個業務類的一部分。

所以，還可通過引入一個新模型，將這個部分調整出去：