[[429099]]

有讀者看到標(biāo)題就開始敲鍵盤了，這還需要寫個文章來水?命名不就是不能用 abc、123 這種，名字要有意義嘛，這有啥好講的?

但現(xiàn)實中，雖然懂得名字要有意義，很多程序員依然無法逃離命名沼澤。

萬金油命名法

什么叫精準(zhǔn)?

看段代碼：

看上去不是挺正常嗎?有何不可?

那我問你，這段代碼在干嘛?你就得全神貫注去閱讀代碼細(xì)節(jié)了。已閱后，你說這段代碼不就是把一個章節(jié)的翻譯狀態(tài)改成翻譯中。

為何你得閱完這段代碼細(xì)節(jié)，才知道該方法在干嘛?

問題就在方法名 - processChapter，該方法是在處理章節(jié)沒錯，但這名太寬泛。如果說“將章節(jié)的翻譯狀態(tài)改成翻譯中”就叫處理章節(jié)，那么請問：

• 將章節(jié)的翻譯狀態(tài)改成翻譯完畢
• 修改章節(jié)內(nèi)容

是不是也能叫處理章節(jié)呢?

所以，這的確是個過于寬泛的方法名，沒有大錯，但不精確!

乍一看，這名字有含義，但實際卻不能有效反映這段代碼的具體含義。

若做的是個信息處理系統(tǒng)，你根本無法判斷，這是個博客平臺還是個圖書管理系統(tǒng)呢?

從溝通角度看，這就不是一個有效信息表達。想理解它，需要消耗大量時間精力。

命名過于寬泛，不能精確描述，這是很多代碼命名現(xiàn)狀，也是讓祖?zhèn)鞔a難以理解的根因。

回想這些命名：data、info、flag、process、handle、build、maintain、manage、modify......

這些都屬于 過于寬泛的命名，當(dāng)這些名字出現(xiàn)在你的代碼，可以肯定作者當(dāng)時也沒想好用啥名字，就開始隨便起個萬金油名字繼續(xù)coding了。

扯半天，那它不能叫處理章節(jié)，那該叫啥?

• 命名要能精確描述該方法在做什么

這段代碼就是“將章節(jié)改為翻譯中”。那是不是該叫 changeChapterToTranlsating?相比處理章節(jié)，這個名字已經(jīng)算進步了，但也不算是個好名字，因為它更多的是在描述這段代碼在做的細(xì)節(jié)。而封裝一段代碼成方法，就是因為我們不想知道過多細(xì)節(jié)。如果把細(xì)節(jié)平鋪開來，那就和直接讀代碼細(xì)節(jié)沒啥區(qū)別了。

• 好名字應(yīng)該描述意圖，而非細(xì)節(jié)

這段代碼為何要將翻譯狀態(tài)修改成翻譯中呢?一定是有所圖的。把翻譯狀態(tài)改成翻譯中，是因為我們在這里開啟了一個翻譯的過程。所以，這個方法應(yīng)該叫 startTranslation

技術(shù)術(shù)語命名法

再看一段代碼：

這!也能有問題?我天天看到還寫這種代碼啊。

是的，我知道你們都在寫這種風(fēng)格代碼，這就是另一個經(jīng)典問題：技術(shù)術(shù)語命名法。

之所以叫 bookList，在于其聲明類型是 List。這種命名幾乎隨處可見，如 xxMap、xxSet。

這也是種不費腦命名法，但這種命名卻會帶來很多問題，因為是基于技術(shù)實現(xiàn)細(xì)節(jié)的命名方式。

我們都知道面向接口編程原則，就是不要面向?qū)崿F(xiàn)編程，因為接口是穩(wěn)定的，而實現(xiàn)易變不穩(wěn)定。大多數(shù)人只覺得該原則是針對類型的，但命名方面，也同樣應(yīng)該遵循。比如，我發(fā)現(xiàn)現(xiàn)在需要的是個不重復(fù)作品集合，即我得把這個變量的類型從 List 改成 Set。變量類型相信你一定會改，但變量名你會改嗎?還真不一定，一旦忘了，就會出現(xiàn)：一個 bookList 變量，居然是Set類型!

那怎么命名呢?得有個更能表達意圖的名字，這段代碼表達的就是拿到一堆書，所以可以叫 books。

這名字更簡單，也很表達意圖了。

追根究底，使用技術(shù)名詞，一般因為它缺少對應(yīng)模型。

比如，在業(yè)務(wù)代碼里若直接出現(xiàn) Redis：

通常來說，這里真正需要的是個緩存。Redis 只是緩存模型的一個具體實現(xiàn)：

但其實緩存這個概念也是個技術(shù)專業(yè)術(shù)語，也不應(yīng)出現(xiàn)在業(yè)務(wù)代碼中。

做得好的是 Spring，使用 Spring 時，若需要緩存，一般是加個注解：

很多人愛用技術(shù)名詞去命名，大多因為：

• 熟悉的語言
• 寫代碼，很多都是參考別人代碼，優(yōu)秀代碼都是一些開源技術(shù)項目。那在一個技術(shù)類項目中，這些技術(shù)術(shù)語其實也就是它的業(yè)務(wù)語言。但對于我們的業(yè)務(wù)類項目，就不能生搬硬套了

若該部分確實就是處理一些技術(shù)，使用技術(shù)術(shù)語無可厚非，但若是在處理業(yè)務(wù)，就要盡可能規(guī)避技術(shù)術(shù)語。

像xxMap這種命名，表示映射關(guān)系，如：書id與書的映射關(guān)系，難道也不能命名為bookIdMap?

Map 表示的是個數(shù)據(jù)結(jié)構(gòu)，而映射關(guān)系推薦寫成 Mapping。

高級點的壞味道

前面的壞味道其實本質(zhì)都是同一問題：對業(yè)務(wù)理解不到位。

編寫可維護的代碼要使用業(yè)務(wù)語言。那如何知道自己的命名是否用的是業(yè)務(wù)語言呢?

把這個詞講給PM聽，看他懂是啥不。

團隊里若每個人都根據(jù)自己理解命名，就可能出現(xiàn)百家爭鳴的命名，所以，一個良好的團隊實踐是建立團隊的業(yè)務(wù)詞匯表，統(tǒng)一業(yè)務(wù)命名。

當(dāng)團隊對業(yè)務(wù)有了一致的理解后，興許還能發(fā)現(xiàn)更高級的壞味道：

看方法名，應(yīng)該是確認(rèn)章節(jié)內(nèi)容審核通過。

但我有一問，chapterId 是審核章節(jié)的 ID，這沒問題，但 userId 是啥?了解背景后，才知道這里要 userId，是因為需要記錄審核人信息。

通過業(yè)務(wù)的分析，就發(fā)現(xiàn)，這個 userId 不是個好名字，因為它還需要更多解釋，更好的命名是 reviewerUserId，因為這用戶在當(dāng)前場景下就是審核人(Reviewer)角色。

這也是一種萬金油命名法，但它不是那種一眼就能看出的壞味道，而是需要在業(yè)務(wù)層進行討論，所以，算個高級壞味道。