這兩天與 Ringle 一同至高雄某家規模蠻大的專案開發公司，從年前兩日的 UML 課程教育，然後年後第三日係以座談的方式，面對面聽取學員們在實際專案開發時，利用 UML 設計時，所遇到的問題，同時並檢驗他們的設計產出是否正確與適當。其實呢，算起來也有半顧問的意味，當場就拿出他們利用 EA 所開發的設計圖，檢驗、評論、說明，然後協助直接修改，甚至轉出程式碼。

我覺得學員們真的很認真，讓我有些訝異，在年前只上過短短的兩天 UML 基本課程後，竟然在一個月的時間，就已經將某一系統的需求訪談記錄建構為使用案例圖，並且還產出系統分析的類別圖與循序圖，就只差程式碼還沒出來而已。

一整天的座談，就針對這些設計產出來 “指指點點”，說明他們在 SA/SD 設計的一些茫點與比較顯明的謬誤。但大致上，我們到蠻給予高度肯定的評價，重點是有沒有 “心” 要做，其它的都還是次要而已。他們專案經理，也非常認真，提問了很多的問題。我發現到，都比較偏向是專案管理面的範疇，諸如設計產出是如何承接、由擔任什麼角色的開發人員負責、該如何 “檢驗” 他們設計的品質 …等等。專案經理重視 “制度”、”製程” 等，那也是當然的，不過，到讓我發現到，一個很明顯的問題：想太多了。 這會導致在分析/設計階段因瞻前顧後，花太多不必要的時間在小細節上，而陷入了「癱瘓(paralysis)」。

如同寫文章，越想求完美的人，越不容易動筆。分析/設計 也是如此，就是因為想要 “分析” 更精確、”設計” 得更完美，讓系統開發規格更明確 …這些心理因素的作祟，而導致在某個開發的局部就 “僵住”，好像是動彈不得、陷入瓶頸的感覺。

何以見得？ 答案太明顯了：程式碼沒有出來！

傳統 SA/SD/PM 最大最大的一個茫點是，如果沒有開立明確的系統分析與設計的規格，包括 Database Schema，那如何能讓程式人員寫碼呢？ 這不就是傳統 “Waterfall(瀑布式)” 開發流程的詬病？ 許多軟體公司以為，採用如 RUP 先進、國際標準典範的開發流程，就會從 “瀑布式” 的開發魔咒解套，問題是，當你把 SA/SD 拉長數星期以上的開發，才開始展開 “Implement” 的實做階段。這種方式，如同 “藍皮綠骨”，根本還是 “瀑布”，因為，RUP，甚至是現今必然要嚴謹遵循的開發原則，最重要的一個精髓之一： I&I (Incremental and Iteration)，根本沒有確實實踐。

從需求分析、設計、至實做，甚至包含測試，要花多久時間？ 我與該公司 PM、系統開發人員說，完成一個使用案例的實現，第一個 Iteration 不能超過三天。 他們聽了覺得挺不可思議的。怎麼可能？

唉，為了證明，所以，又要請出我們的 “呂布” 級戰將 Ringle，將他們系統的一個使用案例，從頭作一個分析，補充上使用案例敘述、設計類別圖，描述循序圖，然後利用 EA 的 “Code generator” 功能產出程式碼框架到 Visual Stuio .Net 的 C# 專案，再補上一些虛擬碼的註解，同時又加上功能測試程式碼。第一個 Iteratin，整個過程，還不到兩小時。

第一個 Iteratin 當然不可能包括完整的屬性與行為細節，那並不是第一個循環要關注的事情。即使資訊不足、流程不明確，一旦確定使用案例的目標(Goal)，就應該快速跑過一次 RA/SA/SD/Implement 等開發階段，用最短的時間，完成可以執行的程式碼。如此，最重要的幾個目的就能達成：：增進團隊整理信心、建立系統雛形結構、快速取得回饋(Feedback)。：

這麼說好了，確定目標(使用案例)、找出達成目標的手段(分析/設計)、馬上執行與測試(Implement and Test)、問題收集與回饋，這才是 “Iteration” 的真諦。

況且，程式碼是最現實的產物，客戶、老闆眼中一定要看到程式碼，才算 “眼見為憑”。我一直傾向是要在最快的時間內，一確立實作的目標，先經過簡單的設計(Simple Design)，就要快速產出可執行的應用程式碼以及功能測試碼，這才能確保軟體分析/設計的信心主要來源。

請記得，世間沒有一開始就是完美的事，分析/設計更是如此。我從來都假設需求不明確、企業流程有問題，但只要經由需求分析確立目標，就可以馬上著手系統分析與設計，當然也就可以立即產出程式碼了。當有個 “框” 之後，再來才是逐步修正細節，包括企業規則與邏輯等。 (當然，也不可能無限上綱，永無止盡的 Iteration。過與不及，均不妥。)

分析/設計，甚至包括程式碼，都只是手段，既然是手段，當然不需要太重視，因為手段會時時視需要調整與修正的。我最重視的是原則，什麼原則呢？ “把握當下，泰然面對無常”！

我在上個月看 Discovery 節目時，該節目很有趣，是介紹有史以來，前 10 大受歡迎與戰鬥力強的坦克車。

嗯，還是從二次大戰開始介紹的呢，其中，包括德國的虎式與豹式坦克，都名列上榜，而更為驚人的是，蘇聯的 T34，當時在德蘇大戰中叱吒風雲，令德軍第一次感受到他們的武器不如人，是名列 10 大中的第三名。而至於第二名的坦克，則是活躍於波灣戰爭中，但卻也有令人苦惱的問題，太過龐大與吃油量太重、維修不易等問題。

嗯，這要與我談軟體模組化有何關係呢？ 嘿，當我看到榮登 Discovery 第一名排行榜的坦克時，實在驚訝與讚嘆不已。榮登第一名的是：改良過的德國製坦克 — 豹式二代。

話說原來，當時二次大戰中，德軍鑑於蘇聯 T34 的優異與靈活又兼顧火力的性能，而加以參考並改造他們的坦克，當時就有豹式坦克的出現。但是，豹式坦克雖性能優異，且砲火猛烈，但是，太容易故障了，而德國人龜毛完美的性格也反映在該坦克上，加上太多不必要的束縛與修飾，而這些，是在激烈的對戰中，大部分是不需要的。

而今的豹式二代，仍然呈現著豹式一代優異的性能與保持了德國人求完美的設計性格，但卻改善了最重要的一點 — 快速維修與保養的能力。怎麼作呢？在所有前 10 大坦克中，也只有豹式二代具有現今結合硬體與軟體的彈性設計 — 模組化！

我看了節目的展示，嘴巴合不攏嘴，實在驚訝不已。豹式二代一旦發生故障，維修人員只要拿出筆記型電腦，連結坦克的介面，即可以診斷出坦克的那一部分出了部分，再來呢，不是去拆開出問題的那一部份，而是，整個模組抽出來，就好像診斷出 PC 的顯示卡或記憶體模組出問題後，拔出來，再把新的給置換進去即可。我第一次看到，坦克的模組化設計，也能造成這種 P&P(Plug-and-Play) 的可抽換效果。

回歸軟體，看到好多產品都號稱是 “模組化” 的設計，每次呢，我到世貿軟體應用展，只要問展示販售 “進銷存” 產品的廠商，能否將 “進貨” 模組，與某家或是本來公司內部既有的 “存貨” 系統給 “兜” 在一起呢？ 嘿，得到的解決方案就是利用 “資料庫” 來作系統整合。

而以資料庫為整合的解決方案，我就很清楚了，這些號稱是模組化，根本只是在業務層級的邏輯面，卻沒有確實在實體的系統面，達成模組化的設計。若要能達成在實體系統面的模組化設計，必然是首重於介面(Interface)的設計與溝通，至於資料庫，只是各個模組的 “私有倉儲(private storage)” 罷了。以資料庫為主的整合，是屬於 “草本植物” 式的整合，雜草叢生，而根卻早已彼此糾纏不清，剪不斷、理還亂了。

連龐然大物般的坦克車都可以確時達成模組化的設計，怎麼這些軟體產品，談模組化這麼久了，卻仍是用幼稚的資料庫整合方式，而無法確實分隔每個可被抽離與置換的模組，並且可以很容易地利用測試工具找出是那個模組出問題，乾脆就直接把壞的模組給 “抽換” 掉呢？

下午在某家公司討論架構設計的顧問服務時，與該公司主管會後的閒聊，其中一個話題，就是聊到 JavaScript，我又不假思維的回答：JavaScript 是爛東西。

啊！我亂說話的毛病又犯了… :-/

前兩年，也是在某家軟體公司所承接上億元的案子上，當時我是某家顧問團隊的 Member 之一。在與該公司數十位軟體開發人員的顧問輔導會議上，我也是直接就講出這句話，當然，我會去說明認為爛東西的理由。不過會後，我們團隊其中一位 member 很不高興，認為我不應該如此的批判，還有一個重點，當時，他是負責教授學員們 JavaScript 設計的講師，他說了，如果我對未來會上課的學員直接批判 JavaScript，那他如何教課呢？ 是滴～ 不過當年我 “年輕氣盛”，就與他說了，那麼，我們課程互換，他來教授高階設計，我來教授 JavaScript，然後，也允許他直接批判 JavaScript。;)

這是之前的往事了．．． 想起來還是蠻有趣的一段話題。

對 JavaScript 印象不好的原因，源自於 ASP/JSP 網頁設計的時期，其實，我也很清楚，程式語言本身，那有什麼爛不爛的，會爛的原因是… 程式設計師把它變成爛東西了。 :>>

