最近部門(mén)在組織bootcamp，正好我負(fù)責(zé)培訓(xùn)代碼質(zhì)量部分，在培訓(xùn)課程中讓大家花了不少時(shí)間去討論、改進(jìn)、完善自己的代碼。雖然剛畢業(yè)的同學(xué)對(duì)于代碼質(zhì)量都很用心，但最終呈現(xiàn)出來(lái)的質(zhì)量仍然沒(méi)能達(dá)到“十分優(yōu)秀”的程度。 究其原因，主要是不了解好的代碼“應(yīng)該”是什么樣的。

什么是好代碼

寫(xiě)代碼的第一步是理解什么是好代碼。在準(zhǔn)備bootcamp的課程的時(shí)候，我就為這個(gè)問(wèn)題犯了難，我嘗試著用一些精確的定義區(qū)分出“優(yōu)等品”、“良品”、“不良品”;但是在總結(jié)的過(guò)程中，關(guān)于“什么是好代碼”的描述卻大多沒(méi)有可操作性

2.1.好代碼的定義

隨便從網(wǎng)上搜索了一下“優(yōu)雅的代碼”，找到了下面這樣的定義:

Bjarne Stroustrup，C++之父：

• 邏輯應(yīng)該是清晰的，bug難以隱藏;
• 依賴(lài)最少，易于維護(hù);
• 錯(cuò)誤處理完全根據(jù)一個(gè)明確的策略;
• 性能接近最佳化，避免代碼混亂和無(wú)原則的優(yōu)化;
• 整潔的代碼只做一件事。

Grady Booch，《面向?qū)ο蠓治雠c設(shè)計(jì)》作者：

• 整潔的代碼是簡(jiǎn)單、直接的;
• 整潔的代碼，讀起來(lái)像是一篇寫(xiě)得很好的散文;
• 整潔的代碼永遠(yuǎn)不會(huì)掩蓋設(shè)計(jì)者的意圖，而是具有少量的抽象和清晰的控制行。

Michael Feathers，《修改代碼的藝術(shù)》作者：

• 整潔的代碼看起來(lái)總是像很在乎代碼質(zhì)量的人寫(xiě)的;
• 沒(méi)有明顯的需要改善的地方;
• 代碼的作者似乎考慮到了所有的事情。

看起來(lái)似乎說(shuō)的都很有道理，可是實(shí)際評(píng)判的時(shí)候卻難以參考，尤其是對(duì)于新人來(lái)說(shuō)，如何理解“簡(jiǎn)單的、直接的代碼”或者“沒(méi)有明顯的需要改善的地方”?

而實(shí)踐過(guò)程中，很多同學(xué)也確實(shí)面對(duì)這種問(wèn)題：對(duì)自己的代碼總是處在一種心里不踏實(shí)的狀態(tài)，或者是自己覺(jué)得很好了，但是卻被其他人認(rèn)為很爛，甚至有幾次我和新同學(xué)因?yàn)榇a質(zhì)量的標(biāo)準(zhǔn)一連討論好幾天，卻誰(shuí)也說(shuō)服不了誰(shuí)：我們都堅(jiān)持自己對(duì)于好代碼的標(biāo)準(zhǔn)才是正確的。

在經(jīng)歷了無(wú)數(shù)次code review之后，我覺(jué)得這張圖似乎總結(jié)的更好一些：

代碼質(zhì)量的評(píng)價(jià)標(biāo)準(zhǔn)某種意義上有點(diǎn)類(lèi)似于文學(xué)作品，比如對(duì)小說(shuō)的質(zhì)量的評(píng)價(jià)主要來(lái)自于它的讀者，由個(gè)體主觀評(píng)價(jià)形成一個(gè)相對(duì)客觀的評(píng)價(jià)。并不是依靠字?jǐn)?shù)，或者作者使用了哪些修辭手法之類(lèi)的看似完全客觀但實(shí)際沒(méi)有什么意義的評(píng)價(jià)手段。

但代碼和小說(shuō)還有些不一樣，它實(shí)際存在兩個(gè)讀者：計(jì)算機(jī)和程序員。就像上篇文章里說(shuō)的，即使所有程序員都看不懂這段代碼，它也是可以被計(jì)算機(jī)理解并運(yùn)行的。

