?在作者的工作經歷中，每當同事評論項目代碼質量的時候，作者聽到最多的評論是“代碼 寫得很爛”或“代碼寫得很好”。作者認為，用“好”“爛”這樣的字眼來描述代碼質量是非常 籠統的。當作者詢問代碼到底“爛”在何處或“好”在哪里時，盡管大部分同事都能簡單地羅列幾個“爛”的方面或好的方面，但他們的回答往往都不夠全面，知識點零碎， 也無法切中要害。

當然，也有一些軟件工程師對如何評價代碼質量有所認識，如認為好代碼是易擴展、易讀、 簡單、易維護的，等等，但他們對于這些評價的理解往往只停留在表面上，對于諸多更加深入 的問題， 如“怎么才算可讀性好？什么樣的代碼才算易擴展、易維護？可讀、可擴展與可維護 之間有什么關系？可維護中的‘維護’兩字該如何理解？”，等等，他們并沒有太清晰的認識。

實際上，對于代碼質量的描述，除“好”“爛”這樣比較簡單、籠統的描述方式以外，還 有很多語義豐富、專業和細化的描述方式，如下所示：

靈活性（?exibility）、可擴展性（extensibility）、可維護性（maintainability）、可讀性（readability）、 可理解性（understandability）、易修改性（changeability）、可復用性（reusability）、可測試性（testability）、模塊化（modularity）、高內聚低耦合（high cohesion loose coupling）、高效（high e?ciency）、高性能（high performance）、安全性（security）、兼容性（compatibility）、易用 性（usability）、簡潔（clean）、清晰（clarity）、簡單（simple）、直接（straightforward）、少 即是多（less code is more）、文檔詳盡（well-documented）、分層清晰（well-layered）、正確 性（correctness 、bug free）、健壯性（robustness）、魯棒性（robustness）、可用性（reliability）、 可伸縮性（scalability）、穩定性（stability）和優雅（elegant）等。

面到如此多的詞匯，我們到底應該使用哪些詞匯來描述一段代碼的質量呢？

實際上，我們很難通過其中的某個或某幾個詞匯來全面地評價代碼質量，因為這些詞匯是 從不同角度描述代碼質量的。例如，在評價一個人的時候，我們往往通過多個方面進行綜合評 價，如性格、能力等，否則，對一個人的評價可能是片面的。同樣，對于代碼質量，我們也需 要綜合多種因素進行評價，不應該從單一的角度去評價。例如，一段代碼的可擴展性很好，但 可讀性很差，那么，我們不能片面地認為這段代碼的質量高。

注意，不同的評價角度并不是完全獨立的，有些之間存在包含關系、重疊關系等，或者可 以互相影響。例如，代碼的可讀性和可擴展性好，可能意味著代碼的可維護性好。而且，各種 評價角度不是“非黑即白”。例如，我們不能簡單地將代碼評價為可讀或不可讀。如果用數字 來量化代碼的可讀性，那么應該是一個連續的區間值，而非 0 、 1 這樣的離散值。

不過，我們真的可以客觀地量化一段代碼的質量嗎？答案是否定的。對一段代碼質量的評 價，常常帶有很強的主觀性。例如，對于什么樣的代碼才算是可讀性好，每個人的評判標準都 不一樣。

正是因為代碼質量評價的主觀性，使得這種主觀評價的準確度與軟件工程師自身的經驗有 極大的關系。軟件工程師的經驗越豐富，給出的評價往往越準確。形成對比的是，資歷較淺的 軟件工程師常常覺得沒有一個可量化的評價標準作為參考，很難準確判斷一段代碼的質量。如 果無法辨別代碼寫得好或壞，那么，即使寫再多的代碼，編碼能力也可能沒有太大提高。

