Jserv's blog

Is Design Dead?

連續感冒一週，在家修養時閱讀了幾篇 Martin Fowler 大師的 [著作]，在此之前我拜讀過他的經典著作《Refactoring : Improving the Design of Existing Code》，第一章影片出租系統的 Refactoring 案例，仍讓我記憶猶新。之前的 blog [鼯鼠與軟體專案開發] 略述個人在軟體專案開發的過程中，作為專案經理或架構設計者，總不免需要作個稱職的「鼯鼠」，特別設計所謂「消費性電子」的軟體架構，更是如此。

在我小時候，曾規劃些 J2EE 的軟體專案 (based on Jserv)，除了 transaction 與 storage 的限制外，我可以明確說出軟體上的瓶頸與設計缺失，而如果是設計手機、PDA，或是其他手持裝置裡面的軟體架構，可就完全不是這回事。首先，基於價格或非技術的考量，可能使用根本不熟悉的硬體架構，也被迫作些高度 risky 的假設與評估，同時還要作硬體、baseband，或者 RF 的妥協，針對這些議題提出一狗票的 workaround，儘管最後作報告時，總是能畫出一系列漂亮的系統架構圖，然而，我們都知道，背後隱藏了難以計數修補的痕跡。

在我設計初期，僅可能透過 GoF 裡面經典的 23 個 Design Pattern，比方說我現在規劃的軟體架構中，使用了 Factory Method，其重要的概念就是讓提出一個(或一系列) Abstract Interface，讓 subclasses 決定該 instance-ize / initialized 哪些 classes，然而有許多非預期的因素涉入，看起來優雅的設計，被迫重複修改，把 "Dirty-hack" 嵌入，我遇過最有趣的例子就是設計 UI framework，結果原本理想的情況，竟然因為硬體的 backlight 考量而修改得面目全非。最近可能會花些時間思考 protocol / communication framework 與 software stack，果然我遇到不少來自 RF 的議題...

又，在時程不斷的壓縮、功能無止盡的要求，codebase 已經開始腐爛，本來是葡萄美酒的設計，現在則是酸溜溜的老醋，怎不叫設計者擔憂？(也難怪感冒一直沒好轉)，該如何進行 Refactoring，就是相當重要的議題，Martin Fowler 大師的 [Is Design Dead?] 給予我頗多啟發，而 Ai92 做了簡體中文的翻譯 [設計已死？]，可以加速我們閱讀的理解，對面大師的著作，不容我這個駑鈍者置喙，不過我到是想到一些有趣的議題。

Kent 提出的概念中，"Do The Simplest Thing that Could Possibly Work" 是相當重要的指導原則，對於許多要求 "Time-to-Market" 的專案 (老實說，我看到這個字，會不自覺的發抖)，幾乎可以說僅可能把現有的 solution 強加組合，甚至執行者都靠著「自覺」完成基本的設計，而且，重點是根本就沒有一家廠商 (至少是可能的 partner) 能對該專案所需要的軟硬體技術有足夠的掌握能力，以工廠的思維進行下，會發生什麼後果，可想而知。在 Refactoring 的過程中，我們檢視了既有的問題，在資源較充分而且經驗也足夠的前提下，原本的「直覺」逐漸演化為「複雜但必要的設計」，這就如 Martin Fowler 在 [Is Design Dead?] 一文所說的 "What on Earth is Simplicity Anyway?"。

注意：以上僅是個人經驗，與目前任職的公司或工作團隊無直接關係，請勿自行臆測。
由 jserv 發表於 January 16, 2006 12:04 PM