所以對(duì)于代碼質(zhì)量的定義我需要于從兩個(gè)維度分析：主觀的，被人類(lèi)理解的部分;還有客觀的，在計(jì)算機(jī)里運(yùn)行的狀況。

既然存在主觀部分，那么就會(huì)存在個(gè)體差異，對(duì)于同一段代碼評(píng)價(jià)會(huì)因?yàn)榭创a的人的水平不同而得出不一樣的結(jié)論，這也是大多數(shù)新人面對(duì)的問(wèn)題：他們沒(méi)有一個(gè)可以執(zhí)行的評(píng)價(jià)標(biāo)準(zhǔn)，所以寫(xiě)出來(lái)的代碼質(zhì)量也很難提高。

有些介紹代碼質(zhì)量的文章講述的都是傾向或者原則，雖然說(shuō)的很對(duì)，但是實(shí)際指導(dǎo)作用不大。所以在這篇文章里我希望盡可能把評(píng)價(jià)代碼的標(biāo)準(zhǔn)用(我自認(rèn)為)與實(shí)際水平無(wú)關(guān)的評(píng)價(jià)方式表示出來(lái)。

2.2.可讀的代碼

在權(quán)衡很久之后，我決定把可讀性的優(yōu)先級(jí)排在前面：一個(gè)程序員更希望接手一個(gè)有bug但是看的懂的工程，還是一個(gè)沒(méi)bug但是看不懂的工程?如果是后者，可以直接關(guān)掉這個(gè)網(wǎng)頁(yè)，去做些對(duì)你來(lái)說(shuō)更有意義的事情。

2.2.1.逐字翻譯

在很多跟代碼質(zhì)量有關(guān)的書(shū)里都強(qiáng)調(diào)了一個(gè)觀點(diǎn)：程序首先是給人看的，其次才是能被機(jī)器執(zhí)行，我也比較認(rèn)同這個(gè)觀點(diǎn)。在評(píng)價(jià)一段代碼能不能讓人看懂的時(shí)候，我習(xí)慣讓作者把這段代碼逐字翻譯成中文，試著組成句子，之后把中文句子讀給另一個(gè)人沒(méi)有看過(guò)這段代碼的人聽(tīng)，如果另一個(gè)人能聽(tīng)懂，那么這段代碼的可讀性基本就合格了。

用這種判斷方式的原因很簡(jiǎn)單：其他人在理解一段代碼的時(shí)候就是這么做的。閱讀代碼的人會(huì)一個(gè)詞一個(gè)詞的閱讀，推斷這句話(huà)的意思，如果僅靠句子無(wú)法理解，那么就需要聯(lián)系上下文理解這句代碼，如果簡(jiǎn)單的聯(lián)系上下文也理解不了，可能還要掌握更多其它部分的細(xì)節(jié)來(lái)幫助推斷。大部分情況下，理解一句代碼在做什么需要聯(lián)系的上下文越多，意味著代碼的質(zhì)量越差。

逐字翻譯的好處是能讓作者能輕易的發(fā)現(xiàn)那些只有自己知道的、沒(méi)有體現(xiàn)在代碼里的假設(shè)和可讀性陷阱。無(wú)法從字面意義上翻譯出原本意思的代碼大多都是爛代碼，比如“ms代表messageService“，或者“ms.proc()是發(fā)消息“，或者“tmp代表當(dāng)前的文件”。

2.2.2.遵循約定

約定包括代碼和文檔如何組織，注釋如何編寫(xiě)，編碼風(fēng)格的約定等等，這對(duì)于代碼未來(lái)的維護(hù)很重要。對(duì)于遵循何種約定沒(méi)有一個(gè)強(qiáng)制的標(biāo)準(zhǔn)，不過(guò)我更傾向于遵守更多人的約定。

與開(kāi)源項(xiàng)目保持風(fēng)格一致一般來(lái)說(shuō)比較靠譜，其次也可以遵守公司內(nèi)部的編碼風(fēng)格。但是如果公司內(nèi)部的編碼風(fēng)格和當(dāng)前開(kāi)源項(xiàng)目的風(fēng)格沖突比較嚴(yán)重，往往代表著這個(gè)公司的技術(shù)傾向于封閉，或者已經(jīng)有些跟不上節(jié)奏了。

