2007年2月12日 星期一

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比直接實作出來還高。



種種原因,使得專案團隊必須在程式碼交附後才開始趕文件,這些文件也許鉅細糜遺,但在我看來,卻對了解系統沒有幫助,如果客戶想將系統交接給新成員,他拿到厚厚一疊設計文件時,應該會覺得不如直接看程式碼比較容易了解。



這個問題,就和很多人喜歡用書的”厚度”來決定書的內涵一樣,厚的書賣的貴是理所當然,頁數不多的書賣貴了,是暴利。



其實,能將許多內容濃縮成幾張圖、幾句話,才是真正價值所在,所以我開始對專案設計文件的產出方式改變。不過,許多客戶還是對於能拿到”厚重的設計文件”這件事很重視,但我還是會嘗試的。

沒有留言: