這周的個人項目讓我感受到自己在編程方面的不足和缺陷，所以選擇了《高效程序員的45個習慣》中的敏捷開發和敏捷調試兩個章節進行閱讀。

　　以下將對敏捷開發和敏捷調試展開詳述。

　　【敏捷開發】

• 註釋 | 以前寫代碼有時會為了寫註釋而寫註釋，既費時費力又顯得多余而無效果，其實，在代碼可以傳遞意圖的地方不要使用註釋，例如：bool isStartofWord 就無需添加註釋說明變量名含義，又如 int getLinesofFile(string filename) 也無需添加註釋說明函數用處。換言之，解釋代碼做了什麽的註釋用處不那麽大。相反，註釋要說明為什麽會這樣寫代碼。比如，對於上述的函數可以添加如下註釋：//count lines by calculate the number of ‘\n‘, and the number of lines equals the number of ‘\n‘ plus one if the file isn‘t empty.
• 增量式編程 | 不要等待著程序全部寫完後在一口氣調試，而應該采用增量式編程。每寫完一個函數就應當設計一個測試單元去測試，而且為了保證函數的魯棒性，測試單元應當進行至少一次的重構，以保證測試的有效性。類似的，每寫完一個模塊也應該進行關於該模塊的綜合測試。即采用小步伐的代碼構思，實現，測試與調整來實現代碼的推進。
• 保持簡單優雅 | 繁瑣的代碼自己查錯和修改都很痛苦，因此保持代碼的簡單優雅非常重要。優雅的代碼第一眼看上去，就知道它的用處，而且很簡潔。但是這樣的解決方案不是那麽容易想出來的。這就是說，優雅是易於理解和辨識的，但是要想創建出來就困難得多了。所以當我們覺得自己的代碼過於繁雜時，可以考慮自己的編程思路是否可以進行優化
  。
• 註意內聚 | 設計類的時候要註意控制類的規模，不要無所不含，也不要過於分散。一個類實現某一特定的功能。

　　【敏捷調試】

• 解決方案日誌 | 我們經常碰到這樣的情況，這種錯誤以前遇到過也解決過，但是就是不記得解決的措施了。一種良好的解決方法是維護一個解決方案日誌（日期，問題簡述，解決方案詳述，鏈接或者代碼片段等補充信息）。日後方便通過關鍵詞檢索快速定位解決方案。另一方面，解決方案日誌要保持輕量級和簡單，不要在記錄問題上花費比解決問題更多的時間。可以考慮Wiki等多人協作平臺進行共同維護。
• 不要忽視警告 | 不要因為是警告就放任不管！
• 單元測試 | 掌握常用的單元測試方法。

讀書筆記 | 敏捷編碼&敏捷調試