01 - 什么是好的代碼？
對開發人員來說，辨別代碼的“好”和“爛”，是個非常重要的能力，這也是我們寫出好代碼的前提。
那什么是好的代碼，我們應該從哪些維度評判代碼質量的高低呢？
答案是：很難通過某（幾）個詞匯來全面地評價代碼質量。
“評價”這個詞本身就有很強的主觀性，每個人的標准都不盡一致。但不可否認的是，越有經驗的工程師，給出的評價也就越准確。
02 - 評價代碼的標准有哪些
2.1 可維護性（maintainability）
“維護”，就是修改 bug、修改老代碼、添加新代碼之類的工作。
- “代碼易維護”，就是在不破壞原有代碼設計、不引入新 bug 的情況下，能夠快速修改或者添加代碼。
- “代碼不易維護”，就是修改或者添加代碼時很可能引入新的 bug，並且需要花費很長的時間才能完成。
大多數項目中，維護代碼的時間要遠多於編寫代碼的時間，所以代碼的可維護性非常重要。
影響代碼的可維護性的因素有很多，比如：
- 代碼的分層是否清晰，模塊化是否良好，模塊間耦合性是否足夠低（要高內聚、低耦合）；
- 項目代碼量的多少，業務的復雜程度，使用到的技術的復雜程度；
- 另外，各類過程文檔的編寫、團隊成員的開發水平等因素也會影響代碼的可維護性。
2.2 可讀性（readability）
首先，代碼被閱讀的次數要遠遠超過被編寫、修改的次數，讀不懂代碼，就很難安全地添加新功能、修復舊 bug。
代碼的可讀性，與代碼是否符合編碼規范、代碼的命名（包括類、函數、變量等）是否達意、注釋是否詳盡、函數是否長短合適、模塊划分是否清晰等因素有關。
影響代碼的可維護性的因素有很多，比如：
- Code Review（代碼審查）是個很好的測驗代碼可讀性的方法。
- 如果你的同事可以輕松讀懂你寫的代碼，說明你的代碼可讀性很好；
- 如果其他人在讀你的代碼時，有很多疑問，說明你的代碼可讀性並不高。
2.3 可擴展性（extensibility）
可擴展性表示代碼應對未來需求變化的能力。
如果原有的代碼已經預留好了擴展點（比如原代碼中抽象了很多底層可以復用的模塊），我們在修改很少代碼的情況下，添加新的功能。
這個時候，就可以說代碼的可擴展性好，也可以說成代碼的靈活性（flexibility）好。
影響代碼的可維護性的因素有很多，比如：
代碼的可讀性和可擴展性，在很大程度上決定了代碼是否有良好的維護性。
2.4 簡潔性（simplicity）
用最簡單的方法解決最復雜的問題，能做到這一點的，都是真正的大牛。
程序開發中有個很有名的 KISS 原則：“Keep It Simple, Stupid”，就是說要盡量保持代碼簡單，甚至於傻瓜化，這其實也意味着代碼易讀、易維護。
2.5 可復用性（reusability）
開發過程中，要多復用已有的代碼，盡力避免堆砌重復（相似）的代碼。
與可復用性相關的設計原則和實踐經驗有：
- 與 KISS 原則齊名的 DRY（Don’t Repeat Yourself）原則，強調的就是要提高代碼的可復用性；
- 有面向對象編程基礎的同學，應該都知道繼承、多態存在的目的之一，就是提高代碼的可復用性；
- 單一職責原則、解耦、高內聚、模塊化等實踐經驗都能提高代碼的可復用性。
2.6 可測試性（testability）
這個評判維度比較少提及，但卻是非常重要的代碼質量評價標准。
為了降低線上的故障率，我們的代碼需要通過測試環節的檢驗。可測試性良好的代碼有利於編寫單元測試，有利於我們在測試環節更全面地發現問題、更快地定位到是哪些代碼產生了這些問題。
可測試性高的代碼大多有這些特征：
職責單一；
輸入明確（可控制）；
輸出清晰（可預測）；
運算狀態（一般是錯誤狀態）可見；……
03 - 本篇總結
設計問題沒有標准答案，關鍵是我們要有自己的思考：
為什么有這種設計原則、思想或模式？
它能解決什么問題？有哪些應用場景？
該如何權衡、恰當地在項目中應用？
同時要認識到，上述評價維度 不是完全獨立 的，有些具有包含關系，也有的會互相影響。比如：
代碼的可讀性好、可擴展性好，就意味着代碼的可維護性好；
有些代碼的可擴展性和可復用性好，抽象出了很多接口、類和方法，但卻又導致代碼的可讀性和簡潔性下降。
現在，我們摸清了好代碼的樣子，也知道了好代碼的常見評判標准，接下來我們就要學習各類設計原則和設計思想了哦。
開始期待吧 😃
參考資料：
極客時間-王爭《設計模式之美》
版權聲明
出處: 博客園 瘦風的博客(https://www.cnblogs.com/shoufeng)
感謝閱讀, 右側導航欄有「瘦風的南牆」公眾號二維碼，輸出更及時、更體系，歡迎掃碼關注🤝
本文版權歸博主所有, 歡迎轉載, 但 [必須在頁面明顯位置標明原文鏈接], 否則博主保留追究相關人士法律責任的權利.