什麼叫 “How-to”?

“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 等角色就是軟體設計師

所以,到底什麼是 “軟體設計”?
肯 “思考” 的人,就是軟體設計師。
也就是說:
當你自己能具備自我的思維、反思,並懂得回饋互動時,你就是軟體設計師了。

而這些,都是每一個人與生俱來的天賦能力。
我們所要努力的,也只是將這與生俱有的天賦能力給激發出其潛能而已。

文章導覽

   

共有 3 則迴響

  1. Hello wordmar:

    您的意見非常非常地寶貴,太好了!

    我著重於 “軟體設計” 這個字眼,其目的是在於 “活化思維”,如此而已。
    所以不希望加諸在 “設計” 這個字眼,太多的負擔或是 “門檻”。越簡單、越輕鬆是最理想的了。

    一而再而三地強調,只要軟體人員能 “反思”,有自己的 “主見” 與 “體會”,這就夠了。這已經達成我推銷 “軟體設計” 的 “目標” 了。 🙂

    至於技術面如 EJB 等問題,我們可是很認真的在研讀喔,只是不特別凸顯罷了。 🙂
    三、四年前,我們就辦了多場 EJB 的研討會,Java 週報的第 1~3 期 還有我個人寫的一些文章喔。

  2. 軟體設計的會與不會

    看了王兄精闢的見解之後,我也來響應我的看法:

    設計,現在的用法比較偏向從外國來的定義,在韋氏辭典(Merriam-Webster)裡面說的是
    1、to create, fashion, execute, or construct according to plan
    2、to conceive and plan out in the mind
    在教育部字典中的定義是:謀畫算計

    我個人的認知是:它可說是一種心智的活動,是一種達到目標的過程中,思考的部份。

    所以我認為要談設計的話,所談的內容一定要包含”目標”,而在真實世界中,一定要考慮的東西是”資源”,如果可以達到的話,就可以算是不錯的設計,我想!人活著,可說是隨時隨地在進行設計的行動,所以設計並沒有”會”與”不會”的問題,頂多是從某個角度來評量它是否較優秀。

    另外呀!我認為EJB(其他各式各樣的技術亦如是)是為了在設計中所要解決問題所採用的手段與技術,若談軟體設計,直接就談技術,那我們可說它是一種以技術為導向的解決方案,但重要的是它是否完成了目標,解決了問題,該談的是後面的思考過程,我很讚同王兄所說的:會 UML、懂 “物件導向” 等 “技術”, 不代表你會軟體設計。

    但我想補充的是:設計沒有會與不會的問題,設計人人都會,只是真的要拿來檢視的時候,可能就要討論到思想和藝術的層面了。

    可能用”好”與”不好”會更適當些,而且有評估的準則(如設計是否有達成目標,是否能以小搏大)。

    用更廣的角度來看:UML、物件導向也是軟體的技術之一,子曰:君子循理,故常泰。小人役於物,故多憂戚,我想!我們要多向克明大師學習,要役物而不要役於物,早日擺脫被人恥笑的日子^^

    當然,軟體是很好玩的一件事,有太多的面向可以討論,和世界上很多的事情一樣,會隨著每次不同的人事時地物的不同而不同,希望大家除了悠遊在很多專有名詞或是技術之餘,也能多多聊聊相關好玩的事物。

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *