軟體架構也可逐步成長

August 06 15:54~18:21

 

今天讀了Howie Yu對於「Scrum大師講座 (Emerson Mills)」的實況紀錄，整理非常詳盡，值得拍拍手鼓勵 。其中最吸引Teddy的並不是Emerson對於Scrum的介紹內容，而是Howie Yu所寫的這一句話：「對於Emerson 所說 Do not pre-architecture too much 嘖嘖稱奇」。

相同的概念Teddy曾經在《你的軟體架構有多軟》提過，但也許Teddy是用中文講的，所以並沒有任何鄉民嘖嘖稱奇… 。廣義的來講，這種想法就是敏捷方法所強調「不要做過多事前設計（avoid big up-front design）」的自然結果。但是相信有很多鄉民會跟Teddy有一樣的疑惑：「雖然敏捷方法建議我們不要做過多的事前設計，但是軟體架構的身分這麼特殊，是不是要當作特例處理，在專案開始的時候多花點時間來設計軟體架構呢？」

後來Teddy讀了《Implementing Lean Software Development: From Concept to Cash》這本書，得到佐證資料：

It is time to abandon the myth that architecture is something that must be complete before any development takes place.

翻成白話文就是說：不用等軟體架構都確定之後才開始開發軟體。用嘴巴講很簡單，但是實施起來是挺困難的。

***

上禮拜天Teddy和Kay去聽了一個演講，題目為：「巴黎城市歷史性軸線」，講者是淡江大學建築系副教授陸金雄先生。由於之前去過兩次巴黎，此次陸老師所介紹巴黎城市歷史性軸線上的建築物幾乎都去參觀過了，所以聽起來特別有滋味，有一種遠端重遊巴黎之感 。

(照片翻拍自講者的投影片)

 

(照片翻拍自講者的投影片)

巴黎城市歷史性軸線起點為羅浮宮，往西延伸終點為「拉德芳斯新凱旋門」（上圖右方的白色大框框）。根據維基百科的資料，新凱旋門高110公尺，寬108公尺，深112公尺，幾乎是一個立方體。鄉民們請注意一下照片中的新凱旋門中間下方，有一塊白色的東西漂浮在上，稱之為 飛碟「雲」（沒錯，就是cloud computing的那個cloud）。2011年Teddy和Kay到新凱旋門的時候，Teddy出了地鐵站遠遠看到建築物的第一個感覺是：「好高大的建築物啊，非常的壯觀」。接下來Teddy就覺得有點怪怪的，為什麼要在建築物中央拉上「棚布（就是那朵雲啦）」？

昨天聽了陸老師的解說才明白，原來新凱旋門建造的「尺度」是所謂的「神的尺度」（因為建築物高達110公尺啊），當人站在建築物中間的時候，會覺得壓力很大。為了調和這個現象，建築師就在中間擺上一朵雲，讓人們可以在雲之下休憩（用雲做出人的尺度）。

聽到這邊Teddy想到「風水」。房子已經蓋好了，但是住的不順，於是找風水師傅來幫忙看風水。

風水師：你的房子大門正對著三叉路口，就好像一把刀插入你的胸口。

鄉民：那怎麼辦？不可能把房子移位，也不可能把馬路換位置啊！

風水師：別擔心，只要在門口掛上一個八卦鏡，把煞氣反射回去就可以了。

***

怎麼樣讓軟體架構變軟，也能隨著開發週期而逐漸慢慢成長呢？方法也許很多，但Teddy比較熟知的就是pattern language的方法。Alexander在《The Timeless Way of Building》提到：

• 每一個個別的建造活動就是空間得以分化（差異化）的一個過程。它並非是一個由預先造好的部分（part）相結合而產生一個整體的相加過程，而是一個逐漸展開的過程。就像胎兒的發展，整體先於部分，並透過分化（差異化）孕育人體其他各個部分。
• 展開的過程步步深入，一次一個模式（one pattern at a time）。
• 具有自然特徵的完整建築物將根據這些個別模式的順序，在你的思想中，像句子一樣簡單地自然形成（所以相關的pattern會形成一種語言）。
• 以同樣的方式，幾組人可以透過遵循一個共同的模式語言（pattern language），當場構思出他們的大型公共建築，就好像他們共有一個心靈。
• 一旦建築物像這樣被構想出，它們就可以直接從一些在地上做的簡單的記號中產生出來，不用 UML 圖 施工圖。

寫到這邊有人看得懂…才有鬼 。用最簡單的話來說，要達到讓軟體架構變軟，從高到低有以下幾個層次，每一個層次都要串接起來才算完整（備註一下，還要加上自動化測試和持續整合，不過這不是今天的重點，就不特別說明了）：

• 了解architecture pattern：像是POSA（pattern-oriented software architecture）系列書籍，或是《Patterns of Enterprise Application Architecture》這類的書。根據Alexander的說法「整體先於部分」，所以開發軟體的時候，還是要先思考這個軟體的「整體」是什麼？例如，Alexander在他的書中所舉的例子，他要蓋一個花園，首先選擇「半隱蔽花園」（half-hidden garden）這個模式，接著在往下展開，套用其他幾個較小的模式。回到軟體架構設計，在開發初期，雖然需求尚未清楚的釐清，實作也還沒開始，但是軟體架構類型還是可以事先挑選。例如，MVC、Client-Server、Plug-in、Layered等等。至於架構中的「肉」，可以隨著開發而逐漸長出。以當天Emerson所舉的例子，他說如果應用程式需要用到persistence的需求，他會先用一個簡單的O-R mapping的方式來處理，後端可能只用簡單可以支援儲存（key，value）的資料庫。等到發現效能無法滿足時，再來考慮要如何提升效能。如果效能不是一個問題，這樣的架構也就不需要修改（希望Teddy沒有聽錯Emerson的意思…）。O-R mapping就是一種architecture類型，雖然說「Do not pre-architecture too mush」，但是像這種大範圍架構還是需要先選擇與決定會比較好一點。
• 了解design pattern：architecture pattern只是一個殼，真正要把肉長出來，還是需要範圍比較小的design pattern來協助。對於一些規模比較小的軟體，甚至只要直接套用design pattern便可解決設計上的問題。所以有人稱design pattern為micro-architecture（微架構）。Design pattern往上可以串接軟體架構，往下則是累積了許多優良的物件導向設計經驗，所以從這裡開始學習設計與架構，算是一個很好的入門點。結論就是，趕快報名Teddy的「Design Patterns這樣學就會了：入門實作班」吧…XD。
• 了解物件導向設計觀念：architecture與design pattern可謂是前人智慧的結晶，但是為什麼這些「晶（精華）」會結成這個樣子，就必須要透過基本的物件導向觀念來說明。所以，有了正確的物件導向設計觀念，讓鄉民們不但知其然，還知其所以然。
• 至少熟悉一種程式語言：嘴砲說得再多，最後還是得用程式語言實作出來。規劃、設計的再好，程式寫錯也是枉然。所以，最基礎蹲馬步的功夫一定要做好。

***

上述四個層次，程式語言和物件導向觀念鄉民們比較容易自學，所以Teddy就不雞婆多做解釋（其實物件導向觀念要學得好已經有一點門檻了）。Design pattern往上到architecture pattern難度稍微高一點，而坊間的書本雖然很多，但是真正能學好的鄉民似乎不多。所以，Teddy才會想先開「Design Patterns這樣學就會了：入門實作班」，讓有需要的鄉民們有機會可以打通任督二脈，繼續往上一層發展XD。

***

友藏內心獨白：最近置入性行銷的文章也太多了一點吧。