金山软件程序员  刘鑫

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的意义并不大。

盛大创新院霍炬：UML——一种体系和一种思想

UMLChina潘加宇：竞争优势和建模

(本文来自《程序员》杂志10年08期，更多精彩内容敬请关注08期杂志)

《程序员》8月刊最新上市：http://www.programmer.com.cn/3742/

《程序员》订阅：http://book.csdn.net/programmer/