什麼是好的代碼-代碼Review要點

自描述

命名恰當規範，看名字就知道意思。包括包、類、方法、變量等等，而不是靠註釋去理解。當你須要註釋才能描述清楚你想幹嗎，請思考一下，可否從命名就說清楚？除非是在不行，不然不要依賴註釋。

註釋的一個壞處是，你不能保證註釋和代碼是同步的。當你因爲某些緣由改了代碼，而沒有修改註釋，這時候註釋是誤導人的，還不如沒有。

註釋會帶來代碼的噪音。遍及代碼裏的註釋，讓你沒法抓住代碼要點，而是要費勁去閱讀註釋。

簡單

簡單容易理解的代碼就是短的代碼。有有限的行數（方法低於10行是個不錯的標準，低於7行是個更好的標準，再低可能不容易作到），較少的縮進層次（兩層之內，最多不高於3層）。

過長的方法多是由於你違反了單一職責原則。試着對方法進行重構，對方法裏的代碼進行分層。每一個方法只幹一件事兒，減小代碼的行數。

過大的類也是一種複雜。試着重構，將類的職責分離出來，保持類的單一職責。對於複雜邏輯，嘗試用經常使用設計模式，如類工廠等方法將一些邏輯分佈到其餘類中。

容易修改

當你把相同緣由相同時間變化的放到一塊兒，不一樣緣由不一樣時間變化的分開，代碼就容易修改。從縱向上，把UI、業務邏輯、數據庫訪問等分開，高層的業務邏輯和底層的UI數據庫解耦；從橫向上，不一樣的UseCase分開爲不一樣的模塊。這樣代碼會更容易修改。

面向對象賦予咱們的利器：多態。進而實現依賴反轉。從而讓各個層次能夠很方便用抽象解耦，一個層內部的修改，不會影響到其餘層。

Open-Close原則，面向擴展開放，面向修改關閉。在增長新功能的時候，不須要或者極少須要修改原來代碼。這樣才能避免引入新的Bug。

容易測試

依賴簡單的、職責單一的代碼就容易測試。輕易Mock少數接口（甚至不須要），就能夠完成對業務邏輯的單元測試。當你發現你的代碼很難測試，極有多是你代碼作了太多的事兒，或者沒有好好隱藏內部實現，致使調用者很是複雜。

若是你的對外依賴不容易經過Mock替代進行測試，說明你的代碼違反了里氏替換原則。從新設計其餘依賴，用接口進行隔離。

高效的

採用恰當的方法，是系統可以高效運行。好比沒必要要的打包解包、無謂的循環、頻繁的鎖競爭。固然對效率的優化首先要考慮代碼前面幾個原則，除非很是必要，不要以犧牲可讀性、可測試等特性爲代價。