但是無(wú)論如何，遵守一個(gè)約定總比自己創(chuàng)造出一些規(guī)則要好很多，這降低了理解、溝通和維護(hù)的成本。如果一個(gè)項(xiàng)目自己創(chuàng)造出了一些奇怪的規(guī)則，可能意味著作者看過(guò)的代碼不夠多。

一個(gè)工程是否遵循了約定往往需要代碼閱讀者有一定經(jīng)驗(yàn)，或者需要借助checkstyle這樣的靜態(tài)檢查工具。如果感覺(jué)無(wú)處下手，那么大部分情況下跟著google做應(yīng)該不會(huì)有什么大問(wèn)題：可以參考google code style，其中一部分有對(duì)應(yīng)的中文版。

另外，沒(méi)有必要糾結(jié)于遵循了約定到底有什么收益，就好像走路是靠左好還是靠右好一樣，即使得出了結(jié)論也沒(méi)有什么意義，大部分約定只要遵守就可以了。

2.2.3.文檔和注釋

文檔和注釋是程序很重要的部分，他們是理解一個(gè)工程或項(xiàng)目的途徑之一。兩者在某些場(chǎng)景下定位會(huì)有些重合或者交叉(比如javadoc實(shí)際可以算是文檔)。

對(duì)于文檔的標(biāo)準(zhǔn)很簡(jiǎn)單，能找到、能讀懂就可以了，一般來(lái)說(shuō)我比較關(guān)心這幾類(lèi)文檔：

1. 對(duì)于項(xiàng)目的介紹，包括項(xiàng)目功能、作者、目錄結(jié)構(gòu)等，讀者應(yīng)該能3分鐘內(nèi)大致理解這個(gè)工程是做什么的。
2. 針對(duì)新人的QuickStart，讀者按照文檔說(shuō)明應(yīng)該能在1小時(shí)內(nèi)完成代碼構(gòu)建和簡(jiǎn)單使用。
3. 針對(duì)使用者的詳細(xì)說(shuō)明文檔，比如接口定義、參數(shù)含義、設(shè)計(jì)等，讀者能通過(guò)文檔了解這些功能(或接口)的使用方法。

有一部分注釋實(shí)際是文檔，比如之前提到的javadoc。這樣能把源碼和注釋放在一起，對(duì)于讀者更清晰，也能簡(jiǎn)化不少文檔的維護(hù)的工作。

還有一類(lèi)注釋并不作為文檔的一部分，比如函數(shù)內(nèi)部的注釋?zhuān)@類(lèi)注釋的職責(zé)是說(shuō)明一些代碼本身無(wú)法表達(dá)的作者在編碼時(shí)的思考，比如“為什么這里沒(méi)有做XXX”，或者“這里要注意XXX問(wèn)題”。

一般來(lái)說(shuō)我首先會(huì)關(guān)心注釋的數(shù)量：函數(shù)內(nèi)部注釋的數(shù)量應(yīng)該不會(huì)有很多，也不會(huì)完全沒(méi)有，個(gè)人的經(jīng)驗(yàn)值是滾動(dòng)幾屏幕看到一兩處左右比較正常。過(guò)多的話(huà)可能意味著代碼本身的可讀性有問(wèn)題，而如果一點(diǎn)都沒(méi)有可能意味著有些隱藏的邏輯沒(méi)有說(shuō)明，需要考慮適當(dāng)?shù)脑黾右稽c(diǎn)注釋了。

其次也需要考慮注釋的質(zhì)量：在代碼可讀性合格的基礎(chǔ)上，注釋?xiě)?yīng)該提供比代碼更多的信息。文檔和注釋并不是越多越好，它們可能會(huì)導(dǎo)致維護(hù)成本增加。關(guān)于這部分的討論可以參考簡(jiǎn)潔部分的內(nèi)容。

2.2.4.推薦閱讀

《代碼整潔之道》

2.3.可發(fā)布的代碼

