敏捷架構的8個原則（上）

Jan. 02 21:38~22:47

 

在《Agile Software Requirements》這本書中，介紹了敏捷架構的8個原則。了解敏捷開發的鄉民們看完之後可能會覺得這8個原則有講跟沒講差不多，但許多鄉民即使號稱採用敏捷開發，但實際上很多觀念與做法還是停留在以前waterfall的時代。所以，了解一下這8個原則可以大致知道敏捷方法對於架構設計所採取的策略。

***

原則1：The teams that code the system also design the system（負責撰寫系統的團隊也負責系統設計）

傳統軟體開發通常將架構設計交由架構團隊或是某個架構師來完成，之後再將設計文件轉交給開發團隊來實作。這種模式產生許多問題，首先負責設計架構的人不需要實作這個架構，所以對於架構設計的好壞很難得到回饋，或是打從內心根本拒絕獲得回饋。反正有問題一定是程式設計師能力不足，絕對不是架構設計有問題。其次，架構也必須隨著需求增減或異動而改變，但這種架構師、開發團隊涇渭分明的合作模式，通常不鼓勵改變或是讓架構改變的成本變得很高。

敏捷開發建議系統架構由一個cross-functional team所獨立完成，團隊負責設計與實作架構，以避面「丟過牆」的跨部門溝通與合作浪費，也鼓勵架構持續演進。Teddy自己覺得，敏捷團隊的每個人都是架構師，都有權也有義務對架構做出貢獻。

***

原則2：Build the simplest architecture that can possible work（建立可工作的最簡單架構）

這條原則反應敏捷開發的「簡單設計（simple design）」原則，以避免過度設計（over design）所造成的浪費。現在流行的BDD/TDD就是實踐這條原則的開發方法，借由實作完成單一小需求所需可工作的軟體，來讓軟體架構自然長出來。如果長壞了怎麼辦？請呼叫refactoring、refactoring to patterns、big refactoring這些朋友。

***

原則3：When in doubt, code it or model it out（如果有疑問，實作或建模它）

在設計架構的時候，對於不同的技術團隊成員有時會陷入無止境的討論，無法獲得共識。與其紙上談兵爭不出勝負，還不如直接把各自的提案實作出來，可獲得最實際的回饋。如果系統過於複雜，不容易在短時間實作，可以考慮用建模（modeling）的方式來分析與討論各種解決方案的優劣性。

***

友藏內心獨白：吃自己的狗食。