軟體架構也可逐步成長（6）：Piecemeal Growth的啟發

June 0 21:37~23:08

 

Teddy在《軟體架構也可逐步成長（5）：Piecemeal Growth》這一篇未了留下了一個伏筆：

請鄉民們先思考一下，Piecemeal Growth的三個子規則，與軟體開發活動有沒有對應關係？如果有，這些對應關係是什麼？這三條子規則對於平常的軟體開發與架構發展有沒有幫助？

幾天過去了，不知道鄉民們針對以上問題有沒有什麼看法？今天來談討一下將Piecemeal Growth這三條規則應用在Scrum敏捷開發方法中，如何支持軟體架構逐步成長的作法。首先複習一下Alexander幫Piecemeal Growth列出的三條子規則：

• 任何單一的建築增長計畫規模不可太大。
• 混合合理大小的建築增長計畫。
• 建築功能的分配要合理。

***

現在把節目場景轉到Scrum身上，曾經採用過Scrum的鄉民們幾乎都會遇到相同的問題，那就是「在Scrum或是其他敏捷方法中，何時設計軟體架構？」Teddy在《Iteration 0 要幹麼？》介紹過一種「偷吃步」的方法，在專案正式開始之前，先偷偷地安排一段不太長的時間來設計軟體架構。但這種作法許多「敏捷狂熱分子」是不屑採用的，他們不贊成事先安排一段時間來做所謂的專案啟動前的準備。但無論如何，當組織與團隊還「不夠超級敏捷」的時候，實務上iteration 0也不失為一種可行的方案。

另一種理想的狀況是，團隊並沒有事先花費額外的時間來設計或規劃軟體架構，而是靠著一個、一個story的完成，讓軟體架構逐漸慢慢成形。

從以上兩種做法，可以觀察到兩個相衝突的force（作用力）。

• 只要需求不變，事前花越多的時間設計架構，事後重改的機會就越少。但只要需求改變，有可能導致架構改變，事前設計所花的時間可能就白費了。
• 因為需求一直在變，所以不要花（太多）時間做事前架構設計。但是讓架構隨著需求實作而慢慢成長，長壞掉需要打掉重做的風險又很高。

問題的關鍵點是，要如何在這兩者之前取得平衡。

***

鄉民甲：看到這邊還是不知道敏捷專案的軟體架構設計和Piecemeal Growth的三條子規則有何關係？

Teddy：恭喜老爺，賀喜夫人，此為正常現象。

請再看一次這三條子規則：

• 任何單一的建築增長計畫規模不可太大：如果真的需要事前花時間設計軟體架構，那麼「單一回合」所設計出的軟體架構涵蓋範圍不可太大。例如，一個6個月的專案，如果連續花2個月的時間在設計軟體架構上，感覺耗費的時間就太長了。如果每一個為期6個月的開發週期，安排1~2週來決定初始軟體架構的雛形，這樣的大小感覺比較合適。
• 混合合理大小的建築增長計畫：一個系統設計是好是壞，不光只是由選擇軟體架構這種 「大尺度」的設計決定，還包含模組化與物件導向設計的程度、設計模式的套用這種「中尺度」的設計決定，以及類別設計、函數或方法（method）設計、命名等「小尺度」的設計決定。專案要合理分配花在這三種尺度的設計時間，把全部時間都花在大尺度的「架構設計」，而忽略了模組化或是變數名稱等中、小型設計議題，最終的軟體設計品質也不可能會好。只關注物件導向設計原則、單一類別設計、每個函數要寫幾行、變數怎麼取名等中、小型設計議題，忽略了大的軟體架構，當然整體的設計品質也不可能會好。
• 建築功能的分配要合理：最後這個概念，有點像是「end-to-end story」的味道（請參考《End-to-end stories：鄉民要求篇》），或是RUP（Rational Unified Process）提到的「Use-Case Driven」的概念（使用案例驅動系統與架構的成長）。翻成白話文就是說，透過完成story的方式來讓軟體架構逐步成長的過程中，story要橫跨架構的每一個層面，不能只涵蓋某一個階層（layer）。換句話說，儘量不要用functional team或component team的方式來成長你的軟體架構（關於functional team的說明，請參考《Scrum框架下的跨界開發(4):分組方式》）。

***

以上，看起來像是天書，但只要經歷過「軟體架構逐步成長」過程的鄉民們，多多少少應該可以體會Teddy解釋的這三點精神。如果還是不行但是又想要學的話，只好等Teddy以後有空開「軟體架構逐步成長設計課程」的時候再來報名了。

***

友藏內心獨白：這種偏門的課，可能要排到民國XXX年。