新人的代碼有一個(gè)比較典型的特征，由于缺少維護(hù)項(xiàng)目的經(jīng)驗(yàn)，寫(xiě)的代碼總會(huì)有很多考慮不到的地方。比如說(shuō)測(cè)試的時(shí)候似乎沒(méi)什么異常，項(xiàng)目發(fā)布之后才發(fā)現(xiàn)有很多意料之外的狀況;而出了問(wèn)題之后不知道從哪下手排查，或者僅能讓系統(tǒng)處于一個(gè)并不穩(wěn)定的狀態(tài)，依靠一些巧合勉強(qiáng)運(yùn)行。

2.3.1.處理異常

新手程序員普遍沒(méi)有處理異常的意識(shí)，但代碼的實(shí)際運(yùn)行環(huán)境中充滿(mǎn)了異常：服務(wù)器會(huì)死機(jī)，網(wǎng)絡(luò)會(huì)超時(shí)，用戶(hù)會(huì)胡亂操作，不懷好意的人會(huì)惡意攻擊你的系統(tǒng)。

我對(duì)一段代碼異常處理能力的第一印象來(lái)自于單元測(cè)試的覆蓋率。大部分異常難以在開(kāi)發(fā)或者測(cè)試環(huán)境里復(fù)現(xiàn)，即使有專(zhuān)業(yè)的測(cè)試團(tuán)隊(duì)也很難在集成測(cè)試環(huán)境中模擬所有的異常情況。

而單元測(cè)試可以比較簡(jiǎn)單的模擬各種異常情況，如果一個(gè)模塊的單元測(cè)試覆蓋率連50%都不到，很難想象這些代碼考慮了異常情況下的處理，即使考慮了，這些異常處理的分支都沒(méi)有被驗(yàn)證過(guò)，怎么指望實(shí)際運(yùn)行環(huán)境中出現(xiàn)問(wèn)題時(shí)表現(xiàn)良好呢?

2.3.2.處理并發(fā)

我收到的很多簡(jiǎn)歷里都寫(xiě)著：精通并發(fā)編程/熟悉多線程機(jī)制，諸如此類(lèi)，跟他們聊的時(shí)候也說(shuō)的頭頭是道，什么鎖啊互斥啊線程池啊同步啊信號(hào)量啊一堆一堆的名詞滔滔不絕。而給應(yīng)聘者一個(gè)實(shí)際場(chǎng)景，讓?xiě)?yīng)聘者寫(xiě)一段很簡(jiǎn)單的并發(fā)編程的小程序，能寫(xiě)好的卻不多。

實(shí)際上并發(fā)編程也確實(shí)很難，如果說(shuō)寫(xiě)好同步代碼的難度為5，那么并發(fā)編程的難度可以達(dá)到100。這并不是危言聳聽(tīng)，很多看似穩(wěn)定的程序，在面對(duì)并發(fā)場(chǎng)景的時(shí)候仍然可能出現(xiàn)問(wèn)題：比如最近我們就碰到了一個(gè)linux kernel在調(diào)用某個(gè)系統(tǒng)函數(shù)時(shí)由于同步問(wèn)題而出現(xiàn)crash的情況。

而是否高質(zhì)量的實(shí)現(xiàn)并發(fā)編程的關(guān)鍵并不是是否應(yīng)用了某種同步策略，而是看代碼中是否保護(hù)了共享資源：

• 局部變量之外的內(nèi)存訪問(wèn)都有并發(fā)風(fēng)險(xiǎn)(比如訪問(wèn)對(duì)象的屬性，訪問(wèn)靜態(tài)變量等)
• 訪問(wèn)共享資源也會(huì)有并發(fā)風(fēng)險(xiǎn)(比如緩存、數(shù)據(jù)庫(kù)等)。
• 被調(diào)用方如果不是聲明為線程安全的，那么很有可能存在并發(fā)問(wèn)題(比如java的hashmap)。
• 所有依賴(lài)時(shí)序的操作，即使每一步操作都是線程安全的，還是存在并發(fā)問(wèn)題(比如先刪除一條記錄，然后把記錄數(shù)減一)。

