Kenmingの鮮思維

定位 — 目標、願景、使命：

• 使命(Mission) — 提升及協助軟體開發人員在軟體設計的專業技能及必備素養。
• 目標(Goal) — 把軟體做 "軟"。 (Keeping Software Soft !! )
• 願景(Vision)
  • 成為大中華地區的專業軟體設計中心。
  • 成為軟體設計領域的『麥肯錫』。

核心能力：能 『言』 善 『道』。

• 言 「軟體設計之理」。
• 善 「軟體設計之道」。

軟體設計重視的方向：

• 修鍊的思維與基本功
  • 從本質看軟體設計。
  • 設計與實做，是一體兩面。
  • 軟體設計是人性化、生活化，非純工程與技術。
• 重視
  • 觀照整體的能力。
  • 軟體整體的架構(Architecture)與結構(Structure)。
• 軟體設計者的使命
  • Keeping Software Soft ，把軟體做軟。
  • 三法印—保持系統的彈性、延展性、可重用性。

教育(Education)的目標：

• 傳授學員軟體設計的正則思維。
• 傳授學員軟體設計的觀念與技能。
• 指導學員流暢地整合軟體設計與程式實做。
• 讓學員瞭解軟體設計是有趣的、生動的，而且，是高度生活化的。
• 藉由軟體設計，引導學員具備反思的能力。

課程的特色：

• 強調『軟體設計實做』；而非『程式設計實做』。
• 以實際案例(Case Study)，說明從分析、設計至實作等開發過程，作為課程的主軸。
• 每一開發階段皆有實際產出(Artifacts)，包括UML設計圖及實做程式碼。
• 固定舉辦研討會及提供線上討論區，提供專業建議，協助學員永續成長。

偶然與 Ringle 的女朋友 "一ㄚ珠" 比賽寶石方塊。
沒想到竟然敗於一個女流之手，輸了兩杯咖啡，還被笑說要好好練習再來挑戰啦。 >:(

以前號稱 "電玩天才" 的我，玩小精靈 5 元可以玩 2 個小時；玩雙眼鏡蛇 5 元可以破整整 10 大關兩輪，怎麼會敗在這種小遊戲呢？

嘿，這個小遊戲還可真迷人，安裝 msn 後可以約對方 "雙打" 比賽。後來發現，可以在 msn 的網站玩線上單人遊戲。
這兩天的練習，最多可以玩到 41000 分，前天總算報了一箭之仇，贏了ㄚ珠了

不過，聽說有 "高手" 可以玩超過 數十萬分(Time-based)，挖勒～ 我現在連要超過 10 萬分都覺得異常困難。有必要再加強練習，並要儘速研究該遊戲的 "本質" 為何。

愛好此道的 msn 朋友們，可以透過 msn 找我玩。
不過，可是要論勝負的喔。輸了要請一杯咖啡(可不是三合一那種滴)。;)

剛好開站滿一年，我的 Blog 系統期間從 MT 更換為 B2evolution。

從原來每天瀏覽人數不到 5 人，到最近幾個月每天都有數百人瀏覽。我想，每個 Blog 的主人看到自己網站的瀏覽人數及網友們的互動等，都會促進文章寫作的有效動力。

2005/02/22 當天的網站瀏覽人數破千了！真是開心！！
代表我的 Blog 也小有名度囉。

再加一把勁！！ 下次的目標就是朝向網路出版了。不一定只是軟體設計的出版。有感於我遇到好多軟體開發人員充滿了對工作的失望與無奈，我希望能將心得體會及研究等，分享提供及協助其在心態的轉化與強化上。還有，個人目標的設定、時間管理及規劃等，這些都是許多軟體開發人員(也包括其他職場的朋友們)在現今詭譎多變的資訊時代所需具備的素養。

這兩天，有許多位網友加入我的 msn 聯絡人，我挺開心，也喜歡與他們透過 msn 溝通對軟體設計等的想法。

才剛寫完一篇：「甚麼是 "How-to"？」。
結果這幾天，很失望，問我的盡都是 "how-to" 類的問題，還是與軟體一點關係都沒有的…
我覺得，這些網友挺不尊重我的～

例如，有個網友問我：

下午 11:51:54  ... 寄密件副本 一般郵件原始檔會被加密 

下午 11:52:07  ... 有辦法可以反解回來看出寄給那些email 嗎? 

又有位網友問我：
架設 Blog 的頻寬架要多少？ 該申請多少頻寬來架設 Blog 才夠？

唉！ 這類的問題，利用 Google 查一下不就可以找到資料？
例如，打個關鍵字："密件副本" and "加密"，可以找到一堆的參考資料。
又如，打個關鍵字："Blog" and "頻寬"，不就可以找到一堆架設 Blog 的頻寬參考資料呢？

很奇怪，真的很奇怪，為什麼連最基本找尋資料的意願都沒有呢？為什麼都想抄捷徑直接問這類的 "How-to" 呢？為什麼我會被視為是回答這類 "how-to" 的人呢？(這點我覺得最可悲)

當然，這些網友不是無心之過，我想，他們的生活應該與朋友們經常相互之間會問這類型的問題。

但是，相對地，我也該思考學會如何 "婉拒" 這類 "how-to" 的問題，該如何 "引導" 他們找尋自己所需要的資料。

他們可能以為這些問題我都會，殊不知，我幾乎都不會。只有當需要的時候，才會去找資料參考。"用完" 後我也就都忘記了。

日本電視台的節目實在特別又優質。

今晚 9 點多時，到客廳休息一下，不經意看到 JET 日本台播映「自己自足物語I」節目。PM 9:00 ~ PM 11:00。

介紹的是許多愛好大自然山林生活的一小群日本的小人物們，寧願拋棄世俗的都會生活，在沒有水、電的山林裡，過著自給自足的生活，卻仍然甘之如飴。

每一位介紹的主角人物都有一個共同的特色：他們都有一個夢想且均將其夢想實現～崇尚大自然，極為熱愛山林生活，自給自足，養雞、種水果、下田耕種等。常人的眼光來看，這種日子是非常地苦，但他們卻認為這才是人生最大的樂趣。

節目中介紹，有個女孩子，長得還挺漂亮的(還真的是漂亮喔)，才 26 歲，旅行許多國家後，就自己一個人跑到山林裡，自己種菜、自己下田耕種，所有的飲食均是親自所採下的蔬果烹調而成的。這樣的日子，她過了六年，仍舊是甘之如飴。

該節目很特別，製作好某某主角的山林生活錄影後，過了四年，又再去訪問他們。然後發現，他們的日子仍然與四年前沒啥改變，他們的樂趣，仍然鍾情於山林的自給自足生活。

人們可以選擇過他們想過的生活，不受限於世俗的規範，實現自己的夢想。我想，這才真的叫做「人生」。

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

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

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