模�鍬伎�⒐�討兇鈽麓鋶傻慕崧邸６�藝飧齷貢匭敫鶳roduct　Backlog對應起來。概要設計是確保大家在XP的過程中不會脫離軌道，不會天馬行空。”

“嗯，那我們就先按照這個思路實行一段時間。可以透過每次的Sprint回顧會議進行調整。那我們再來看看TDD程式設計？”阿捷把頭轉向大民。

“好！從它的英文Test…Driven　Development即可以看出是測試驅動的。也就是說是在開發功能程式碼之前，先編寫單元測試用例程式碼，測試程式碼確定需要編寫什麼產品程式碼。這一點跟我們大多數人日常的實踐是不同的。我們雖然也有UT，並且數量也很多，但這些UT用例基本都是在編寫完功能程式碼之後，才編寫的。”

“我覺得區別不大啊！最終都是為了驗證功能的正確性。”小寶說道。

“不一樣！事後的單元測試較TDD會失去大半的意義。我們先來看看通用的測試驅動開發基本過程。”大民邊說邊把每一步列在白板上。

（1）明確當前要完成的功能。可以記錄成一個　TODO　列表。

（2）快速完成針對一個功能的測試用例編寫。

（3）測試程式碼編譯透過，但測試用例通不過。

（4）編寫對應的功能程式碼。

（5）測試透過。

（6）對程式碼進行重構，並保證測試透過。

（7）迴圈完成所有功能的開發。

大民轉過頭來，指著剛剛寫完的7條說，“乍一看，似乎也沒什麼。但深奧之處就在於第一步的明確上。如何明確？通常由業務分析人員、測試人員、開發人員進行一次討論，就要完成的功能的驗收條件達成一致並形成記錄，然後測試人員設計並編寫驗收測試用例，開發人員編寫單元測試和並實現功能程式碼。這樣，測試人員早期介入，從而可以避免開發人員與測試人員理解不一致，開始產生爭執並阻塞等待業務分析人員或者行政主管的仲裁。”

“嗯，測試就是應該越早介入越好！是吧，阿紫？”阿朱徵求阿紫的支援，阿紫很快點頭回應。

“對於開發人員來講，可以強迫他從測試的角度來考慮設計，考慮程式碼，這樣才能寫出適合於測試的程式碼。”大民接著講。

“從另外的一個角度上說，堅持測試優先的實踐，可以讓開發人員從一個外部介面和客戶端的角度來考慮問題，這樣可以保證軟體系統各個模組之間能夠較好地連線在一起，而開發人員的思考方式，也會逐步地從單純的考慮實現，轉移到對軟體結構的思考上來。這才是測試優先的真正思路。”

“另外，大家看第（6）步，這裡提到了重構。重構是XP裡面非常重要的一個實踐，只有不斷地重構，才能改善程式碼質量、提高程式碼複用，它跟TDD/簡單增量設計是相輔相成的，誰都離不開誰。那究竟什麼時候該重構，什麼情況下應該重構呢？”大民把問題提給大家，靜候大家的答案。

“有新功能的時候重構。”txt電子書分享平臺

第11章　你開車，我導航（4）

“需要複用程式碼的時候重構。”

“該重構時重構。”

“寫不下去的時候重構。”

“下一次迭代時重構。”

大家七嘴八舌地回答。

大民看到大家差不多說完了，清了清喉嚨：“這些想法基本都對。在TDD中，除去編寫測試用例和實現測試用例之外的所有工作都是重構，所以，沒有重構，任何設計都不能實現。至於什麼時候重構嘛，還要分開看，我的經驗是：實現測試用例時重構程式碼，完成某個特性時重構設計，產品的重構完成後還要記得重構一下測試用例。”

“我剛畢業時，加入的是一家鐵路局裡的資訊部門。我很清楚地記得，；帶我的大哥給我的第一句忠告就是‘如果一段程式碼還能工作，沒有出現問題，就不要動它’因為我們做的是鐵路排程實時運維繫統，不能出一點差錯。”小寶喝了口水，接著說，“我覺得非常有道理，一直也是奉行這個金科玉律的。你覺得呢，大民？”

大民沒有馬上回答，沉思了一下：“或許在你們的那個環境、那種條件下，這樣做是最穩妥的。我想，你們之前肯定因為修改過程式碼，而導致重大錯誤，從而一朝被蛇咬，十年怕井繩，對程式碼產生了恐懼感，最終無法掌控程式碼。我是這樣認為的，如果一個系統一直沒有新的需求，使用的情形一直不變，它本身可以一直不