你真的思考過自己寫的代碼為啥這么垃圾嗎?
大家所在項目組,一定遇到同類操作,但卻有不同做法,尤其是祖?zhèn)鞔a,一眼望去,可謂八仙過海各顯神通。
大部分程序員也覺得團隊開發(fā)應(yīng)該保持編程習(xí)慣的一致性。但普遍理解的一致性都表現(xiàn)在較宏觀層面,比如,數(shù)據(jù)庫訪問是叫DAO還是叫Mapper,Repository?
團隊雖然也有一些統(tǒng)一標準,但落地到編碼,也沒人一直給你 CR,所以要求就不是那么嚴格了。所以,我們才能欣賞到在代碼寫法百家爭鳴。還是具體看幾個案例來體會下吧!
千奇百怪的命名
這段代碼可以了解到目前的分發(fā)渠道:
- 網(wǎng)站
- 只在Kindle
- 全渠道
乍一看,你可能覺得沒啥問題,可我就會好奇作者:
- WEBSITE 和 KINDLE_ONLY 分別表示什么?
- WEBSITE:作品只會在我們自己網(wǎng)站發(fā)布,KINDLE_ONLY:這部作品只會在 Kindle 的電子書商店里上架。
- 二者是不是都表示只能在單獨一個渠道發(fā)布?
Yes
- 既然含義類似,為何不都叫 XXX 或 XXX_ONLY?
(⊙o⊙)…好像也是哦
所以,大家也看到了吧,類似含義的代碼應(yīng)該有一致的名稱,就像很多團隊都會把業(yè)務(wù)寫到服務(wù)層,各種服務(wù)類類名也都是 XXXService。
不一致的名字,一般都表示不同含義。比如,對那些非業(yè)務(wù)入口的業(yè)務(wù)組件,它們的名字就會不同,會更符合其具體業(yè)務(wù)行為,如BookSender:將作品發(fā)到翻譯引擎。
我料想,這段代碼作者給枚舉值命名時,只分別考慮了應(yīng)該叫啥名,卻忽略了這個枚舉值在整體中的地位。
至此,重構(gòu)途徑就很明白了:
方案不一致
現(xiàn)在某系統(tǒng)要向另外一個系統(tǒng)發(fā)請求,需帶一個時間戳,把這個時間戳按格式轉(zhuǎn)成
String,主要做傳輸用,便于外部系統(tǒng)識別,也方便開發(fā)調(diào)試。
代碼片段本身實現(xiàn)沒問題,甚至還考慮到了 SimpleDateFormat 這個類非線程安全,所以,每次都創(chuàng)建一個新的 SimpleDateFormat 對象。
那我為什么還說它是有問題的呢?因為這種寫法是 Java 8 之前的寫法,而我們用的 Java 版本是 Java 8。
現(xiàn)在這是個Java8項目,完全可以使用 Java 8 的新日期時間API。所以項目也約定所有日期時間類型使用新API。
所以,這段代碼本身實現(xiàn)沒問題,但放在項目整體中,卻沒有和其它部分保持一致。
重構(gòu)成使用新API即可:
一個項目應(yīng)對同一個問題出現(xiàn)多個解決方案,沒有統(tǒng)一約定,成員會根據(jù)自己的習(xí)慣隨機選擇方案,導(dǎo)致方案不一致。還比如判斷字符串是否為空或空串,就有 Guava 和 Apache Commons Lang,都能做同樣事情,所以,程序員也會根據(jù)自己熟悉程度選擇其中之一來用,造成代碼不一致。
這兩個程序庫是很多程序庫的基礎(chǔ),經(jīng)常因為引入了其它程序庫,相應(yīng)的依賴就出現(xiàn)在我們的代碼中。所以,我們必須約定,哪種做法是我們在項目中的標準做法,以防出現(xiàn)各自為營。
代碼中的不一致
在翻譯引擎中創(chuàng)建作品的代碼:
- 首先,根據(jù)要處理的作品 ID,獲取其中已審核通過的作品
- 然后,發(fā)送一個 HTTP 請求在翻譯引擎中創(chuàng)建出這個作品
看得出來什么問題嗎?
這些代碼不是一個層次的!首先是獲取審核通過的作品,是個業(yè)務(wù)動作,接下來的三行其實是在做一件事,也就是發(fā)送創(chuàng)建作品的請求,這三行代碼:
- 創(chuàng)建請求的參數(shù)
- 根據(jù)參數(shù)創(chuàng)建請求
- 最后把請求發(fā)送出去
三行代碼合力完成發(fā)送創(chuàng)建作品的請求,而這件事整體才是個完整業(yè)務(wù)動作。
所以,這個函數(shù)有的是業(yè)務(wù)動作,有的是業(yè)務(wù)動作的細節(jié)。所以重構(gòu)如下:
分清代碼處于不同層次,基本功就是分離關(guān)注點。一旦分解出不同關(guān)注點,還可進一步調(diào)整代碼的結(jié)構(gòu)。
像前面拆分出來的這個方法,我們已經(jīng)知道它的作用是發(fā)出一個請求去創(chuàng)建作品,本質(zhì)上并不屬于這個業(yè)務(wù)類的一部分。
所以,還可通過引入一個新模型,將這個部分調(diào)整出去: