The Art of Design

為甚麼好的設計會來自於差的設計呢？ Scott 在 Why Good Design Comes from Bad Design 提到攻讀 CMU Computer Science 博士時選了門介面設計課，第一堂課上他發現一位年輕人素描著隨身聽的各種變異版本，而且圖紙上已經堆積了三、四十種不同考量的版本了。 Scott 於是湊過去問這個小伙子「幹嘛費勁畫那麼多草稿？」，小伙子發楞了好一會才笑著回說：

I don't know what a good idea looks like until I've seen the bad ones.

經過時日洗煉， Scott 後來也體會到當初認為多餘的作法，其背後的精神，他提到：

Each new idea I sketched out was more informed than the last. Each bad idea illustrated some important aspect of the problem that I hadn't thought about before. Out of every five or six ideas, I'd have one or two that might be feasible.

I learned the right way to present ideas–you have to show the other candidates in order to help support the good ones.

When the design student showed me his sketches, he was showing me that he was a designer. All creative, talented people recognize the value of process, and have no concerns about revealing to others that it takes many bad ideas to obtain good ones.

這讓我想到 C++ 的老爸 Bjarne Stroustrup 也曾經提到：

At the start of an ambitious development project, we do not know the best way to structure the system. Often, we don't even know precisely what the system should do because particulars will become clear only through the effort of building, testing, and using the system. How - short of building the complete system - do we get the information necessary to understand what design decisions are significant and to estimate their ramifications?
-- ref. The C++ Programmming Language, p710

這段 William 翻譯如下：

偉大的軟體開發專案開始之初，我們並不知道什麼才是最好的系統組織方式，甚至連應該做出什麼樣的系統都不知道；因為唯有透過打造、測試、使用系統的過程，一切才會明朗。如果尚未打造系統，該如何才能獲得必備資訊以事先瞭解有哪些重要的設計決定？
-- ref. 中譯本, p930

至此，應該不難體會：無論是要創造一個好的設計或成就一項偉大的專案，非常重要的就是要畫出許多「草稿」、進行多項測試及「實驗」。
知道要「作實驗」是個好啟發，卻不夠充分，因為我知道只有能很容易進行實驗的情況下，來談多作實驗才顯得實際。實驗容易進行，人們才有耐性多嚐試，一次又一次、反覆、輕快地測試各個主意，如此，設計才有機會趨於完善。這也是為甚麼大家開發軟體時會找個合用的 framework 來執行 Unit Testing 。
人們進行設計時，常常將一個大系統拆成一塊一塊，然後一次一小塊，個別考量。每一小塊都琢磨得差不多了，再把它們組一組，最後「啪」一聲，整個系統就完成了 :)
唉，事情要是都那麼順利那就好了。實際上我們會遇到許多困難，例如：怎麼把一團模糊的設計概念拆卸成小塊？每一小塊要如何進行設計，將來才兜得起來？每個小塊怎麼兜成一個整體才會穩固？為了無礙進行實驗、兜出想要的設計，還得想法子讓每個小塊都易於抽換。
一個個小塊，就是我們慣稱的一個個模組，而模組設計的目標就是讓每個模組要

• 夠獨立，不會互相干擾。
• 夠彈性，滿足抽換的需求。

例如設計自走車時，我們不將輪子的輪軸跟馬達的傳動軸直接連起來，而是在兩者中間放個聯軸器（a shaft coupling）的裝置，如此抽換馬達或輪子時都可以省許多功夫。
又例如設計電子元件時，要求有高輸入阻抗（Z_in），及低輸出阻抗（Z_out）；前級元件的輸出阻抗（Z_out）要遠低於後級元件的輸入阻抗（Z_in），兩者最好相差十倍以上（以達成最大電壓傳輸），如此我們可以致力於前後級個別的設計，不用憂心它們訊號彼此干擾。
也許剛好自己較熟這塊，總覺得軟體的模組設計花招更多，以 OO 領域來說，相關準則有：

• Open-Closed Principle
• Software entities should be open for extension, but closed for modification
• Principle of Encapsulation of Variation
• Liskov Substitution Principle
• Dependence Inversion Principle
• Abstractions should not depend upon details. Details should depend upon abstractions.
• Program to an interface, not an implementation
• Composit/Aggregate Reuse Principle
• Law of Demeter -- Least Knowledge Principle
• Only talk to your immediate friends. Don't talk to strangers
• Interface Segregation Principle

優秀的程式師總是在思索、尋求「一勞永逸」的作法。學習時不妨從具體案例開始；學成應用時，要改而著重背後的精隨，才不會被細節淹沒。這些年下來，我體會到這個精隨就是「因應變化而設計（Design for Change）」。
要明白 Design for Change ，這裡強烈推薦翻翻 Refactoring 裡提出的壞味。個人認為其中又以下列兩個壞味最為深刻：

• Divergent Change
• Shotgun Surgery

Tags: [design] [concept] [programming]