前三種情況能夠比較簡(jiǎn)單的通過(guò)代碼本身分辨出來(lái)，只要簡(jiǎn)單培養(yǎng)一下自己對(duì)于共享資源調(diào)用的敏感度就可以了。

但是對(duì)于最后一種情況，往往很難簡(jiǎn)單的通過(guò)看代碼的方式看出來(lái)，甚至出現(xiàn)并發(fā)問(wèn)題的兩處調(diào)用并不是在同一個(gè)程序里(比如兩個(gè)系統(tǒng)同時(shí)讀寫(xiě)一個(gè)數(shù)據(jù)庫(kù)，或者并發(fā)的調(diào)用了一個(gè)程序的不同模塊等)。但是，只要是代碼里出現(xiàn)了不加鎖的，訪問(wèn)共享資源的“先做A，再做B”之類(lèi)的邏輯，可能就需要提高警惕了。

2.3.3.優(yōu)化性能

性能是評(píng)價(jià)程序員能力的一個(gè)重要指標(biāo)，很多程序員也對(duì)程序的性能津津樂(lè)道。但程序的性能很難直接通過(guò)代碼看出來(lái)，往往要借助于一些性能測(cè)試工具，或者在實(shí)際環(huán)境中執(zhí)行才能有結(jié)果。

如果僅從代碼的角度考慮，有兩個(gè)評(píng)價(jià)執(zhí)行效率的辦法：

• 算法的時(shí)間復(fù)雜度，時(shí)間復(fù)雜度高的程序運(yùn)行效率必然會(huì)低。
• 單步操作耗時(shí)，單步耗時(shí)高的操作盡量少做，比如訪問(wèn)數(shù)據(jù)庫(kù)，訪問(wèn)io等。

而實(shí)際工作中，也會(huì)見(jiàn)到一些程序員過(guò)于熱衷?xún)?yōu)化效率，相對(duì)的會(huì)帶來(lái)程序易讀性的降低、復(fù)雜度提高、或者增加工期等等。對(duì)于這類(lèi)情況，簡(jiǎn)單的辦法是讓作者說(shuō)出這段程序的瓶頸在哪里，為什么會(huì)有這個(gè)瓶頸，以及優(yōu)化帶來(lái)的收益。

當(dāng)然，無(wú)論是優(yōu)化不足還是優(yōu)化過(guò)度，判斷性能指標(biāo)最好的辦法是用數(shù)據(jù)說(shuō)話(huà)，而不是單純看代碼，性能測(cè)試這部分內(nèi)容有些超出這篇文章的范圍，就不詳細(xì)展開(kāi)了。

2.3.4.日志

日志代表了程序在出現(xiàn)問(wèn)題時(shí)排查的難易程度，經(jīng)(jing)驗(yàn)(chang)豐(cai)富(keng)的程序員大概都會(huì)遇到過(guò)這個(gè)場(chǎng)景：排查問(wèn)題時(shí)就少一句日志，查不到某個(gè)變量的值不知道是什么，導(dǎo)致死活分析不出來(lái)問(wèn)題到底出在哪。

對(duì)于日志的評(píng)價(jià)標(biāo)準(zhǔn)有三個(gè)：

• 日志是否足夠，所有異常、外部調(diào)用都需要有日志，而一條調(diào)用鏈路上的入口、出口和路徑關(guān)鍵點(diǎn)上也需要有日志。
• 日志的表達(dá)是否清晰，包括是否能讀懂，風(fēng)格是否統(tǒng)一等。這個(gè)的評(píng)價(jià)標(biāo)準(zhǔn)跟代碼的可讀性一樣，不重復(fù)了。
• 日志是否包含了足夠的信息，這里包括了調(diào)用的上下文、外部的返回值，用于查詢(xún)的關(guān)鍵字等，便于分析信息。

對(duì)于線上系統(tǒng)來(lái)說(shuō)，一般可以通過(guò)調(diào)整日志級(jí)別來(lái)控制日志的數(shù)量，所以打印日志的代碼只要不對(duì)閱讀造成障礙，基本上都是可以接受的。

2.3.5.擴(kuò)展閱讀

《Release It!: Design and Deploy Production-Ready Software》(不要看中文版，翻譯的實(shí)在是太爛了)

