《高校程序員的45個習慣》--敏捷編碼（Ⅵ）

在開發過程當中便細心「照看」代碼！！

1、代碼要清晰的表達意圖：

　　案例1  conffeeshop.PlaceOrder(2); 

　　以上代碼，能夠大體明白是要在咖啡店裏下一個訂單，可是參數2表明什麼意思不清楚，那麼咱們能夠這麼寫

　　先定義一個枚舉，如　　 public enum CoffeeCupSize { Small, Medium, Large } 

　　接下來，能夠這樣下單， coffeeshop.PlaceOrder(CoffeeCupSize.Large) ，這樣咱們就能明白是要一個大杯咖啡了。

　　以上案例告訴咱們，要編寫清晰的而不是討巧的代碼！

2、用代碼溝通：

　　使用細心選擇的、有意義的命名；

　　解釋代碼作了什麼的註釋用處不大，相反，註釋要說明爲何會這樣寫代碼！

3、動態評估取捨：

　　沒有最佳的解決方案；

　　考慮性能、便利性、生產力、成本和上市時間；

　　即便不能面面俱到，也應該以爲已經獲得了最重要的東西--客戶認爲有價值的特性！

4、增量式編程：

　　採起增量式編程和測試，會傾向於建立更小的方法和更具內聚性的類；

　　重構代碼，重構測試；

　　要休息的話就請遠離鍵盤好好休息！

5、保持簡單：

　　簡單不是簡陋；

　　簡潔、優雅的代碼，是易於理解和辨識的；

　　太過簡單不等於簡單，那樣沒法達到溝通的目的；

6、編寫內聚的代碼：

　　若是一個組件中的成員共同完成了一個功能特性或一組功能特性，那麼這個組件就是內聚的；

　　讓類的功能儘可能集中，讓組件儘可能小；　　

　　須要高內聚、低耦合！

7、告知，不要詢問：

　　將命令與查詢分離開來；

8、根據契約進行替換：

　　保持系統靈活性的關鍵方式，是當新代碼取代原有代碼以後，其餘已有的代碼不會意識到任何差異；

　　通常狀況下，若是新類能夠替換已有的類，就要使用繼承。若是新類只是使用已有的類，那麼就用委託；

　　經過替換遵循接口契約的類，來添加並改進功能特性，要多使用委託而不是繼承；

　　相對繼承來講，委託更加靈活，適應力也更強！