可執行的軟體架構雛形

Dec. 21 00:46~01:40 [2012]

前幾天有一位朋友問Teddy一個關於在Scrum專案中如何進行軟體架構規劃的問題：

我們準備開發一個大型系統，為了避免日後做錯，因此我們需要一段時間（也許1~2個月）用來分析與整理系統架構。此時系統分析師需要規劃並且整理出一個適合專案採行的系統架構。但是問題來了，這種架構分析工作都無法馬上實作，也就是說此時還無法寫程式。請問這種類似系統架構分析無法立即寫程式實作的工作，在Scrum中要如何進行呢？

***

這位朋友對與軟體開發的想法，還是停留在比較傳統的瀑布式開發模式。在這種模式之下，系統分析師會依據系統需求設計出一個系統架構。這個所謂的「系統架構」通常就是一堆文件，其中包含block diagrams、UML diagram、系統模組、資料庫schema等等。這些東西，當然是不能吃…嗯嗯，不能執行的東西。

Teddy帶領Scrum團隊的做法，在專案剛開時的幾個sprint，也是會花時間在確定軟體架構雛型上面。但是這種確定軟體架構的產出，並不是一堆文件，而是可以乘載一個、一個story的可執行軟體架構雛形。翻成白話文的意思就是說，在Scrum專案剛開始的時候，團隊會與PO討論，決定哪些是「對使用者價值比較高的story」挑出來優先施工。如果這是一個全新領域的專案，且技術面（例如軟體架構的選擇）的風險與不確定性比較高，則此時會盡量挑選那些對軟體架構影響比較大的story，或是可以協助軟體架構成型的story，考慮優先施工。換句話說，藉由挑選與實作合適的story，軟體架構就逐步的成形。

舉個例子，假設鄉民們要開發一個「持續整合系統」，這樣的系統要能夠成功，一個主要的因素就是要能夠支援各式各樣的建構工作（例如編譯、測試、靜態程式碼分析等等）、程式語言（Java、C/C++、C#、Python等等）、版控系統（CVS、SVN、Git等等）。請問這個系統的軟體架構要如何設計？

***

在考慮軟體架構之前，寫story先：

• 身為CI工程師，我可以編譯
• Java專案。
• C專案。
• C++專案。
• Python專案。
• …專案。
• 身為CI工程師，我可以測試
• Java專案。
• C專案。
• C++專案。
• Python專案。
• …專案。
• 身為CI工程師，我可以從
• CVS下載專案檔案。
• SVN下載專案檔案。
• Git下載專案檔案。
• …下載專案檔案。
• …

思考這些story，應該不難發現這個持續整合系統必須要具備「擴充性」，而且可能需要支援未知的程式語言、建構工作、版控系統。假設團隊決定要採用「插件架構」（Plug-in Architecture）來解決這個擴充性的問題，與其花時間幫這個「想像中」的插件架構畫出所謂的架構圖，可以藉由實作上面的story來逐步產生軟體架構。例如，第一個sprint可以先做：

• 身為CI工程師，我可以編譯Java專案。
• 身為CI工程師，我可以測試Java專案。

這種挑法可以讓團隊驗證「支援多種建構活動」這個需求。當然你也可以這樣挑：

• 身為CI工程師，我可以編譯Java專案。
• 身為CI工程師，我可以編譯C專案。

改用這種挑法，則可以讓團隊先驗證「支援多種程式語言」這個需求。

***

雖然Teddy已經在搞笑談軟工部落格中講過好幾次了，但是重要的事還是值得一講再講。很多人認為軟體架構「一定要在寫程式之前確定」，這個觀念應該要被打破或是修正。具體來說，要讓團隊變得更靈活、更有彈性，應該朝向提升以下能力邁進：

• 一定要寫自動化測試。自動化測試是系統的安全網，讓開發人員不再害怕改程式。
• 要具備良好的設計能力。「具備良好的設計能力」這句話聽起來很空洞，最低限度至少要有正確的物件導向觀念，以及應用設計模式（design pattern）的能力（歡迎報名參加「Design Patterns這樣學就會了：入門實作班」）。
  
• 要導入持續整合。
• 有空要多看、多了解市面上有那些軟體架構模式，分別可以解決哪些類型的問題。
  

***

友藏內心獨白：寫這篇的時間剛好是傳說中的世界末日。