『How-to』,中文翻譯叫做 『如何』。例如底下的句子:
- 『如何使用』 Mindmanager(心智圖工具) 畫心智圖?
- 如何讓 JSP/Servlet 透過 JDBC 連結資料庫?;如何實做 EJB(Enterprise Java Bean?
『How-to』,是一種程序、是一種步驟,基本上,照本宣科,依照指導手冊或既往經驗,不需花太多心思,即可完成工作。
尤其,現在 『How-to』 的取得來源太多太多了,透過 Google,要找到程序文件、範例等…太容易了。
『How-to』 是站在 『用』 的觀點,如何 『使用』 某種工具,用得好,用得熟悉,能達成使用的目的就可以了。
『How-to』 重不重要? 當然,因為會增加我們在生活上的便利,例如開車,就是一種 『用』。
但是,若站在 『軟體設計』 的角度,那麼,』How-to』 可就不是最重要的了。
為什麼?因為,』How-to』 會讓你忘卻設計的本質;會讓你沒有自己的思維;會讓你少卻反思的能力;會剝奪你創意的天賦能力。
設計之所以為設計,也就在於能把自己的想法表達出來,無論對錯,自然會有回饋的建議與修正。
看過大陸某網站所提的一句:「軟體以用為本」。
個人覺得從使用者的觀點來看,無庸置疑;但若站在軟體設計者的角度來看,可要千萬慎思!從 『用』 的角度來開發系統,往往只會看到系統的 『外觀』,而忽略掉了系統的 『結構』。
不要以為,UML 就是設計;程式就是 『How-to』。
不然不然。業界充斥著太多這樣的假象了。
沒有自己的想法、沒有反思的能力、照本宣科,依循某書本或某專家的話來做…。這些才叫做 『How-to』。
舉一個例,透過 msn,問了一位朋友,什麼是 『Sequence Diagram』?
沈默了一會他回答:』表示某一個任務經過物件的順序 及使用時間,還有相關訊息流的傳遞』。
他的回答對不對? 那是最標準的定義,但是,一聽這個回答,我就很清楚,這位朋友沒有心中自己的想法。
為什麼?那是書本作者必須對大眾讀者有一個很明確的 『定義』,所以必須用很沈悶的工程語句來做敘述定義。大多看了書的讀者,就背了一大堆這些無聊的定義,卻沒有花心思於潛伏於定義背後的 『哲理』。
若要我回答,我會很肯定的 『說出』 我對 Seq. 圖的感覺:
『一群物件之間的互動合作完成所賦予的任務』。
這還悶了點,更簡明一點;
『一群演員照劇本演戲』。
對不對? 那不是我最在乎的。說得不對自然會有人來 『指正』。
我所在乎的是,有沒有真正說出心中自己的體會。
軟體設計師,要多花心思於 『What』 and 『Why』。這些,非僅從書本的知識得來,更需要從生活中體會、觀察、保持好奇心,多花時間與自己的內心對話… 才能有自己的體悟。
例如,有人問我要不要教授 EJB?
若是 『How-to』 對 EJB 的實做,那確實六個小時就可以學得了的。
但是,我非常懷疑他學 EJB 的目的。問了他:學 EJB 的目的是什?又,到底,你認為什麼是 EJB? 他回答不出來。
我也曾經問一位很 『高竿』 的 Java 工程師,EJB 的目的何在?他覺得理由是 『ReUse』。
這是一般 EJB 的技術書籍及規格的制式答案。
是嗎? 那麼,難道,使用 Java Object 就無法達到 『ReUse』 的目的嗎?
其實,重點不在於是否 EJB 是以 『ReUse』 為目的。而是在於是否我們真有用心於思考這些書本所提的 『定義』 或 『說明』,有太多…,充斥了 『表象』 與 『假象』。
做一個簡單的結論:
- 會 UML、懂 『物件導向』 等 『技術』, 不代表你會軟體設計,就是軟體設計師。(簡單的判斷,若無法以最平常的生活化例子來解釋 UML、物件導向,那麼,我不太相信他懂軟體設計)
- 程式開發不代表 Programmer 沒有將軟體設計蘊含其內。
- 不是擔任 SA/SD、Architect、Designer 等角色就是軟體設計師
所以,到底什麼是 『軟體設計』?
肯 『思考』 的人,就是軟體設計師。
也就是說:
當你自己能具備自我的思維、反思,並懂得回饋互動時,你就是軟體設計師了。
而這些,都是每一個人與生俱來的天賦能力。
我們所要努力的,也只是將這與生俱有的天賦能力給激發出其潛能而已。
Kenming's 軟體設計
Kenming's .NET 實作
since 2004.05.11
關於本站授權聲明