Tiny Program用"獨立小程式"增添新功能

為大專案增添新功能時, 務必使用Tiny Program技巧
建立一個全新的Project並且只是為了單一新功能配置好編譯與執行的環境

開發流程如下:
1. Text UML規劃
2. Unit Test
3. 為新功能建立Tiny Program(小程式)
4. 合併到大專案的CVS

使用Text UML進行Refactoring

打破類別相依 (依賴穩定不變的Interface比依賴時常修改的具體類別更好)
A->B (A引用到B)
to
A->I<=C, B (A引用Interface I, 而C與B實現I)

打破循環相依 (循環相依會造成動一髮牽全身的副作用, 一定要打破)
A->B->C->A
to
A->B->C->D
A->D

打破繼承關係 (委託關係比繼承關係鬆, 應該多用委託少用繼承)
A<=B
to
A<-B

A只用到一部分B, 想打破A,C之間的關係
A -> B -> C
to
A -> B1 <- B2 -> C

只有A的一部分用到B
A -> B
to
A1 <- A2 -> B

B只是需要部分繼承A(部分Method放空萎縮不用)
A <= B
to
A1 <= A2, B

B其實不需要繼承A,但是C需要繼承A與B的特性
A<=B<=C
to
A<=C=>B

Text UML的優點

UML圖形對分析類別相依性有著不可抹滅的貢獻, 舉例來說, 在Class Diagram當中, 即使是錯綜複雜的線條加上數十個類別, 我們仍可以順著箭頭所指的方向與密集程度, 瞬間了解某個類別是否嚴重相依於其他類別. 而Text UML也擁有許多UML圖形所無法達成的好處, 兩者可以相輔相成.

以下為Text UML的幾個優點:

採用直接閱讀文字就可輕易理解的格式

運用文字取代輕易打破相依關係

使用文字編輯器就能輕鬆編輯或重整設計理念

可使用文字方式將設計理念嵌入原始程式碼

可由CVS, Diff進行Text UML文字檔案的版本控制

30分鐘就能做出屬於自己的Text UML工具

由Sequence Diagram可全自動產生Class Diagram相依關係

由Sequence Diagram可全自動產生Class Diagram類別與其擁有的方法

可自動計算類別間的相依性是否由不穩定到穩定

不受程式語言的限制, 可運用在各種設計場合: Python, Java, C#, C++

Text UML展現文字的力量

如果你經常需要畫流程圖或者方塊圖, 一定有跟我一樣的體驗, 明明幾個箭頭就可以解決的東西, 偏偏要開出作圖工具來拉線, 實在有夠麻煩, 製圖工具的啟動 時間緩慢之外, 人類通常都有浪費時間在調整框框位置或大小的癖好 (天啊! 程式已經寫不完了... 別再調啦!), 如果可以用很簡單的文字來表現UML圖形, 開發者就能夠更專注在改良類別設計. 舉例之前我們先定義Text UML中兩種文字箭頭的意義:

=> 代表 繼承/實現 關係 (Inheritance, Generalization, Realization)

-> 代表 引用/使用/擁有/依賴 關係 (Association, Dependency)

為什麼每種文字箭頭都代表了多重意義? 因為簡單勝於一切, 若要精確的呈現類別關係, 使用精準的UML圖形會比Text UML佳, 我們使用Text UML就是貪圖簡單的力量:

MailClient->SqlStorage

以上Text UML說明了電子郵件客戶端類別MailClient使用資料庫類別SqlDatabase來儲存郵件, 一旦SqlStorage改變, 因為MailClient相依於SqlStorage所以可能必須跟著改變.

利用Text UML的簡易性, 我們可以在十秒內將上述相依性打破, 讓MailClient可以自由選擇將電子郵件儲存在檔案FileStorage或資料庫SqlStorage:

MailClient->IStorageService<=FileStorage, SqlStorage

上述Text UML是讓MailClient相依於Interface IStorageService, 再讓FileStorage與SqlStorage實現IStorageService當中宣告的方法, 這樣一來MailClient就可以任意選用檔案或資料庫的儲存方式, 這是典型Strategy Pattern的手法.

然而文字Text UML為我們帶來什麼樣的好處? 有個很明顯的優點是: 可以利用字串替換的方式打破相依性, 我們完全不需要管類別真正的意義, 就可以運用單純的字串替換達到更有彈性的設計. 假設我們有A, B兩個類別, 而A相依於B, 則在Text UML表示如下:

A->B

若想運用Strategy Pattern將類別A與B之間的相依性切開, 只需要將"I<=C,"字串插入原本B的前面如下:

A->I<=C,B

