因为IT知识体系的大局观，我一直感觉不够。
UML在02-04年的时候，非常爱用。但是在后来到北大青鸟做教师，上了一遍UML课程下来，备课过程中，甚至是在批改学生作业的时候，才深感以前对很多基础的UML组成，根本就理解错了。也就是说那个时候所有的同事、客户都在乱用。我抛弃了UML之后，不但没觉得损失，还觉得写代码就写代码，直接、清晰了很多。在这样一个领悟后，我彻底戒除了IDE和UML。反而感觉工作能力有所提升。
对UML的立场，我也处于一个反复和深入的过程。一方面觉得像以前那样错用UML，真的是有害无益。但是经历很多同行企业，确实就是在这样误用。大家仅仅是处于对工具的生产力迷信，这其实是跟我早年盲目相信用VS或Delphi等RAD工具就一定比手写代码高效一样。特别是IT业涉及的生产领域非常广大，管理方式也越来越丰富。很多场合根本不依赖UML这样的图例工具，文本就足够整个团队进行沟通了。但是另一方面，看到一些企业也确实成功的使用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发烧友，从我五岁认识他起，他就热衷各种手工制作。有次他给我看一个欧洲论坛上的文章。一个德国朋友讲如何在自家车库里制作涡轮风扇发动机。燃烧室腔体形状如何，可以从那些日用品中找到替代材料，涡扇要有几片桨叶，要扭多大的角度，为什么这样，数学公式如何，三视图如何。都一清二楚。这位德国老兄并不是克虏伯或奔驰的工程师，更不是什么航空专家。他就是一个普通的老百姓，一个单纯的机械爱好者。做这样的DIY，不是单靠说我喜欢或者我手巧就可以达成的，它需要一种工程师的思维能力，一种可以把想法实现出来，一步步的变成现实的思维和实践训练。想到欧洲，特别是德国英国这样的老牌工业国家，遍地是这样的普通人。就让我产生一种复杂的感情。我们和他们之间的差距，不是一个问题两个问题的解决方法，而是更大的能力差距。当这种差距从一个人两个人扩大到国民这么大的一个团体，发达国家的竞争优势就体现出来了。
在软件开发的领域，这样的差距同样表现的非常明显。为什么人家的团队可以用的很好的各种开发模式和工具，包括敏捷、UML等，到我们这里来就一塌糊涂。这个并非我们不聪明，但是我们缺少真正的工程师的训练。
这些方面我见识少，说的比较混乱。再不打住，就不知道跑出十万八千里了。简单的说，UML，我承认他有用，但是应该在不增加负担的情况下有限使用。UML是一个中间过程，不是IT开发团队最终的产物，不应该因为它给团队带来负担。大家能读懂到什么程度，能用到什么程度，就到那个程度为止。因地制宜非常重要。不能削足适履。特别是对于我们身边常见的开发团队，和项目领域，如果不是复杂的，需要长期维护、需要大量的跟客户深度沟通的企业应用项目，UML的意义并不大。