高效程序員的45個習慣 敏捷開發修煉之道 讀書筆記 第六章 敏捷編碼

代碼要清晰地表達意圖（PIE原則 program intently and expressively）

這個問題強調過不少遍的。

命名問題參見：代碼整潔之道,對命名問題講得很好。

要編寫清晰的而不是討巧的代碼。向代碼閱讀者明確代表你的意圖。可讀性差的代碼一點都不聰明。

如今對弈顯而易見的事情，對別人可能並不是如此，對於一年之後的你來講，也不必定顯而易見。

 

用代碼溝通

用註釋溝通。使用細心選擇的、有意義的命名。用註釋描述代碼意圖和約束。註釋不能替代優秀的代碼。

註釋就像是是能夠幫助你的好朋友，能夠先閱讀註釋，而後快速瀏覽代碼，從而徹底理解它作了什麼，以及爲何這樣作。

 

動態評估取捨

動態評估權衡。考慮性能、便利性、生產力、成本和上市時間。若是性能表現足夠了，就將注意力放在其餘因素上。

不要爲了感受上的性能提高或者設計的優雅，而將設計複雜化。

不要過分設計，最重要是適合，即便不能面面俱到，你也應該以爲已經獲得了最重要的東西--客戶認爲有價值的特性。

 

增量式編程與測試（指編程的時候）

在很短的編程/構建/測試循環中編寫代碼。這要比花費長時間僅僅作編寫代碼的工做好得多。能夠建立更加清晰、簡單、易於維護的代碼。

長時間編碼後再想測試，出的問題每每容易摸不着頭腦，不利於在代碼中發現問題。

頁面測試、控件測試、頁面功能實現後測試我通常分爲。

 

保持簡單、編寫內聚的代碼

開發能夠工做的、最簡單的解決方案。除非有不可辯駁的緣由，不然不要使用模式、原則和高難度技術之類的東西。

讓類的功能儘可能集中。讓主鍵儘可能小。要避免建立很大的類或組件，也不要建立無所不包的大雜燴類。

體會項目分類準確，圖片、IO、控件等等相應的工具類要分好地方，在項目中不要出現類似名字的類也不要出現常常性複製代碼，以前在公司的項目就存在不少代碼重複的地方，一控件作的不夠可擴展，二是一些工具類沒有設計相應的存放的地方，致使這些類在其餘包不可見，只能複製過去。

 

告知，不要詢問

 命令與查詢相分離模式（command-query separation），將功能和方法分爲這兩類並在源碼中記錄下來。

不要搶別的對象或是組件的工做。告訴它作什麼，而後盯着本身的職責就行了。

不能容許一個看起來無辜的查詢去修改對象的狀態

 

根據契約進行替換

當使用繼承時要想一想派生類是否能夠替換基類，若是答案是不能，而是但願在編寫新類的時候重用基類中的代碼，也須要考慮轉而使用聚合。

經過替換代碼來擴展系統。經過替換循環接口契約的類，來添加並改進功能特性。