落實TDD的三個難題（中）：通用語言的建立

March 18 17:02~18:11

▲廣義的說，TDD、ATDD、BDD、SBE都是同義字。

難題二

落實TDD/ATTD/BDD/SBE的第二個難題就是通用語言的建立。傳統TDD（先寫失敗的單元測試）好像只是開發人員自己的事情，它被降級為一種開發方式的選擇（Test First VS. Code First），一種技術議題，與商業無直接關係。

但後來的TDD，也就是冠上ATTD/BDD/SBE之後的TDD，強調透過開發團隊與領域專家的合作，以「舉例」的方式一起釐清需求與商業價值。

這裡說的領域專家，可能是Scrum團隊的Product Owner，或是任何具備問題領域知識的stakeholders。這是一種頻繁、高互動性且非常燒腦的活動，而不是單方面由Product Owner寫好user story然後在sprint planning meeting「宣達聖旨」給團隊的那種溝通模式，更不是瀑布式開發那種「文件丟過牆」的溝通模式。

***

通用語言

通用語言（Ubiquitous Language）是領域驅動設計（Domain-Driven Design；DDD）所提出的觀念，意指「在一個特定領域中，所有人所固定使用的術語」。例如，在貓奴這個特定領域（bounded context），大家對於乾乾、濕濕、罐罐、浪浪、小橘、賓士、虎斑、三花、玳瑁、麒麟尾、鏟屎官、聖上、皇后、離胺酸、貓砂、逗貓棒、結紮、貓毛、掃地機器人等名詞有著高度共識。一群貓奴聚在一起，用他們的「通用語言」可以非常有效率溝通而且比較不會造成誤會。

這個概念，應用在軟體開發上面，當團隊建立了良好的的通用語言，問題領域的知識可以直接出現在解決方案領域，商業人士可以直接和技術人員用相同的語言溝通，表達商業邏輯。更進一步，在實作軟體系統時，這個通用語言將直接反應在程式碼裡面，也就是ubiquitous language in code。如此一來，程式將變得更加容易理解與維護，也更容易擴充。這是一種讓軟體變軟，擁抱改變的做法。

***

通用語言和TDD有什麼關係？

在〈落實TDD的三個難題（上）：領域模型與軟體架構〉中Teddy提到建立領域模型對於TDD的重要性，而建立通用語言的過程，同時間幫助團隊建立領域模型，兩者相輔相成。

只要Teddy聽到有朋友「宣稱」採用TDD開發軟體，Teddy一定會問對方：「你們的需求如何產生（如何撰寫失敗的驗收測試）？」如果答案是「Product Owner寫好給我們照做」，那麼落實TDD的程度就還有不少改善的空間。

如果答案是「透過頻繁地與Product Owner溝通，討論列出需求中的重要例子（key examples）」，那就比單向的接受user story要好很多。如果答案是「透過與Product Owner以及stakeholder的討論，以舉例的方式，建立共同討論的語言，並以此為基礎來撰寫程式」，那就可以獲得一張「好棒棒」貼紙。

***

結論

TDD是透過先撰寫測試案例來釐清需求或規格，之後再考慮如何開發程式的一種設計方法。套用建築師Alexander的模式框架，這是一種「先決定Context，再決定Form」的設計方法。

為什麼網路上的TDD範例與TDD Kata你都做得嚇嚇叫，公司的專案做起來卻讓人很想睡覺？很簡單，因為前者具有定義清楚的Context，而後者的Context非常模糊。

一般來講，Product Owner與stakeholders擁有比較多的領域知識，換句話說他們比較了解Context。缺少這些角色的幫忙，開發人員很難獨自透過TDD的方式自行決定Context，這也是許多人在真實專案中落實TDD所遭遇到的困難。

在許多公司，Product Owner與stakeholders覺得「撰寫失敗的測試案例是開發人員的事」，人家不願意理你啊。

難怪你的TDD又變成XD了。

***

友藏內心獨白：不能放任開發人員自由發揮，結果會很恐怖。