l

2015年1月1日 星期四

敏捷開發與OOAD(下)

2014 Dec. 29 22:45~23:50

image

 

不知到鄉民們是否會有一個疑問,在這麼多敏捷開發的書籍當中,好像很少有書提到要怎麼做分析設計?為什麼把需求寫成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要難很多啊。

2 則留言:

  1. 我也覺得 Craig 該更新這本書了,不過他目前在忙 LeSS 的事情。

    近年他的課上也有 Spec by Example 的內容。其實他書中也提到不要把 Model 做得完美完整,其實替未來打算會做的 stories 去分析和做一點設計,作為團隊中對設計的共識就夠,跟 Spec by Example 很類似。

    http://less.works/less/technical_excellence/architecture_design.html

    回覆刪除
    回覆
    1. 我覺得 UP 的 use case driven 和 Spec by Example 的味道很像,只是 use case沒有用 Given-When-Then這種格式來撰寫 scenario。讀了 Craig 的書,覺得書中的方法 up-front design 的味道還是重了一些。還沒時間去把 DDD/BDD/TDD 這套方法和傳統 OOAD 方法的差異搞清楚,這也是一個有趣的課題。

      刪除