經(jīng)常在TDD訓練營中有學員提這個問題：學了TDD，在項目上也沒法落地，為什么TDD很難在項目上推動？
TDD本身就是一項具有爭議的實踐，但凡不是一個極限編程踐行者，很難堅持貫徹實踐TDD，原因有很多，如果"不負責任"的回答可能是：
- 自身技能不熟練
- 項目不允許，因為TDD會影響交付
- 系統(tǒng)很難寫測試
- ......
原因說的再多，導致難以推動只因為存在一個問題 -- 一旦你用了TDD，就會阻礙交付，即讓你交付的速度下降。 如果沒有影響交付，就不會有任何實質(zhì)性的問題。
第1種原因，就沒什么可說了，技能不熟練，用新的東西，速度肯定會變慢，而且還容易出錯，原本項目就緊巴巴的，肯定會拖慢交付速度。但這個也是相對較容易解決，只是時間的問題，多花點業(yè)余時間練功就好。我說相對，確實是相對的，相對你所在項目交付節(jié)奏的緊張程度。越緊張，你就越難有時間去練功和項目上運（試）用（錯），越?jīng)]有時間練功，你就越?jīng)]法好好運用。所以當你所在的項目緊張到自己對完成交付缺乏信心的時候 ，你就不愿意投入時間學習，而想用這個時間來加班工作。如果沒有超過臨界值，你需要鍛煉的主要有以下幾個方面：
- 分析性思維，能夠更加高效地理解問題，拆分問題
- Clean Code sense，能夠花同樣的時間寫出更簡潔的代碼
- 單元測試，能夠?qū)懗鲇行У膯卧獪y試
- 設計思維，能設計出符合業(yè)務模型的代碼。比如OOD，Simple Design
- 重構技巧，能夠有效的阻止代碼腐化，持續(xù)改進設計
- 手速（快捷鍵），編寫同樣的代碼，花的時間更少。
第2種原因，得分兩種情況。一類是項目緊張到對新東西沒有丁點容忍，實在沒法給新人嘗試新東西的空間，這種項目你可以做完后考慮換一換了。另一類是項目其實還是有空間的，只是因為大家都在依照本能開發(fā)，沒有測試，很多人肉測試和返工的花銷。在這種情況下，你可能覺得要上洗練套餐了（洗腦+練兵）。其實，最重要的是，你自己要先把基本功練扎實，讓自己能夠在有限的時間內(nèi)完成從Tasking到TDD的連招，做好表率，然后證明TDD縮短了DoD（Definition of Done）的周期，并證明自己寫的代碼Bug率更低。拿著數(shù)據(jù)，再上洗練套餐。當然在這種情況，你要付出別人更多的努力，你要在狹縫中殺出一條生路，所以唯一的捷徑是自身的基本功修煉之路。話說，項目為啥不允許TDD？實際上是因為擔心會影響交付進度，如果能扭轉(zhuǎn)這個因果關系，項目會管你用不用TDD嗎。
第3種原因，確實有那那么一種系統(tǒng)，自誕生就是一個遺留系統(tǒng)（Michael C. Feathers在《修改代碼的一書中》提到：遺留代碼就是那些沒有編寫測試的代碼）。由于系統(tǒng)很難寫測試，就別談TDD了。如果排除了上述兩種原因，那么這種原因極大可能是系統(tǒng)架構設計出了問題，不是沒有分層，就是層分多了；不是層分多了，就是層分錯了；如果都不是，那就是層與層的依賴關系混亂了。如果架構的設計出了問題，你就很難對系統(tǒng)或者某一層去寫測試。就好比：
- 系統(tǒng)沒有分層，是一個大單體，不知道從哪里寫測試，感覺哪里都要測，又感覺哪里都沒法測。
- Controller層依賴了Use case層，Use case依賴了Domain層，Use case依賴了Infrastructure層，Controller又依賴了Domain，Domain又依賴了Infrastructure層，感覺要測試Use case，但各種復雜依賴。
TDD很難推動的原因有很多，可以嘗試先解決內(nèi)因（自身基本功），內(nèi)因是更可控的。但解決了內(nèi)因，也不一定能克服外因，外因有很多種情況，不知道你遇到了哪種？
