軟體架構也可逐步成長（2）

August 07 17:09~18:31

翻拍自《The Oregon Experiment》

 

昨天提到軟體架構逐步成長的一個重點，就是「整體先於部分，然後透過差異化的過程將整體逐步展開」。不知道鄉民們對於此點精神是否有給他了解？今天Teddy要回應「鄉民W」在「搞笑談軟工Facebook社團」中，針對《軟體架構也可逐步成長》所提出的一個看法。

鄉民W：軟體架構要怎樣才會逐步成長是我目前最大的困擾, 在專案成員還沒有能力或是說有些人能力就是上不來時, 放手讓架構自我成長往往都會變成一盤義大利麵 = =

***

軟體架構長歪的情況，相信絕大多數有在開發軟體的鄉民都有類似的經驗。曾經有「鄉民R」告訴Teddy…

鄉民R：我設計好的軟體架構，交給developer去施工之後，剛開始還可以依造我原先的設計去實作。但是隨著時間過去，原本的架構不敷使用，無法應付新的需求。但是，我手邊還有其他的事情要處理，沒辦法繼續參與架構設計，只能任由developer「胡搞瞎搞 自行發揮」。最後的結果，套句mobile01上的話，就是：這棟樓又歪了（迷之音：幫不了你）。

這個問題怎麼解決？要怪鄉民R當初沒有設計出一個可以應付未來100年都不用修改的軟體架構嗎？當然不可能，因為世界上沒有那種東西。還是要怪公司交付給鄉民R的工作太多，害他沒時間持續參與軟體架構的演進？或是，把眼光放遠一點，思考如何讓developer有能力可以接手「軟體架構演進的工作」？

從敏捷方法的角度來看，每個developer都被期待可以是designer（設計師），也可以是architect（架構師）。如此一來，「軟體架構也可以逐步成長」這件事就變得比較有可能（請注意，只是變得比較有可能而已喔，還不一定會成功）。

***

那為什麼大部分的developer都還無法達到designer與architect的程度？最白話文的講法就是「經驗不夠」。但是，光光是說經驗不夠是不負責任的說法，因為Teddy也看過有工作10年以上經驗的developer，還是無法勝任designer更不用說是architect。到底是何種經驗不夠？從Teddy的角度來看，就是pattern（design pattern與architecture patter）的經驗不夠，就算有些經驗但是了解的也不夠深入。

使用pattern作為設計的元素在今日已經算是主流的方法，如果剛開始的軟體架構雛形採用pattern的方式來設計，只要這個架構可以應付目前的需求，那麼developer不懂pattern也沒關係，只要知道怎麼用（通常是直接copy別人的範例）就好了。但是，一旦現有的架構無法容納新的需求，需要加以擴充的時候，如果developer不懂pattern，那麼擴建之後的建築物，不但是違章建築，還很可能是危樓。

看到這邊鄉民們可能會想，有那麼嚴重嗎？

真的有！

***

奇怪了，design pattern與architecture pattern都已經出來10幾年以上了，又不是什麼新的東西，有那麼難學嗎？

說真的Teddy也不太確定pattern到底好不好學，只不過根據Teddy的觀察，在台灣業界（學校就更不用提了）developer熟悉pattern的比例還真是不太高耶（就是很低的意思啦）。試問，在這樣的環境底下：

• 如果你是team leader，你會採行big architecture up-front（如果可能的話，在開始寫程式之前先把軟體架構設計好），還是讓軟體架構逐步成長？廢話，當然是前者啊，採用後者不等於自己找死嗎 。
• 但是你的專案正在採用Scrum，敏捷方法告訴你，不要做過多的事前設計，所以你又想要嘗試讓團隊具備「讓軟體架構逐步成長」的能力。這下頭大了，怎麼辦？
  

Teddy今天重讀Alexander的《The Oregon Experiment》這本書，書中提到：

Somehow, the combination of tacit, culture-defined agreements, and traditional approaches to well-known problems, insured that even when people were working separately, they were still working together, sharing the same principles.

不知道鄉民們有沒有看出來，要讓軟體架構可以逐步成長，答案就在上面這句話。「even when people were working separately, they were still working together, sharing the same principles」，達到這樣的境界軟體架構才不會因為下放到每一個developer身上之後，就逐步長壞了（原本的出發點是希望逐步成長，但是最後結果變成逐步毀壞，更慘的還有人變成立即崩塌…Orz）。

如何達到此境界？答案很簡單：

• 古人有云：熟讀唐詩三百首，不會作詩也會吟。Teddy有云：熟讀pattern三百個，不會設計也會砲（打嘴砲XD）。總之，就是要多學pattern就對了。
• 還有一點，光會pattern只成功了一半，另外一半就是要知道如何套用pattern的流程。

***

這個套用pattern的流程有點小複雜，最近Teddy正在整理當中。目前發現其實Alexander所提到的套用pattern（嚴格講起來是pattern language）流程，本身就是一種「跨界開發的流程」。為什麼？試想一下，蓋一棟房子，或是設計都市計畫，這其中會牽涉到多少種不同專長的人？要把這些不同專長與背景的人搞在一起，這樣的流程當然是一種「跨界開發的流程」啊XD。

***

友藏內心獨白：今天忍住沒有置入性行銷喔。