2010年6月12日星期六

关于UML的个人见解——答周筠和霍炬两位老师

谢谢周老师和霍总的抬爱,我觉得很惭愧,
因为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的意义并不大。

没有评论: