爪哇人的Ruby (1)

1995年，我是個年輕小夥子，天氣好的時候會結伴打打藍球、游個泳，雖然偶爾夜裡沉迷在魔獸爭霸2的網路對抗，但可以自豪的說，我體格健壯輕盈，擁有結實的六塊腹肌，和不實人間煙火的遠大理想。

當時陪伴我的桌機是Pentium 100，搭配Tseng ET4000顯卡，還有32MB的記憶體，和一顆540MB的大容量Quantum牌硬碟，這些都是逸品，以當時來說。

雖然還是習慣使用Dos 6.0加倚天中文連上BBS，但Windows 95的問市的確也在我的硬碟中佔了一席之地，儘管我還是留有一份Windows 3.1。

那時想用C++寫個視窗程式並不是那麼容易的，鎖碎的Win32 API，混雜著Win16時代的遺毒，加上煩人的C++指標，如果再配合MFC，新手想上路得有一定的決心。

Java的出現立即吸引了我的目光，類似C++的語法，更純的OO，終極的跨平台解決方案-JVM
，內建的AWT可以優雅的建立視窗介面程式，而iostream不止檔案讀寫，也完美的將網路Socket讀寫整合，還有Applet可以輕鬆的建立高互動性的網頁……種種變革，讓打開文字編輯器撰寫Java變成是種享受。

JDK1.0體態輕盈，只有幾MB不到，並且各種姿態都深深吸引了C++使用者的目光，而且使用記事本就能輕鬆駕馭他，生產力驚人，比使用複雜的Visual C++ MFC 還更有生產力，雖然執行效能較C++差是罩門，但大部份的事情其實不需要多高的CPU執行效率，通常程式花最多執行時間的地方是在IO，而這點Java並不會比較差。

十二年過去，Java果然成長為主流程式語言之一，許多企業選擇Java做為建置資訊系統的主要語言，我也靠Java而得以擁有穩定的收入，我的工程團隊使用Java為客戶導入各種系統，賺取錢財。

這些系統使用JDK5.0，搭配各種MVC Framework、O-R Mapping Tool或是J2EE Container，硬碟的使用量成長不少，而一個新進程式員要上手前的訓綀也難上許多。

愈來愈多Framework使用XML做設定檔，設定檔不難，但是很雜，這逼得我必須使用先進的IDE開發工具協助管理這些設定檔，並且在變更發生時同步幫我更新許多設定檔、Java Bean Class…，這感覺和當年使用MFC開發必須大量依賴IDE提供的精靈一樣，鎖碎了、煩了…

我可以用Java完成各種任務，但那過程已經不再是享受…Java 肥了，和我一樣，我老婆說現在看著我的身體做愛，已經不再是享受了，但我的確比以前會賺錢。

Ruby on Rails 最近紅透半邊天，Ruby是個富有OO特性的Scripting Language，Rails是個革命性的MVC Framework。

Ruby有精簡易懂的語法、比Java更純的OO，而且Meta Programming、程式碼區塊、Mix-In等好用的OO特徵都是Java沒有的，這使得Ruby語言有驚人的生產力。

Rails使用Ruby的特性開發出來，你可以用他來建置MVC Web App，配合好用的O-R Mapping，但是你不再需要重覆的設定XML，重覆的更新Java Bean。

我會再之後的文章中以Java人的觀念介紹這些Ruby好用的特性。

SCEA第二階段---我的步驟

上回提到了文件中應該要包含Assumption、Design Decision、Diagram等要素讓它更具可讀性，這回我要講講設計的主軸應該要如何開始撰寫。

試題中提到了第二階段必須交附的四大項目：

1. Class Diagram --> 1張
2. Sequence Diagram --> 每個Use Case 1張
3. Component Diagram --> 1張
4. 輔助說明文件(需要包含Assumption和Design Decision)

由於我個人畫圖及寫文件的技巧不佳，因此花了些功夫才做出來，以下分享我的產出步驟：

1. 惡補GoF Design Pattern及J2EE Core Design Pattern，不是叫你照抄，但了解別人怎麼做，自己也才能做的更好，不是嗎！（如果你已經很熟就跳過吧）。
2. 決定整體架構的大方向，例如前端介面使用Web MVC，商業邏輯放在SLSB，Persistence使用EJB配合…
3. 惡補UML圖的繪製規格，練習使用UML Case Tool （如果你已經很熟就跳過吧）。
4. 把需求從頭到尾看過至少二次以上，將有疑問的地方寫成Assumption。
5. 從Domain Model長出Class Diagram，並寫下各個在設計類別時所牽涉到的Design Decision，注意符合需求是第一原則。
6. 決定各層有那些元件，一樣寫下Design Decision，注意要和其它圖保持設計的一致性。
7. 根據元件畫出各Use Case 的Sequence Diagram，此時你會再發現一些需要Assumption的地方，或設計不合理的地方，寫下來，並且回頭修正設計。
8. 畫出Component Diagram，寫下Design Decision，注意要和其它圖保持設計的一致性。
9. 寫說明文件，記得此文件要包含之前所整理的Assumption、Design Decision和各個UML圖，如果有不容易了解的地方，盡量用圖形輔助。
10. Review再Review，切記符合需求及一致性(不要有自相茅盾的地方)。
11. 送件。