熟讀 Design Patterns 之後

July 16 23:10 ~ July 17 00:21

有在看搞笑談軟工的鄉民們應該都知道 Teddy 上個禮拜六晚上在天瓏書局遇到了一個畢業四年的學弟，這位學弟目前的工作是 programmer，正打算轉換跑道，朝向 PM 之路邁進 。在學弟正式『棄手從口』開始 學壞 學會打嘴砲之前，他還是問了 Teddy 一個技術性的問題。

學弟：學長，工作這三年來我已經把  GoF 的 Design Patterns 弄得很熟了，但是在接一些案子的時候，總是覺的好像還是少了些什麼。

Teddy：你這樣問太抽象了，可否舉個例子。

學弟：例如，我目前接手的案子，經常需要配合不同的客戶，而改用底層不同的 libraries，久而久之這樣導致我的 AP 邏輯變得很亂。總覺的應該要在 AP 與 libraries 之間定義個 interface ，但是因為不同廠商提供的 libraries 介面都不一樣，真的要定 interface 一下子又不知道要如何定起。

Teddy 內心獨白：上面的敘述是 Teddy 自行揣測加以修飾過的，當場 Teddy 其實是沒聽懂學弟的問題...XD。不管了，時間有限，就當一回蒙古大夫吧。

Teddy：你不是有修過 software architecture（SA）嗎？

學弟：沒有耶，那一年剛好沒開。

這...算你倒楣.....嗯嗯...既然身在天瓏，食材如此豐富，Teddy 就好好利用一下，就地取材將學弟引導至放 software architecture 書籍的這一邊。原本 Teddy 是要介紹學弟看 Contributing to eclipse 這本書，耶，書架上怎麼沒有。此時熊熊想起，這本書已經絕版了，改用 B 計畫。

Teddy：Pattern-Oriented Software Architecture 這一系列的書你可以參考一下，對於你的問題應該會有幫助。這一系列出了好幾冊，可以先看第一冊就好了。

Teddy 利用學弟正在看書的機會，趁機 落跑 跟學弟告別，並祝他轉換跑道成功。

***

鏡頭回到 agile methods，為什麼搞 agile  的人會告訴你不要做 big up-front design？奇怪了，如果不做 big up-front design，不給他好好地『打好基礎』，導致架構不良，日後軟體開發不是會遇到很多問題嗎？（Teddy 內心獨白：不知到為什麼最近對於打好基礎這幾個子特別反感...誰能了解 Teddy 的痛苦啊...）

害怕軟體會因為架構不良而需要一直改來改去，所以要打好基礎。因為要打好基礎，無形之中便落入了 big up-front design。但是做了 big up-front design，到頭來等真正 coding 的時候又發現『理想與現實的落差居然是如此之大』，結果還是一直改來改去。很熟悉的劇情吧，因為太多軟體專案都是這樣進行滴。

那到底要如何能夠做到 agile 書上所說的那種境界呢？其實答案在書上也都有，簡單一句話就是 developers 的技術能力要夠好，再搭配一些仙丹妙藥一起服用，效果更佳。說具體一點，要達到不做 big up-front design 又可以讓 software architecture 不會在日後的軟體開發過程中長壞掉，至少需要練到以下幾招：

• 要能活用 GoF 的 Design Patterns：這本書裡面的招式，只要能真正了解並活用，就已經拿到解決上述問題的門票了。
• 多看 software architecture patterns：有時候要解決的問題比較大，光從 GoF 的 design patterns 要推導出解決方案會耗時過久而且對於比較沒有經驗的人很容易就會套用到走火入魔。所以，還是那句老話，能抄就抄。別人的架構，就是最好的架構。問題是，該如何知道有那些架構可以抄啊？平常花一點點時間，稍微了解一下 software architecture patterns 有那些，等自己遇到問題的時候，在看看有那些是可以拿來用的。不要說沒有，鄉民們的問題有 99% 的機會應該都可以找到立即可用，或是至少具有相當參考價值的 architecture patterns。如果真的找不到，那肯定是書看的太少了。少加點班，多看點書吧。
• 寫 test cases 和 refactoring：任何東西，蓋的在好，用料在如何的實在，日子一久還是會退去原來的光彩。在軟體界，靠著自動化測試案例與 refactoring 來幫忙『修復』軟體設計與架構，這一點想必鄉民們都知道了，就不多說了。

***

不管是資深工程師，或是剛出社會的菜鳥，一旦工作之後，相信大家可自由支配的時間都相當有限。在這麼有限的時間中，如果要投資時間學對於開發軟體有實質幫助的東西，還是把 design patterns，architecture patterns，software testing，refactoring 給學好 C/P 值會比較高一點。至於 UML....把 Martin Fowler 所寫得 UML Distilled 『稍微』瞄一下就 OK 了，不要搞到走火入魔。這算是 Teddy 的個人偏見，如果有 developer 的 UML 熟到不像話，Teddy 還真懷疑此人是否會寫程式。

UML 大內高手留言：程式寫得好，要飯要到老（此為設計對白...XD）。

***

友藏內心獨白：對於『打好基礎 + UML』不爽的文章也罵得太久一點了吧。