在仔細閱讀前面羅列的代碼質量評價標準之后，讀者會發現，有些詞匯過于籠統、抽象， 而且偏向于對整體的描述，如優雅、好、壞、整潔和清晰等；有些過于注重細節、偏重方法 論，如模塊化、高內聚低耦合、文檔詳盡和分層清晰等；有些可能并不僅僅局限于編碼，與架 構設計等也有關系，如可伸縮性、可復用性和穩定性等。

為了讀者有重點地進行學習，作者挑選了7 個常用且重要的評價標準來詳細講解，包括可 維護性、可讀性、可擴展性、靈活性、簡潔性、可復用性和可測試性。

1.可維護性（maintainability）

對于代碼開發，“維護”無外乎修改 bug、修改舊的代碼和添加新的代碼等?！按a易維護” 是指， 在不破壞原有代碼設計、不引入新的 bug 的情況下， 能夠快速修改或添加代碼。“代碼 不易維護”是指，修改或添加代碼需要冒極大的引入新 bug 的風險，并且需要很長的時間才能 完成。

對于一個項目，維護代碼的時間可能遠遠大于編寫代碼的時間。軟件工程師可能將大部分 時間花在修復 bug、修改舊的功能邏輯和添加新的功能邏輯之類的工作上。因此，代碼的可維 護性就顯得格外重要。

對于維護、易維護和不易維護這 3 個概念，我們不難理解。不過，對于實際的軟件開發，更重要的是需要清楚如何判斷代碼可維護性的高低。

實際上，可維護性是一個難以量化、偏向對代碼整體進行評價的標準，它類似之前提到的 “好”“壞”“優雅”之類的籠統評價。代碼的可維護性高低是由很多因素共同作用的結果。代 碼簡潔、可讀性好、可擴展性好，往往就會使得代碼易維護。更深入地講，如果代碼分層清 晰、模塊化程度高、高內聚低耦合、遵守基于接口而非實現編程的設計原則等，就可能意味著 代碼易維護。除此之外，代碼的易維護性還與項目的代碼量、業務的復雜程度、技術的復雜程 度、文檔的全面性和團隊成員的開發水平等諸多因素有關。

2.可讀性（readability）

軟件設計專家 Martin Fowler 曾經說過：“Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ”（任何人都可以編寫計算機能理解的 代碼， 而好的程序員能夠編寫人能理解的代碼。）在 Google 內部， 有一個稱為“Readability” 的認證。只有拿到這個認證的軟件工程師，才有資格在 Code Review 的時候批準別人提交的代 碼?？梢?，代碼的可讀性有多么重要，畢竟，代碼被閱讀的次數有時候遠遠超過被編寫和執行 的次數。

代碼的可讀性如此重要，在編寫代碼的時候，我們要時刻考慮代碼是否易讀、易理解。代 碼的可讀性在很大程度上會影響代碼的可維護性，因為無論是修復 bug 還是添加 / 修改功能代 碼，我們首先要讀懂代碼。如果我們對代碼一知半解，就有可能因為考慮不周而引入新 bug 。

既然代碼的可讀性如此重要，那么我們如何評判一段代碼的可讀性呢？

我們需要查看代碼是否符合代碼規范，如命名是否達意、注釋是否詳盡、函數長度是否合 適、模塊劃分是否清晰， 以及代碼是否“高內聚、低耦合”等。除此之外，Code Review 也是 一個很好的測試代碼可讀性的手段。如果我們的同事可以輕松地讀懂我們寫的代碼，往往能夠 說明我們的代碼的可讀性不差；如果同事在讀我們寫的代碼時，有很多疑問，那么可能在提示 我們，代碼的可讀性存在問題，需要重點關注。

3.可擴展性（extensibility）

代碼的可擴展性是指在不修改或少量修改原有代碼的情況下，能夠通過擴展方式添加新功 能代碼。換句話說，代碼的可擴展性是指在編寫代碼時預留了一些功能擴展點，我們可以把新 功能代碼直接插入擴展點，而不會因為添加新的功能代碼而改動大量的原始代碼?？蓴U展性也 是評價代碼質量的重要標準。代碼的可擴展性表示代碼應對未來需求變化的能力。與代碼的可 讀性一樣，代碼是否易擴展也在很大程度上決定了代碼是否易維護。