這怎麼說呢？ 我看到好幾位的程式設計師，因為非常不習慣於原來從傳統 Client/Server 的表單設計，因為潮流，公司需要把系統 Web 化，而往 Web 設計時，卻發現到，怎麼以往 Client/Server 的表單很好寫，為何轉到 Web 後，不僅開發工具的缺乏，以往很容易表達如 “Master/Detail”，卻怎麼在 Web 上如此難寫？

舉一個最簡單的例子，Client/Server 的表單設計，當操作人員輸入客戶ID 時，按【TAB】鍵移到下一欄位時，就會自動顯示出客戶姓名。嘿，當時若用 ASP/JSP 來寫這樣的作法，並不是一件容易的事呢。

為什麼？ Web 的表單設計，是當操作者填完整個表單的資料後，才會按【Submit】送出至 Web Server 處理，處理後傳回結果，連線就中斷了。所以，Browser/Web Server 的溝通，是屬於 “Stateless(無狀態)” 的方式；相對於 Client/Server，因為表單一直是連線著資料庫，不管你有沒有在用，資料庫就是一直連線著，我把這稱之為 “佔著茅坑不拉屎”。:) 表單與資料庫的持續連線，稱之為 “Stateful”，也正因如此，所以表單要資料處理時，隨時就可以至資料庫 “撈資料”。

“Stateless” 是為了節省系統資源，因為 Web Server 所服務的 Client 是至少以百計以上，不可能讓每個 Client 都一直連線著；”Stateful” 會浪費系統資源，但是可以盡善盡美地來服務 Client，在 MIS 內部，操作者規模在 100 人以內，系統的負荷是不會有問題的，當然就可以這樣作。

結果，許多程式設計師，搞不懂 “Stateless” 與 “Stateful” 的原理，不僅是新手而已，也有很多算是老手級的了，以上剛我所舉的例子，為了能達成輸入客戶 ID 後，就能馬上秀出客戶姓名，竟然就乾脆一次把位於資料庫的客戶資料全部傳到 Browser 內，然後，用 JavaScript 寫個 For-Loop 的迴圈啊，來找出對應 ID 的客戶姓名。

離譜吧？ 會犯這種低級錯誤的，還可真不少呢。 除了增加傳輸頻寬的負載外，根本就沒有基本安全性的防護，赤裸裸地將客戶資料全部儲存在 Browser 內。我在輔導 Web 化的專案時，絕對是嚴禁利用 JavaScript 作上述這種事情，甚至，也不容許企業邏輯寫在 JavaScript 內，例如，計算員工薪資，一定是在 Middleware 來負責處理的。

難道，JavaScript 真的是一無是處，是個爛東西？ 不然啦～ 我會用 “爛東西” 來凸顯，其實是要提醒，程式設計師，可千萬不能濫用。我們要為 JavaScript 來正名，瞭解它真正的角色與責任。

我最激賞的網頁設計技術，就是微軟所提出的 ASP.NET。在其技術裡，總算找到了為 JavaScript 定位的最好名稱了，就是 “間諜(Spy)”。

且聽我道來～

網頁設計的技術，最大的挑戰，就是要能把 Stateless 的現實環境，”模擬” 成具 Stateful 的狀態。也就是說，Web 化的表單，即使還沒按下【Submit】之前，很有可能會根據某某欄位的資料，而即時送至 Web Server 處理，並傳回部分的結果，但請記得，因為表單還沒有完全送出，所以，表單的資料，是需要被保存其狀態的，ASP.NET，簡單的說，就是利用在 Web Server 有個 “State Bag” 的機制來為 Client 儲存尚未【Submit】的表單資料。

那麼，是誰來負責傳送欄位的資料？ 當然就是 JavaScript 囉～
UI 的設計，除了 Style 的美感之外，在技術面，最為重要的，就是 UI 元件的狀態與事件(Event)的處理了。仍然舉上述的例子，當輸入客戶ID 後，操作者可能按下【TAB】鍵或是以滑鼠點選移至下一個欄位，這兩種動作，都會觸發了事件，此時，JavaScript 當作 UI 的事件處理者(Event Handler)，收到事件後，根據 UI 所設計條件邏輯，來決定是否後送至 Web Server 來處理，再把結果傳回，並秀出在 UI 上。整個後送的過程，操作者完全沒有感覺，可能就是畫面閃了一下，其實就是作一次 “Refresh” 的動作，JavaScript 已經偷偷地把資料後送至 Web Server 處理了。

Javascript 除了可以在 Browser 端，作一些動態的展示呈現效果外，在企業應用系統的 Web 化表單設計，就讓它回歸最單純的角色，UI 事件的處理者，簡單的說，就是 “間諜”。如此，就不會把 Web UI 的設計搞成複雜又糾纏不清，JavaScript 反而會變成 “好東西” 了。 😉