Numbers Everyone Should Know

2.4.可維護(hù)的代碼

相對(duì)于前兩類(lèi)代碼來(lái)說(shuō)，可維護(hù)的代碼評(píng)價(jià)標(biāo)準(zhǔn)更模糊一些，因?yàn)樗獙?duì)應(yīng)的是未來(lái)的情況，一般新人很難想象現(xiàn)在的一些做法會(huì)對(duì)未來(lái)造成什么影響。不過(guò)根據(jù)我的經(jīng)驗(yàn)，一般來(lái)說(shuō)，只要反復(fù)的提問(wèn)兩個(gè)問(wèn)題就可以了：

• 他離職了怎么辦?
• 他沒(méi)這么做怎么辦?

2.4.1.避免重復(fù)

幾乎所有程序員都知道要避免拷代碼，但是拷代碼這個(gè)現(xiàn)象還是不可避免的成為了程序可維護(hù)性的殺手。

代碼重復(fù)分為兩種：模塊內(nèi)重復(fù)和模塊間重復(fù)。無(wú)論何種重復(fù)，都在一定程度上說(shuō)明了程序員的水平有問(wèn)題，模塊內(nèi)重復(fù)的問(wèn)題更大一些，如果在同一個(gè)文件里都能出現(xiàn)大片重復(fù)的代碼，那表示他什么不可思議的代碼都有可能寫(xiě)出來(lái)。

對(duì)于重復(fù)的判斷并不需要反復(fù)閱讀代碼，一般來(lái)說(shuō)現(xiàn)代的IDE都提供了檢查重復(fù)代碼的工具，只需點(diǎn)幾下鼠標(biāo)就可以了。

除了代碼重復(fù)之外，很多熱衷于維護(hù)代碼質(zhì)量的程序員新人很容易出現(xiàn)另一類(lèi)重復(fù)：信息重復(fù)。

我見(jiàn)過(guò)一些新人喜歡在每行代碼前面寫(xiě)一句注釋?zhuān)热纾?/p>

 

// 成員列表的長(zhǎng)度>0并且<200  
if(memberList.size() > 0 && memberList.size() < 200) {  
    // 返回當(dāng)前成員列表  
    return memberList;  
} 

看起來(lái)似乎很好懂，但是幾年之后，這段代碼就變成了：

 

// 成員列表的長(zhǎng)度>0并且<200  
if(memberList.size() > 0 && memberList.size() < 200 || (tmp.isOpen() && flag)) {  
// 返回當(dāng)前成員列表  
return memberList;  
} 

再之后可能會(huì)改成這樣：

 

// edit by axb 2015.07.30  
// 成員列表的長(zhǎng)度>0并且<200  
//if(memberList.size() > 0 && memberList.size() < 200 || (tmp.isOpen() && flag)) {  
// 返回當(dāng)前成員列表  
// return memberList;  
//}  
if(tmp.isOpen() && flag) {  
return memberList;  
} 

隨著項(xiàng)目的演進(jìn)，無(wú)用的信息會(huì)越積越多，最終甚至讓人無(wú)法分辨哪些信息是有效的，哪些是無(wú)效的。

如果在項(xiàng)目中發(fā)現(xiàn)好幾個(gè)東西都在做同一件事情，比如通過(guò)注釋描述代碼在做什么，或者依靠注釋替代版本管理的功能，那么這些代碼也不能稱(chēng)為好代碼。

2.4.2.模塊劃分

模塊內(nèi)高內(nèi)聚與模塊間低耦合是大部分設(shè)計(jì)遵循的標(biāo)準(zhǔn)，通過(guò)合理的模塊劃分能夠把復(fù)雜的功能拆分為更易于維護(hù)的更小的功能點(diǎn)。

一般來(lái)說(shuō)可以從代碼長(zhǎng)度上初步評(píng)價(jià)一個(gè)模塊劃分的是否合理，一個(gè)類(lèi)的長(zhǎng)度大于2000行，或者一個(gè)函數(shù)的長(zhǎng)度大于兩屏幕都是比較危險(xiǎn)的信號(hào)。

