[[429094]]

我們提供的服務(wù)有：網(wǎng)站設(shè)計制作、成都網(wǎng)站設(shè)計、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、仙居ssl等。為超過千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的仙居網(wǎng)站制作公司

大家所在項目組，一定遇到同類操作，但卻有不同做法，尤其是祖?zhèn)鞔a，一眼望去，可謂八仙過海各顯神通。

大部分程序員也覺得團(tuán)隊開發(fā)應(yīng)該保持編程習(xí)慣的一致性。但普遍理解的一致性都表現(xiàn)在較宏觀層面，比如，數(shù)據(jù)庫訪問是叫DAO還是叫Mapper，Repository?

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

千奇百怪的命名

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

• 網(wǎng)站
• 只在Kindle
• 全渠道

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

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

Yes

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

(⊙o⊙)…好像也是哦

所以，大家也看到了吧，類似含義的代碼應(yīng)該有一致的名稱，就像很多團(tuán)隊都會把業(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í)慣隨機(jī)選擇方案，導(dǎo)致方案不一致。還比如判斷字符串是否為空或空串，就有 Guava 和 Apache Commons Lang，都能做同樣事情，所以，程序員也會根據(jù)自己熟悉程度選擇其中之一來用，造成代碼不一致。

這兩個程序庫是很多程序庫的基礎(chǔ)，經(jīng)常因為引入了其它程序庫，相應(yīng)的依賴就出現(xiàn)在我們的代碼中。所以，我們必須約定，哪種做法是我們在項目中的標(biāo)準(zhǔ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ù)動作的細(xì)節(jié)。所以重構(gòu)如下：

分清代碼處于不同層次，基本功就是分離關(guān)注點(diǎn)。一旦分解出不同關(guān)注點(diǎn)，還可進(jìn)一步調(diào)整代碼的結(jié)構(gòu)。

像前面拆分出來的這個方法，我們已經(jīng)知道它的作用是發(fā)出一個請求去創(chuàng)建作品，本質(zhì)上并不屬于這個業(yè)務(wù)類的一部分。

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

 

當(dāng)前標(biāo)題：你真的思考過自己寫的代碼為啥這么垃圾嗎？
網(wǎng)站路徑：http://uogjgqi.cn/article/djjghcd.html