其中I相當於郵件範例中的IStorageService, 而C與B相當於上述郵件範例中的FileStorage與SqlStorage. 這麼簡單的字串取代就能完成Strategy Pattern的設計, 完全不用管你實際類別到底有什麼作用, 文字的力量表現無遺. 這種字串取代很容易可以利用程式自動化, 熟悉文字處理的開發者, 只要幾十分鐘就可以做出好用的Text UML工具, 輔助進行各種複雜的設計.

捨棄白板崇拜

很多程式設計大師與書籍都鼓勵程式設計師使用白板交換對Class Diagram的心得, 因為白板可以迅速擦掉修改, 加上大家站在白板面前熱烈討論的氣氛, 確實讓白板成為吸引人的工具, 但是我發現使用白板有幾個缺點:

1. 白板筆時常寫到沒有水 (奇怪的是明明沒水了大家還是不斷用力的塗)

2. 圖形很難Email給所有與會者 (真希望白板內建Outlook Express)

3. 白板筆很臭 (應該屬於有毒氣體)

4. 有些人用白板作畫, 明明就是超級簡單的方塊也會醜到無法理解

5. 白板沒有辦法列印出來放在電腦旁參考

我原本對白板充滿了幻想, 覺得這應該是很好用的東西 (沒辦法, 眾家大師推薦, 我又很喜歡趕流行, 你只要看看XP相關書籍就知道他們對白板的崇拜), 但真正運用在實際生活上面, 白板對程式設計師就是不太夠.

所以我極力推薦大家挑選任何一種順手的UML製圖工具 (例如免費的JUDE,或是Borland Together, Rational Rose都很好用) 加上19吋LCD大螢幕(現在已經比五年前便宜到超乎你想像), 就可以在辦公室或會議室進行討論, 有幾個優點很顯著:

1. 用滑鼠拉各種線條非常快速並且整齊, 不會因為同事美術不及格而打壞心情 (帥手, 我真的不是有意把你的事蹟供出來...)

2. Class Diagram可以任意調整Class位置, 迅速拖拉可騰出空間放新產生的Class (白板經常畫到沒有空間, 在邊邊角角越畫越小...)

3. 儲存為PNG格式很容易使用Email流通, 或插入Word文件

4. 使用列表機印出來放在桌邊隨時參考, 又可以用原子筆迅速塗改

5. UML工具很容易可以把細節隱藏起來, Class Diagram最重要的是分析類別之間的相依關係(Dependency), 所以單單有Class名稱與線條就夠用了, 把Method與Attribute隱藏起來, 才不會因為圖太複雜迷失方向

6. 若工具是使用Borland Together有額外的好處, 程式碼可以與UML即時同步

很多程式設計師把UML當成是"設計草稿"在使用, 這種觀念有其價值, 因為最終是Source Code主宰結果, 太認真想要畫出巨細靡遺的UML圖形, 便失去了利用圖形進行抽象設計的意義, UML圖形是要讓我們節省設計時間, 因為塗改UML圖形比改Source Code容易, 現實生活中的程式設計師是有時程壓力的, UML應該挑最重要並且容易混淆的地方特別畫清楚就好, 剩下的應該讓風格一致並且容易閱讀的Source Code自我說明.

只要兩種UML圖形

UML發展的精神, 是為了讓軟體開發者有共同的設計語言, 以便有效縮短大家溝通設計理念的時間, 現在幾乎各種物件導向程式語言 (Python, Java, C++, C#, Delphi...) 都有專屬UML工具可以使用, 而我們可以看到一些與設計相關的文獻如 Design Pattern, Refactoring, Agile Programming等領域, 作者們也都習慣使用簡煉的圖片指出設計關鍵, UML圖形已是軟體設計必要的基礎工具.

完整的UML規格龐大而複雜, 常導致許多初學者裹足不前, 不知從何著手將UML帶入日常的程式設計流程, 其實UML跟所有語言特性一樣, "敢講不怕錯" 就很容易可以上手.

撇開各種複雜的UML規格先不看, UML裡與程式設計關聯最緊密的兩種圖形為: Class Diagram與Sequence Diagram, 前者分析類別間的繼承關係與引用關係, 後者則清晰的將物件之間的互動順序呈現在眼前, "每個"程式設計師都應該精通這兩種圖形. 無論是將自己的設計架構文件化, 或為了與同事做Design Review / Code Review, 或想看懂設計相關文獻中的架構討論, 這兩種UML圖形都可在短時間內讓人抓住開發者的設計理念, 進而通過討論溝通而得到更好的改善建議.

捕捉不變的原則

無論是Python, Java, C++, C#, 這些程式設計語言都有共通的原則, 掌握這些原則, 可以應用在Mobile Phone Programming, Web Programming, Client/Server Programming. 身為程式設計師, 若要在瞬息萬變的資訊世界立足, 探索並捕捉這些不變的原則, 是累積我們個人價值的方式, 學會一個新的技術可以時髦一陣子, 但掌握了一個不變的原則卻可以用很久很久.