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

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

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