軟體測試管理之如何評價代碼品質？

代碼品質的評價有很強的主觀性

最常用的評價标準有可維護性、可讀性、、可擴充性、靈活性、簡潔性、可複用性、可測試性。

一、可維護性

我們先來看看幾個概念

　　維護：是指修改bug、修改撈的代碼、添加新的代碼之類的工作；

　　代碼易維護：指不破壞原有代碼設計、不引入新的 bug 的情況下，能夠快速地修改或者添加代碼；

　　代碼不易維護：指修改或者添加代碼需要冒着極大的引入新 bug 的風險，并且需要花費很長的時間才能完成。

　　我們可以從側面上給出一個比較直覺但又比較準确的感受。

　　如果 bug 容易修複、修改、添加功能也能輕松完成，那我們就可以主觀的認為代碼對我們來說是易維護的。

　　是否易維護本來就是針對維護的人來說的，不同水準的人對于同一份代碼的維護能力也是不相同的，而且對系統的熟悉程度也占很大的主觀因素。

　　二、可讀性

　　如何評價一段代碼的可讀性呢？

　　很難給出一個覆寫所有評價名額的清單，比如是否符合編碼規範、命名是否達意、注釋是否詳盡、函數是否長短合适、子產品是否清晰、是否符合高内聚低耦合等等。

　　實際上，code review 是一個很好的檢測代碼可讀性的手段。如果别人可以輕松讀懂你寫的代碼，那說明你的代碼可讀性很好；如果同僚讀你的代碼時，有很多疑問，那就說明你的代碼可讀性有待提高了。

　　三、可擴充性

　　在不修改或少量修改原有代碼的情況下，通過擴充的方式添加新的功能代碼。

　　說直白點就是，代碼預留了一些功能擴充點，你可以把新功能代碼，直接插到擴充點上，而不需要一位添加一個功能而大東幹戈，改動大量的原始代碼。

　　開閉原則

　　添加一個新的功能，應該是通過在已有代碼基礎上擴充代碼（新增子產品、類、方法、屬性等），而非修改已有代碼（修改子產品、類、方法、屬性等）的方式來完成。

　　關于定義，我們有兩點要注意。第一點是，開閉原則并不是說完全杜絕修改，而是以最小的修改代碼的代價來完成新功能的開發。第二點是，同樣的代碼改動，在粗代碼粒度下，可能被認定為“修改”；在細代碼粒度下，可能又被認定為“擴充”。

　　四、靈活性

　　靈活這個詞的含義非常寬泛，很多場景下都可以使用功能。如果一段代碼易擴充、易複用或者易用，都可以稱字段代碼寫得比較靈活

　　五、簡潔性

　　KISS 原則：“Keep It Simple, Stupid” 。盡量保持代碼簡單。

　　KISS 原則是保持代碼可讀和可維護的重要手段。KISS 原則中的“簡單”并不是以代碼行數來考量的。代碼行數越少并不代表代碼越簡單，我們還要考慮邏輯複雜度、實作難度、代碼的可讀性等。而且，本身就複雜的問題，用複雜的方法解決，并不違背 KISS 原則。除此之外，同樣的代碼，在某個業務場景下滿足 KISS 原則，換一個應用場景可能就不滿足了。

　　KISS原則

　　對于如何寫出滿足 KISS 原則的代碼，有幾條指導原則：

　　· 不要使用同僚可能不懂的技術來實作代碼；

　　· 不要重複造輪子，要善于使用已經有的工具類庫；

　　· 不要過度優化。

　　六、可複用性

　　可以簡單地了解為，盡量減少重複代碼的編寫。

　　代碼可複用性和 DRY （Don't Repeat Yourself/不要重複自己）這條設計原則的關系挺緊密的。

　　DRY原則

　　三種代碼重複的情況：實作邏輯重複、功能語義重複、代碼執行重複。

　　· 實作邏輯重複，但功能語義不重複的代碼，并不違反 DRY 原則。

　　· 實作邏輯不重複，但功能語義重複的代碼，也算是違反 DRY 原則。

　　· 除此之外，代碼執行重複也算是違反 DRY 原則。

　　提高代碼可複用性的一些方法，有以下 7 點。

　　· 減少代碼耦合

　　· 滿足單一職責原則

　　· 子產品化

　　· 業務與非業務邏輯分離

　　· 通用代碼下沉

　　· 繼承、多态、抽象、封裝

　　· 應用模闆等設計模式

　　七、可測試性

　　代碼可測試性的好壞，能從側面上非常準确地反應代碼品質的好壞。

　　代碼的可測試差，比較難寫單元測試，那基本上就能說明代碼設計得有問題。

　　1. 什麼是代碼的可測試性？

　　粗略地講，所謂代碼的可測試性，就是針對代碼編寫單元測試的難易程度。對于一段代碼，如果很難為其編寫單元測試，或者單元測試寫起來很費勁，需要依靠單元測試架構中很進階的特性，那往往就意味着代碼設計得不夠合理，代碼的可測試性不好。

　　2. 編寫可測試性代碼的最有效手段

　　依賴注入是編寫可測試性代碼的最有效手段。通過依賴注入，我們在編寫單元測試的時候，可以通過mock（模拟）的方法解依賴外部服務，這也是我們在編寫單元測試的過程中最有技術挑戰的地方。

　　3. 常見的 Anti-Patterns（反面模式）

　　常見的測試不友好的代碼有下面這 5 種：

　　· 代碼中包含未決行為邏輯（所謂的未決行為邏輯就是，代碼的輸出是随機或者說不确定的，比如，跟時間、随機數有關的代碼。）

　　· 濫用可變全局變量

　　· 濫用靜态方法

　　· 使用複雜的繼承關系

　　· 高度耦合的代碼