談談XP（3f）：Primary Practice

Mar. 11 21:44~23:55

 

介紹完Sit Together、Whole Team、Informative Workspace、Energized Work、Pair Programming、Story、Weekly Cycle、Quarterly Cycle、Slack、Ten-Minute Build、Continuous Integration，今天介紹最後兩個XP Primary Practice：

• Test-First Programming（測試先行程式設計）：在改變或新增任何程式之前，先為它寫一個失敗的自動化測試。Kent Beck說這個實務做法同時解決了：
  • scope creep （範圍蔓延）：Teddy在〈組織要如何解決更複雜的問題？〉提到：「先寫test code是要界定solution的context（因為直接設計出solution可能不容易，或是不小心會陷入over design的陷阱）」，所謂「界定solution的context」就是不要造成production code的「範圍蔓延」。因為用戶端的程式已經先寫好了（以test code的形式存在），所以production code這個solution也就固定了。依據Alexander的說法，當你有一種方法可以用來詳細描述context，則設計問題便不存在。
  • coupling and cohesion（耦合和內聚）：Teddy在上設計模式或是單元測試課程的時候經常提到，很多開發人員不寫測試，是因為測試程式很難寫，寫不出來。其實絕大部分的情況並不是「測試程式很難寫」，而是待測程式（production code）設計得很爛，導致很難測試。當測試程式寫不出來的時候，開發人員就知道設計出了問題，要想辦法降低耦合提高內聚。
  • trust（信任）：如果某人寫的程式動不動就出包，大家對這個人的信心指數將大幅降低。為了不讓你變成「某人」，先寫測試並利用自動化測試展示自己開發的程式功能正常，可以提高別人對你的信任感。
  • rhythm（節奏）：寫程式的人一定都遇過那種寫到頭昏腦脹，不知道自己在寫程式還是在寫bug的窘境。Test-First Programming的開發步驟—test、code、refactor，周而復始，讓程式開發養成一個規律的節奏。
• Incremental Design（漸進式設計）：每天投資一點時間在設計系統上面，努力讓設計完美滿足當天系統所需即可。很多鄉民聽到 「漸進式設計」，就會想到Martin Fowler這篇著名的文章〈Is Design Dead?〉，然後導出「big up-front design」（花很多時間在事前設計）不好，然後再簡化成「任何的up-front design都不好」的結論。Kent Beck在書上提到，如果你已經 很有經驗，「漸進式設計」並不是說事前設計是很糟糕的。它只是建議，當需要的時候再做設計工作，是比較有效率的方式。這種看法和Alexander所說的piecemeal growth（逐步成長），還有精實開發所說的「儘量延遲決策時間」，都是一樣的道理。

Kent Beck提到一個很基本的提升設計品質方法，大家都知道但卻很難做到，那就是「eliminate duplication」（消除重複）。所謂「重複」不單只是「程式碼一模一樣」才叫做，結構或邏輯重複也算。

***

要支援「漸進式設計」以及「測試先行程式設計」，都需要仰賴refactoring（重構），而重構有需要有足夠的測試案例來確保重構後的程式沒有改變系統外在行為。

最後補充一點，Test-First Programming和Test-Driven Development（TDD）有什麼不一樣？Teddy原本一直以為這兩個實務做法是一樣的東西，只是XXX-driven development這樣的「命名pattern」在軟體界很常見，什麼TDD、BDD、DDD，而Test-First Programming縮寫變成TFP，就不像TDD那麼酷了。

剛剛google了一下，還真的有人列出這兩者的相同與相異之處。雖然Teddy覺得這樣的差別似乎不是很重要，基本上把就算是提到TFP，大部分的人腦袋裡面應該都是直接以TDD代換。有興趣的鄉民可以自行參考一下這篇文章：〈The Differences Between Test-First Programming and Test-Driven Development〉。

***

友藏內心獨白：終於寫完了XP的13個Primary Practice。