敏捷開發與OOAD（下）

2014 Dec. 29 22:45~23:50

 

不知到鄉民們是否會有一個疑問，在這麼多敏捷開發的書籍當中，好像很少有書提到要怎麼做分析設計？為什麼把需求寫成user story之後，就可以很自然地在每一個iteration當中就把程式寫出來。物件要怎麼產生？方法（method）又要怎麼設計？

早些年這個問題一直是Teddy心中的疑問，噯呀，可能是功力不夠所以還不知道要怎麼做。但是在學了OOAD方法之後，Teddy心中就更模糊了。Larman講的那一套Teddy可以理解，但是與敏捷開發相比，Larman的方法相較起來up-front design（事前設計）的成份又重了很多，而這不正是敏捷開發所要避免的嗎？

關於這個問題在上集Teddy提到借用傳統OOAD方法（Larman在書中所介紹的UP）做為整理初始product backlog以及建立可執行軟體架構雛形的方法做為一種可能的答案。今天談敏捷開發社群如何看待分析與設計。

***

以Teddy的理解，現今敏捷開發有一種主流的做法，就是透過Specification by Example（或BDD）的方式來描述需求，然後以story做為一個小的context，從規格中尋找出類別與方法。這種做法就好像傳統OOAD方法中，從use case找名詞與動詞，然後對應成conceptual model/domain model裡面的concept/class與operation（類別與方法的前身）。只不過一次看的範圍很小，就僅止於這個story。

有了story以及以given-when-then所撰寫的scenario做為詳細規格之後，接著開發人員必須提供step definition檔案用以連結規格和production code。這時候step definition就變成Code by Example（TDD）的具體context，所需的物件與method也就很容易產生。

換句話說，透過Specification by Example與Code by Example，敏捷開發方法的物件與method就此產生。然後借由不斷疊代（iterative），傳統OOAD方法所建立的domain model就慢慢浮現出來。當然片段式的產生物件與method很可能導致系統的設計混亂、難以擴充等問題，因此需要搭配refactoring（小步驟重構）、refactoring to pattern、甚至是Big refactoring來改善設計。

***

這兩集的技術成份比較高，如果有看懂的鄉民應該會感受到，傳統OOAD方法有比較濃厚的up-front design與push味道，而和Specification by Example/Code by Example這套方法則有很強烈的JIT（Just In Time）與pull味道，也正好反映出敏捷與精實開發的「延遲承諾」精神。

到目前為止Teddy還不是很確定，傳統OOAD方法和DDD（Domain Driven Design）/Specification by Example/Code by Example彼此之間是否可以互相取代（互斥），亦或是可以互相合作、交互應用。如果鄉民們有這方面的資料或知道有哪本書有提到相關的內容，歡迎告知Teddy。

***

友藏內心獨白：JIT Anything還是比UP-Front Anything要難很多啊。