UML or not? Less or More?
前幾年UML很流行，就跟很多新玩意一樣，眾人稱道，紛紛採用。
UML很好，但你不需要只擁有它，只要是可以讓文件更簡單易懂的表達方式，都可以出現在設計文件中。
過去幾年我經歷過幾個專案，客戶感受到UML的Power，相當喜愛，因此我也感受到他們的狂熱，這些專案被要求要以”OOAD”的方式開發，要享有”OOAD的好處”，他們需要一份包羅萬象的設計文件，內容必須包含UML的各種圖。
我被要求必須提供符合UML規範的圖形，而且”顆粒度愈細愈好”，所以我的Class Diagram包含了整個系統的所有類別，可能有二、三百個吧！而Sequence Diagram則被要求必須包含所有該專案產出的”每行”程式碼，畢竟對客戶而言，東西愈多愈好，一樣的價錢，能拿到愈多文件就是賺愈多。
那些年，我總是在專案最後收尾階段時才拼命補畫各種圖，也許你會講”設計文件後補”，不是正規的方法，但我有我的難處：
1. 顆粒度太細的設計圖，溝通的功能不足，不如直接看程式碼。
2. 專案開發過程中，只有高階架構有可能維持一致，實作細節則是不斷變更的，變更原因可能是Bug修正、效能調效或需求變更，如果同時要改Sequence Diagram，那程式員會殺了我吧…
3. 畫出顆粒度很細的UML圖形，其Effort比直接實作出來還高。
種種原因，使得專案團隊必須在程式碼交附後才開始趕文件，這些文件也許鉅細糜遺，但在我看來，卻對了解系統沒有幫助，如果客戶想將系統交接給新成員，他拿到厚厚一疊設計文件時，應該會覺得不如直接看程式碼比較容易了解。
這個問題，就和很多人喜歡用書的”厚度”來決定書的內涵一樣，厚的書賣的貴是理所當然，頁數不多的書賣貴了，是暴利。
其實，能將許多內容濃縮成幾張圖、幾句話，才是真正價值所在，所以我開始對專案設計文件的產出方式改變。不過，許多客戶還是對於能拿到”厚重的設計文件”這件事很重視，但我還是會嘗試的。
