閱讀《馴服爛代碼》

在新做一個項目之前閱讀了本書，記錄下印象深刻的部分。
作者剛開始描述的做酒店時鐘系統的開發流程。由文檔到設計到系統，完全按照正常的開發流程。作者採用領域模型訂閱和術語表定義的方式明確需求。然後用領域模型圖和用例圖進行分析，採用適當的設計模式。這些過程都感覺沒什麼問題。當系統採用main函數進行調用驗證結果的時候，感覺開發的過程中應該有單元測試的（這也是開發思維的進步）。這種開發的過程中，文檔跟不上代碼的修改，大多數情況下都會發生。
在測試驅動開發重做系統的過程中，事情變得很不一樣。我瞭解到，採用用戶故事來描寫產品特性。（用戶故事：作爲<角色>,我想<實現目標>來<獲得收益>。 不牽扯細節，作爲溝通的指路牌）。通過預先定義預期結果的方式，來反推生產代碼。以前一直以爲讓測試很快通過的方式很醜陋，現在來想，這是作者表明小步開發思想的方式。在相應的位置，記錄要進行的任務，然後不斷的實現特性，重構代碼。(重構，要不斷進行，書也應該不斷閱讀，能夠發現代碼的壞味道，並且知道解決方案）。
測試驅動開發，那麼，新增加的測試，應該是能夠促進生產代碼的修改的。其他的全面性測試，可以放到後面做。這時作者也提出，隨着對系統不斷的加深理解，可以不根據編譯錯誤來解決問題。
凡是沒有全面測試代碼的代碼都是遺留代碼，那麼，我好像到現在開發的都是遺留代碼。
對遺留代碼的重構過程中，應該以接口爲閱讀切入點。此時，我們不能急於修改代碼，而應該是記錄可以重構的地方和原因。最後再逐個解決需要修改的問題。
在開發過程中，我們要針對抽象編程：高層模塊不依賴於低層模塊；抽象不依賴於細節。所以測試的代碼，應該針對用戶意圖和公共接口這樣的抽象編寫。函數中的語句都要在同一抽象層次上。
Stub是提供被測系統提供輸入，Mock在提供輸入的同時驗證輸出。提取接口，派生子類都可以構造stub。
單元測試要快，不應該：
1.與數據庫交互
2.進行網路通信
3.調用文件系統
4.對環境做特定準備（編輯配置文件等）才能運行。
全面重構：
1.審視並更新TODO列表，刪除已經完成的任務，添加新發現的任務。確保該列表反應當前最新情況。
2.根據經驗，選定合理的下一個任務
3.編寫或修改測試代碼(固化行爲，調用當下生產代碼接口）
4.頻繁測試修改。
想做好一件事情，真的需要用心的長期堅持。10000個小時，我們真的差得好遠。在某一個特定領域用一生的時間來刻意完善自己的表現，與君共勉。