設計最難的部份是什麼？

December 20 22:28~23:20


最近部落格都在講 Teddy 看病和找工作的事，今天主題回到軟體上面來。Teddy 去年九月寫過一篇『需求分析書中最重要的資訊是什麼？』不知道鄉民們還記得答案嗎？今天想談一個類似的問題『設計最難的部份是什麼』？



請鄉民們花一分鐘想一下這個問題，或是我們把原來的問題簡化一下，改成『設計軟體最難的部份是什麼？』是如何寫 stories or use cases，如何套用 design pattern，如何設計 software architecture，如何用 UML 畫出漂漂亮亮嚇死人不償命的圖，如何 coding，如何 testing，還是如何喝酒...Orz...（問業務就知道最後一項技能對於結案的重要性）


一分鐘差不多到了，公佈答案，這個答案是從 The Design of Design 這本書第 22 頁抄過來的：


The hardest part of design is deciding what to design.
(設計最難的地方在於決定要設計什麼東東)


假設鄉民們先暫時同意作者 Brooks 老先生在書中的說法，那麼重點在後面（23 頁）的幾句話：


Then, slowly, I came to realize that the most useful service I was performing for my client was helping him decide what he really wanted.


這一段話 Teddy 最近看了更有感覺，為什麼？因為最近 Teddy 在思考未來的職涯規劃，有人可能看上 Teddy 的 Scrum 與 agile practices 經驗，有人可能覺的 Teddy 的 software architecture 設計能力應該還不錯，也有人看上 Teddy 去上過 CMMI 課程而想找一個懂 CMMI 的 PM（此人一定沒看過搞笑談軟工...XD）。其實 Teddy 這兩個禮拜也一直在問自己同樣的問題：Teddy 能夠做什麼？


Teddy 內心獨白：都沒人想問說 exception handling design 要怎麼做耶...白研究了...Orz。


不過剛剛在擠料的時候，隨手翻到這本書，看到這段文字，嗯，覺的上面這段話的『abstraction（抽象化）』做的真好，一言以蔽之可以代表 Teddy 的心聲（至少 Teddy 內心希望是這樣啦）。

***

既然設計最難的地方在於決定要設計什麼東東，那是不是說『需求定義』很重要？Yes，可以這麼說。那是不是說回歸到傳統軟體開發流程告訴我們的：


需求分析 -> 架構分析 -> 設計 -> coding -> testing 


這種流程，所以在專案開始實做之前要把所有的需求都找出來？


Brooks 老先生很好心的告訴鄉民們，No. 一樣還是第 23 頁：


Not only is the design process iterative; the design-goal-setting process is itself iterative.


... knowing complete product requirements up front is a quite rare exception, not the norm.


其實這本書看到這邊  Brooks 老先生就被 Teddy 『看破手腳』了，這根本是另類的 agile methods 代言人啊。

***

對一個軟體專案來講，定義需求的確是不容易的一件事，尤其如果要處理的問題領域（problem domain）本身就非常複雜，那麼光是要把『what to design』... 的雛型...搞清楚，就夠花時間了。更難的還在後面，由於『design process 』與『design-goal-setting  process（搞清楚要設計什麼的流程）』都是 iterative （就是要跑個好幾次，一步一步的來，才能把設計，以及到底要設計什麼搞懂），所以軟體開發才會常常被弄的很亂。


上面這段有點玄，請多看兩次。


Teddy 再補充一下，因為需求隨著時間越來越清楚，換句話說需求隨著時間一直在變（由模糊變清楚，或是由錯誤變正確），而相對的設計本身因為需求變了所以也要變。所以，如果軟體沒有『設計好』（或是說專案沒有帶好），那麼在這種『需求與設計的愛恨情仇交互作用之下』，最終的產品就不容易成功。

***

結論就是，老王賣瓜一下：做軟體要找到像 Teddy 這種『品德兼修（需求與設計）』都熟的人來帶專案，要不成功也難啊。

***

友藏內心獨白：最近突然覺的書看太多好像沒什麼鳥用，英文學好比較重要...Orz。