最經典的問題

Tech.Ed 2006 台北，我就座在 回答問題的一方，

短短 40 分鐘吧. 許多問題 天上掉了下來， 但 一個問題 令我最最 印象深刻.

 

『技術越做越簡單了，我們身為技術人員實在很難不擔心以後一個國中畢業生 就可以和我做同樣的事情，你們微軟有什麼看法』

 

其實這好像是 記者問的話啊；這個問題 由其他先進前輩回覆了，但是 我的腦袋裡頭 卻有很多的感觸與想法 ：

因為這是很嚴重的 誤解 啊...

 

今年的 Developer Track 主題放在 .NET Framework 3.0 上，

在這個主題下，許多關心這個議題的人 已經參加了許許多多的 場次，欣賞到了 WPF, WF, WCF... 等超炫新技術

看起來 真的越來越簡單了... 以前都是 豆芽菜的 編碼過程.. 現在都有圖形化 拖拖拉拉 就可以搞出 你要的軟體

但如果您 真因為這些技術 "看起來" 很簡單 而受打擊，我真的很想替你打打氣：

 

WPF 的技術，看起來 可以讓你設計出 很漂亮的 應用程式了，但請各位 仔細想想，您真的可以 簡單搶下 "設計" 這個飯碗嘛?

對於當天 在場的 回答問題端 夥伴們，我們私底下 都聊過，也必須很尷尬的承認， 我們大概都稱的上是 中等以上的 軟體人員

(有些人如 蔣公 除外，他們實在太上流了..ha) ，但如果要 拖拖拉拉 一個 按鈕變成很漂亮， 那大概還做得到，但要做到一個 殺手級

美的讓人一摸就 不捨得不用的 介面，就必須要靠 充滿創意的 對圖形顏色敏感的 設計人員. (越高段的 軟體設計高手，設計UI上就好像越有一點 抱歉...:<)

WPF 的簡單，是希望 解決過去 設計團隊 與 開發團隊 溝通的 雜事.. 但這個簡單 絕對不可能讓 國中生 甚至 大學生 就很容易 hands on...

 

WF 的技術，也是另一項 "看起來" 超級簡單的應用... 以前豆芽菜 現在還真的可以靠 拖拖拉拉 就搞定了.

只是我想請問一個最簡單的問題，今天 有一個 單據審核的流程， 讓您採用 WF 技術來實做， 請問 您會採用 "循序式流程" ?

還是採用 "狀態轉移式流程" ? ， "Rule base 的流程也不錯啊" ?， 或者是 三者混合運用不是更好 ?

沒錯，這是決策了... 只是這個決策 包含了 管理性考量、架構性考量、團隊素質、維護、以及 Domain 相關議題，甚至 技術細節..

您還覺得 這樣的 拖拖拉拉 酷炫 技術，真的是您 就讀 國中高中 甚至大學的親朋好友、子女們 能夠做的來的嗎 ?

今年的 WF 主題是由我 傳遞的，讓人有這樣的誤解 表示兩件事情.. 我成功的包裝了 技術細節... 還有 我應該要檢討一下 下次的闡述內容...

 

WCF 的技術 把介面與協定 拉上了一個管理上的領域, ABC 的概念 (Address, Binding, Contract) 聽起來又是很簡單了

但是問題在 誰決定 Address ? 您是用了 哪種 考量 ?

誰決定了 Contract 的介面 ? 你是在哪個 因素下 決定了 Interface 與 method 參數等 就該長成這樣 ? 為什麼要傳入 DataSet 不傳入 String ?

是誰決策了 Binding 的方式， 透過 Remoting ? MSMQ ? Web Service ? 理由是什麼呢 ? 你有其他安全性等考量嗎 ?  效能你怎麼判斷呢 ?

 

我想我的重點在 替自己也替別人打打氣...

一個企業長輩曾說過， 當技術越來越簡單，最重要的是有沒有更完善的 "管理方式" "判斷能力"

這些是靠我們 經驗 與 思考累積的... 微軟的新技術 是在談 People Ready... 只要您 站在這立場上， 您會發現， 工具是在輔助您的 取代不了您的...

Comments

• Anonymous
  September 22, 2006
  我想技術只是工具，建構好的軟體還需要好的演算法、資料結構、好的架構設計、好的軟體開發流程.....這些只會越來越複雜，越來越專業。在建築工具越來越先進的現在，國中生應該還是無法蓋出101大樓的吧。