4.靈活性（flexibility）

靈活性也可以用來描述代碼質量。例如， 我們經常會聽到這樣的描述：“代碼寫得很靈 活”。那么，我們如何理解這里提到的“靈活”呢？

盡管很多人用“靈活”描述代碼質量，但實際上，“靈活”是一個抽象的評價標準，給“靈活”下定義是很難的。不過，我們可以想一下，我們在什么情況下才會說代碼寫得很靈活呢？

作者羅列了 3 種場景，幫助讀者理解什么是代碼的靈活性。

1）當我們添加新功能代碼時，由于原有代碼中已經預留了擴展點，因此，我們不需要修 改原有代碼，只需要在擴展點上添加新代碼。這個時候，我們除可以說代碼易擴展以外，還可 以說代碼寫得很靈活。

2）當我們要實現一個功能時，如果原有代碼中已經抽象出了很多位于底層且可復用的模 塊、類等，那么我們可以直接使用。這個時候，我們除可以說代碼易復用以外，還可以說代碼 寫得很靈活。

3）當我們使用某個類時，如果這個類可以應對多種使用場景，滿足多種不同需求，那么， 我們除可以說這個類易用以外，還可以說這個類設計得很靈活或代碼寫得很靈活。

從上述場景來看，如果一段代碼易擴展、易復用，或者易用，我們一般可以認為這段代碼 寫得很靈活。因此，“靈活”的含義寬泛，很多場景都可以使用。

5.簡潔性（simplicity）

有一條非常著名的設計原則，大部分讀者應該都聽過，那就是 KISS 原則：“Keep It Simple ，Stupid”。該原則的意思是“盡量保持代碼簡單”。代碼簡單、邏輯清晰往往意味著代 碼易讀、易維護。在編寫代碼的時候，我們往往會把“簡單、清晰”原則放到首位。

不過，很多編程經驗不足的程序員會覺得，簡單的代碼沒有技術含量，喜歡在項目中引入 一些復雜的設計模式，覺得這樣才能體現自己的技術水平。實際上，思從深而行從簡，真正的 編程高手往往能用簡單的方法解決復雜的問題。

除此之外，雖然我們都能認識到，代碼要盡量寫得簡潔，要符合 KISS 原則，但怎樣的代 碼才算足夠簡潔？怎樣的代碼才算符合 KISS 原則呢？實際上，不是每個人都能準確地做出判 斷，因此，在第 3 章介紹 KISS 原則的時候，我們會通過具體的代碼示例詳細說明。

6.可復用性（reusability）

我們可以將代碼的可復用性簡單地理解為“盡量減少重復代碼的編寫，復用已有代碼”。 在后續章節中，我們會經常提到“可復用性”這一代碼評價標準。例如，當介紹面向對象特性 的時候，我們會提到繼承、多態存在的目的之一就是提高代碼的可復用性；當介紹設計原則的 時候，我們會提到單一職責原則與代碼的可復用性相關；當介紹重構技巧的時候，我們會提到 解耦、高內聚和模塊化等能夠提高代碼的可復用性。可見，可復用性是一個重要的代碼評價標 準，也是很多設計原則、設計思想和設計模式等所要實現的最終效果。

實際上，代碼的可復用性與 DRY（Don’t Repeat Yourself）原則的關系緊密，因此，在第 3 章介紹 DRY 原則的時候，我們還會介紹代碼復用相關的更多知識，如提高代碼的可復用性的 編程方法等。

7.可測試性（testability）

相比上述 6 個代碼質量評價標準，代碼的可測試性較少被提及，但它同樣重要。代碼的可 測試性的高低可以從側面準確地反映代碼質量的高低。代碼的可測試性低，難以編寫單元測試，那么，基本能夠說明代碼的設計有問題。?