另一個(gè)能夠體現(xiàn)模塊劃分水平的地方是依賴(lài)。如果一個(gè)模塊依賴(lài)特別多，甚至出現(xiàn)了循環(huán)依賴(lài)，那么也可以反映出作者對(duì)模塊的規(guī)劃比較差，今后在維護(hù)這個(gè)工程的時(shí)候很有可能出現(xiàn)牽一發(fā)而動(dòng)全身的情況。

一般來(lái)說(shuō)有不少工具能提供依賴(lài)分析，比如IDEA中提供的Dependencies Analysis功能，學(xué)會(huì)這些工具的使用對(duì)于評(píng)價(jià)代碼質(zhì)量會(huì)有很大的幫助。

值得一提的是，絕大部分情況下，不恰當(dāng)?shù)哪K劃分也會(huì)伴隨著極低的單元測(cè)試覆蓋率：復(fù)雜模塊的單元測(cè)試非常難寫(xiě)的，甚至是不可能完成的任務(wù)。所以直接查看單元測(cè)試覆蓋率也是一個(gè)比較靠譜的評(píng)價(jià)方式。

2.4.3.簡(jiǎn)潔與抽象

只要提到代碼質(zhì)量，必然會(huì)提到簡(jiǎn)潔、優(yōu)雅之類(lèi)的形容詞。簡(jiǎn)潔這個(gè)詞實(shí)際涵蓋了很多東西，代碼避免重復(fù)是簡(jiǎn)潔、設(shè)計(jì)足夠抽象是簡(jiǎn)潔，一切對(duì)于提高可維護(hù)性的嘗試實(shí)際都是在試圖做減法。

編程經(jīng)驗(yàn)不足的程序員往往不能意識(shí)到簡(jiǎn)潔的重要性，樂(lè)于搗鼓一些復(fù)雜的玩意并樂(lè)此不疲。但復(fù)雜是代碼可維護(hù)性的天敵，也是程序員能力的一道門(mén)檻。

跨過(guò)門(mén)檻的程序員應(yīng)該有能力控制逐漸增長(zhǎng)的復(fù)雜度，總結(jié)和抽象出事物的本質(zhì)，并體現(xiàn)到自己設(shè)計(jì)和編碼中。一個(gè)程序的生命周期也是在由簡(jiǎn)入繁到化繁為簡(jiǎn)中不斷迭代的過(guò)程。

對(duì)于這部分我難以總結(jié)出簡(jiǎn)單易行的評(píng)價(jià)標(biāo)準(zhǔn)，它更像是一種思維方式，除了要理解、還需要練習(xí)。多看、多想、多交流，很多時(shí)候可以簡(jiǎn)化的東西會(huì)大大超出原先的預(yù)計(jì)。

2.4.4.推薦閱讀

• 《重構(gòu)-改善既有代碼的設(shè)計(jì)》
• 《設(shè)計(jì)模式-可復(fù)用面向?qū)ο筌浖幕A(chǔ)》
• 《Software Architecture Patterns-Understanding Common Architecture Patterns and When to Use Them》

3.結(jié)語(yǔ)

這篇文章主要介紹了一些評(píng)價(jià)代碼質(zhì)量?jī)?yōu)劣的手段，這些手段中，有些比較客觀，有些主觀性更強(qiáng)。之前也說(shuō)過(guò)，對(duì)代碼質(zhì)量的評(píng)價(jià)是一件主觀的事情，這篇文章里雖然列舉了很多評(píng)價(jià)手段。但是實(shí)際上，很多我認(rèn)為沒(méi)有問(wèn)題的代碼也會(huì)被其他人吐槽，所以這篇文章只能算是初稿，更多內(nèi)容還需要今后繼續(xù)補(bǔ)充和完善。

雖然每個(gè)人對(duì)于代碼質(zhì)量評(píng)價(jià)的傾向都不一樣，但是總體來(lái)說(shuō)評(píng)價(jià)代碼質(zhì)量的能力可以被比作程序員的“品味”，評(píng)價(jià)的準(zhǔn)確度會(huì)隨著自身經(jīng)驗(yàn)的增加而增長(zhǎng)。在這個(gè)過(guò)程中，需要隨時(shí)保持思考、學(xué)習(xí)和批判的精神。