很久以來我一直不太清楚工程師應該怎樣定義和定位，所謂的工程師應該是有怎樣的特質……
朋友有次讓我看歐洲論壇上的文章，是一個德國人講如何在自家車庫裏製作渦輪風扇發動機。燃燒室腔體形狀如何、可以從哪些日用品中找到替代材料、渦扇要有幾片槳葉、要扭多大的角度、數學公式如何等，都描繪得一清二楚。這位德國老兄並不是克虜伯或奔馳的工程師，更不是航空專家，就是一個普通老百姓，一個單純的機械愛好者。做這樣的DIY，不是說喜歡或者手巧就可以達成的，它需要一種工程師的思維能力，一種可以把想法實現出來、一步步變成現實的思維和實踐訓練。想到歐洲，特別是德國、英國這樣的老牌工業國家，遍地是這樣的普通人，就讓我產生一種複雜的感情。我們和他們之間的差距，不是能不能解決一兩個問題的差距，而是更系統的能力差距。
2002～2004年間，我非常愛用UML。但後來到北大青鳥執教，在準備UML課程過程中，甚至是在批改學生作業時，才深感以前對很多基礎的UML組成，根本就理解錯了。我拋棄了UML之後，不但沒覺得有什麼損失，反而覺得寫代碼就寫代碼，直接、清晰了很多。有了這樣一個領悟後，我徹底戒除了IDE和UML，反而感覺工作能力有所提升。
對UML的立場，我也處於一個反覆和深入的過程。一方面覺得像以前那樣錯用UML，真的是有害無益。大家僅僅是出於對工具的生產力迷信，這跟我早年盲目相信用VS或Delphi等RAD工具就一定比手寫代碼高效一樣。IT業涉及的生產領域非常廣大，管理方式也越來越豐富。很多場合根本不依賴UML這樣的圖例工具，文本就足夠整個團隊進行溝通了。但另一方面，看到一些企業也確實成功地使用UML進行工作。難道這樣的團隊是在假裝一種獲得滿足的狀態？似乎不可能。因此，我很困惑。
UML作爲軟件工程的一個發展成果，肯定有它的意義，特別是大型團隊中的內外溝通。大型企業應用項目很難靠開發人員的個人才華來突破，而是要靠團隊去完成客觀的工作量。如果整個團隊有一個大家都能理解的、圖形化的、直觀的溝通方式，確實是有積極作用。儘管單純的圖形和線段的作用還是有限，但是圍繞UML，有一套基於文本的、清晰的定義方式和描述標準。只是瞭解這套標準，同樣需要付出學習的代價。更糟糕的是，往往UML在團隊中的使用價值，取決於平均甚至最差的那個使用者，而不是最好的那個。
我教過的ACCP的學生，幾個班裏能正確理解Use Case的不超過10人，能很漂亮地運用Use Case的，不超過3個。我用過各種UML工具，沒有一個讓我覺得可以很方便地幫助我快速畫出我的想法。所有的圖例工具都讓我有一種跟不上思路的感覺。類似類圖和代碼之間互相轉換的功能，更是讓我覺得畫蛇添足，華而不實。
要發揮UML的作用，首先應該推廣學習最容易、對工作最有價值的部分，如用例圖、泳道圖等。不應該追求儘可能多地使用UML，只在UML比文本好的時候才用它。儘可能在紙或白板上畫圖，哪怕畫完再拍照或掃描。不必推崇完備的UML工具，業界一些講軟件工程的老師總是很推崇從ROSE之類的工具中，用UML生成代碼，對這種技術的實用價值我持懷疑態度。在我所經歷的所有工作場景中，所用到的UML知識都只是非常小的一個子集。UML的最大價值應該是幫助人理解問題，把文本不易描述的問題直觀化，讓技術能力、知識背景不同的人形成共識，而不是幫助機器去構建。或許在J2EE風格鼎盛的年代，這樣的能力很好很強大。但在動態語言面前，無論使用怎樣的開發工具，Java/C#這樣的靜態、強OO、編譯語言與之相差一兩個數量級的開發效率，總是很難得到彌補。
朋友有次讓我看歐洲論壇上的文章，是一個德國人講如何在自家車庫裏製作渦輪風扇發動機。燃燒室腔體形狀如何、可以從哪些日用品中找到替代材料、渦扇要有幾片槳葉、要扭多大的角度、數學公式如何等，都描繪得一清二楚。這位德國老兄並不是克虜伯或奔馳的工程師，更不是航空專家，就是一個普通老百姓，一個單純的機械愛好者。做這樣的DIY，不是說喜歡或者手巧就可以達成的，它需要一種工程師的思維能力，一種可以把想法實現出來、一步步變成現實的思維和實踐訓練。想到歐洲，特別是德國、英國這樣的老牌工業國家，遍地是這樣的普通人，就讓我產生一種複雜的感情。我們和他們之間的差距，不是能不能解決一兩個問題的差距，而是更系統的能力差距。當這種差距擴大到整個民族，發達國家的競爭優勢就體現出來了。
在軟件開發領域，這樣的差距同樣表現得非常明顯。爲什麼人家的團隊用得很好的各種開發模式和工具，包括敏捷、UML等，到我們這裏來就一塌糊塗。也許並非我們不聰明，而是我們長期缺少真正的工程師思維的訓練。
簡單地說，我承認UML有用，但應該在不增加負擔的情況下有限使用。UML是一箇中間過程，不是最終產物，不應該讓它給團隊帶來負擔。大家能讀懂到什麼程度，能用到什麼程度，就到那個程度爲止。因地制宜非常重要，不能削足適履。如果不是複雜的、需要長期維護的、需要大量跟客戶深度溝通的企業應用項目，UML的意義並不大。
金山軟件程序員 劉鑫
