落實TDD的三個難題（下）：技術能力的精進

March 26 07:37~08:53

難題三

落實TDD/ATTD/BDD/SBE最後的難題是技術能力的精進。TDD所需的技術能力，包含如何透過與領域專家緊密合作，找出代表規格的關鍵例子（key examples），再以軟體工具（Cucumber、SpecFlow、Robot Framework、xUnit等）逐一自動化這些例子（驗收測試）。

有了失敗的測試案例界定規格邊界（範圍），接下來便可撰寫production code實作這個規格。等待測試案例通過，代表某項規格已被實現，此時回頭思考程式碼是否可透過重構（refactoring）改善設計品質，讓軟體持續維持在軟的狀態。一個可閱讀、可維護、可測試、易修改、易部屬的軟體，才能給予團隊擁抱改變的力量。

遵循這個步驟，採取穩扎穩打、迭代與增量、價值驅動的方式，完成系統開發工作。

***

三個圈圈的交集

這系列三篇文章提到的三個主題：

• 領域模型與軟體架構
• 通用語言
• 技術能力

三者看起來好像是各自獨立的議題，但實質上彼此緊密相關，互有增強效果。領域模型與軟體架構可促進團隊建立穩健的通用語言，讓後續開發工作變得更具體，更容易落實ubiquitous language in code。更強的技術能力，讓團隊與領域專家溝通時，能更精確找出代表需求的關鍵例子，以更準確、精練的語言，描述規格並將所獲的的知識以程式碼的形式紀錄下來。

舉個例子，當你準備採用最簡單的Rename重構程式中的變數、函數、類別、package名稱時，是否有著不知道如何命名的困擾？對於非英語系國家的人，可能直覺認為是自己的英文能力不夠好，所以不知道如何取名字。英文程度當然會影響取名字的能力，但有另一個更深層且不容易被察覺的問題，就是「團隊對於問題領域的重要概念或商業邏輯還沒有達成一定的共識，不知道用什麼名字來稱呼某件事情」，

另外一個常見的例子就是在沒有做任何分析的情況下，期望透過 TDD，在撰寫失敗的測試案例過程中就能夠直接找出類別必且定義它們的介面。這其實是一件困難的工作，「物件村」空無一人，你的失敗案例要呼叫誰來幫忙？如果可以做一點點事前設計，有了初始的領域模型，進一步甚至直接套用像是clean architecture這種通用軟體架構，可以讓後續實作自動化驗收測試的過程更加容易且比較不會長歪掉。

***

吃技術

Teddy的一位朋友在討論技術問題時很喜歡用「吃技術」這三個字：「TDD很吃技術、重構很吃技術、持續整合很吃技術、DDD很吃技術」。

軟體開發本身就是一件技術活，有什麼活動是「不吃技術」的嗎？只要基本功夫紮實，做起事來就跟喝開水一樣簡單，不會覺得做什麼都「吃技術」。

有不少人因為沒學過OOAD（物件導向分析與設計），或是學過OOAD但覺得OOAD好難，TDD好簡單，都不用作什麼分析、設計的工作，只要驗收測試寫出來，物件就自動冒出來，介面也設計好了。傑克，這真是太神奇了。

在此Teddy要告訴傑克：「這是不可能的」。能量不滅，原本OOAD所要做的工作，不會因為改用TDD就消失不見，只是以其他的形式呈現罷了。

想學好一件事，先弄清楚困難的地方在哪裡。知道地形地物、context之後，才不會人云亦云，才會有自己的看法，才能夠透過迭代與增量的方式累積層次而不至於長歪掉。

***

友藏內心獨白：做軟體的不吃技術難道要吃大便XD。