【導讀】本文作者在現有UML現狀的基礎上，和我們探討了目前的UML熱潮是怎么產生的？為什么會存在形式主義？以及RUP之類的工具究竟存在哪些問題。作者根據自己的經驗，給出了解決的建議。
UML在國內不少地方獲得了應用。這應該說是個好事，然而背后我們也看到，這種應用大多屬于不夠冷靜的炒作和跟風，UML在很多時候已經變成了一種形式主義的東西。實際上，UML本身所倡導的主旨是很好的，它保證了程序員之間的交流語言，RUP之類的工具也保證了軟件開發過程的規范性，嚴格保證了先設計后開發，設計階段有翔實的規范化的文檔等。接下來，我們要看看目前的UML熱潮是怎么產生的？為什么會存在形式主義？以及RUP之類的工具究竟存在哪些問題。
第一是目前幾乎所有的UML工具都非常不好用，不美觀、不直觀、更不方便，在項目中進行同步維護也很困難。很多項目中用UML基本上可歸于形式主義的范疇。事實上，UML本身是一種規范，而規范本身的目的在于更好的交流溝通和更快更好的設計質量，事實上現在UML的發展已經背離了這些更基本的宗旨。我崇尚簡單就是美，最傳統的流程圖每個人都能看懂（甚至不是程序員也可以），現在的UML呢？太多不夠體貼和人性化的東西了，過于抽象化和公式化。我想未來會有新的更輕量級的類似的東西取代落后、冗腫和封閉的UML。我個人崇尚簡單就是美……
第二個問題是目前程序員的普遍素質不夠。UML本身基本是于面向對象的軟件設計思想的，沒有足夠優良的OO設計能力，很難有真正需要UML類別設計工具去表達自己設計意圖的必要。這個觀點不算夸張，其實有的人OO理論很強，但真正在實踐中往往過度設計，或者設計本身極度不平衡，把項目開發改成了科研實驗和上機實驗。另外更多的一些人對自己的動手能力很信任，往往忽視設計環節，基本上項目的設計一直處于反復和動蕩中。這些程序員不給他們一段時間學習和實踐，是很難成為成熟的設計師的，在基本成熟之前，UML對他們將是一個形式化的東西，不會有很強的意義。Andrei曾經說程序員要到35歲才會成熟，而代碼員可能20多歲就可以了。這句話里大概也有“設計本身是個很需要經驗的工作”的意思。
第三個問題是少數社會層面的宣傳誤導。印度海歸派、外企員工、IT譯書作者和出版社、職業培訓機構等處于各自的經驗、目的和原因，大部分人完全背離現實的盲目鼓吹UML，甚至幾乎片面的認為UML就是軟件工程。外企應用UML其實也并不很成功，不過他們有成熟的培訓體系，所以一定程度的彌補了UML過于晦澀的弱點，作為已經掌握他們的外企員工有一些可能會比較片面的歡迎UML。而印度海歸派的目的就不用多說了，至于培訓和譯書的人很多都學者成分大于實戰成分，他們需要鼓吹UML，不過早晚他們會發現更好的東西而放棄對UML的鼓吹。事實上，現在已經有人開始考慮這樣作了。
第四個問題是少數程序員非常依賴自動代碼框架生成，而這其實根本不是UML的關鍵問題。他們為了使用某些工具生成的一點也不符合中國人閱讀習慣的代碼，情愿放棄其他的一切。對他們來說UML只是一個代碼生成工具而已，所以他們作的UML大都沒有多大價值，比較形式化。
第五個問題是項目資源的問題。國內大多數項目實際可支配的資源非常有限，如果給其他外國公司的開發人員看無論開發周期還是資金人力都基本是荒唐可笑的。UML實際上應該貫穿始終，而不是只在最初的設計階段，也應該貫穿整個項目組，包括設計、管理、開發、測試所有的人都應該應用它。
我想一般的公司如果沒有極大的把握不用太迷信UML/RUP，其實某些基于輕量級項目并不需要RUP或UML。現在正打算學習UML的同行們，也盡可以先放下它，將來一定會有更優秀的技術取代它，現在不如多花點時間學習和實踐一下OO設計等更基礎的東西。其實僅僅熟悉一下工具軟件和交流范式，將來對你來說只是幾天到個把月的事情，不用那么在意。而對于那些現在已經決定了實戰UML的項目，要想獲得成功，我的建議如下：
第一，項目周期至少延長通常計劃的50%至100%。你必須跟所有人解釋說，只有這樣才能讓UML本身有意義，才能切實提高項目的設計質量。
第二，在項目開始集中提供一段時間的UML開發培訓。貫穿項目始終，都要經常進行全方位面向對象設計思想的交流（當然是結合UML的），力圖通過交流提高設計質量。
第三，頂住客戶和公司領導方面的壓力，堅持把盡可能多的設計問題在最初的設計階段解決，而不要被迫匆匆完成形式主義的UML設計，然后把設計丟在一邊，開始編碼。
第四，妥善處理部分“精英”程序員的抵觸情緒。能疏導就疏導，不能疏導應考慮壓服甚至將他徹底排除在項目組外。UML量級的團隊開發并不鼓勵個人英雄主義，不下狠心將根本沒機會推進下去。
第五，對項目的期望不要太高。無論是面對急于驗收向上級邀功的政府客戶，還是公司里不懂技術只懂蠻干的領導，都要保持低調，把它當做一個并不見得立竿見影的實驗……
好了，就寫這么多，祝大家好運。