对UML的看法

无双

转自uml china
http://www.umlchina.com/best/g26/u1129231.htm#1129231
人不过小小程序员，对此所谓系分级的UML发表看法好像不恰当，不过看了坛子上这些现在或者未来的系分精英们就只有一个看法：自从令狐大侠用独孤九剑以无招胜有招后，一群从未练过武功的有为青年个个都找把长剑乱挥一气，全是号称师承独孤九剑，如今是招式已经过时，非要无招才行。于是对编程一窍不通的都敢叫嚣设计最重要，编程好像只要有两个手能敲键盘的都能干。对此不屑一顾。本人虽然不过是还在用招式的小门派的入门弟子而已，但对什么是令狐冲的独孤九剑，什么是乡野村夫的胡乱出招，却还能分辨一二。

我不否定设计的重要，但从经验得知，写不好程序的通常也不会是好的系分。当然，写程序是可以很简单，就象印度人，先找一个人写个功能原型，然后招一群程序员每人拷贝一下，再根据自己的承担的项目把原型更改一下，通常是各自的初始数据调整之类的简单处理，每个子项目一个拷贝，项目经理就是每天确认进度，如果有什么变化，比如某个公用函数的调用参数改变了，就通知下去，每人各自对应，的确程序员只要所谓的软件蓝领就足够了，当然，如果想用继承，模板等使变化能够影响最小，而且统一，那就是另一回事了。项目经理，系分在这种情况下的确不用懂什么面向对象。这里的系分精英个个够格。
先说被系分精英们奉为宝典的《设计模式》，的确是好书，但这些不懂编程的系分精英们有几个能看懂哪怕20%，如何分割类的设计，什么时候用接口，什么时候用具体类，什么时候用继承，什么时候用组合，能说出个为什么的道道吗，死记那些上下文场景有什么用，还有本模式2000,一个个去背吧。没有长期的面向对象的编程经验，就能称为面向对象的设计高手？笑话。新技术不断出现，也成为系分精英看不起程序员积累的原因，觉得淘汰太快，过时技术无用。比如说现在有个面向对象的项目要分析设计类结构，一个是系分精英，通过ROSE之类的工具学习了UML，开口用例，闭口角色。就是不怎么懂编程。一个是老而过时的程序员，比如说是COM时代的，够古老了吧。问题是过时的程序员知道COM强调的就是接口编程。出于对多继承的担心，所以微软用的是InnerClass的解决方案，而JAVA的INTERFACE就是C++的纯虚类，所以JAVA的INTERFACE可以多重继承，而类则不被允许。对简化COM编程引入的所谓智能指针类对应《设计模式》中的哪一个，也不用多说了。这样两个人分析的结果，设计的类层次哪个更符合面向对象的思想，更有实现的可能，需求变化时的对应最方便，但凡有编程实践经验的程序员都清楚。如果有人要相信闭门造车，我个人不反对，最多祈祷别让我碰上。如果这个例子偏重了实现，就用UML最得意的用户需求分析来看，是为了在用户和程序设计间沟通，比如用户说某某和某某可以同意支出某笔款项，于是就创建了审批角色，很好，接下来比如增加监查角色，可以想象，在抽象后，监查和审批在项目和角色间的关联，权限等有相似但略有区别的处理，处理结果多半是同意，否定，但应该还有一些各自特有的状态。那么在UML中，这两个角色是会有继承关系？还是用同一个类，依靠身份状态区别具体处理和结果状态？还是各自独立从最基本的PERSON继承，独立实现？还是从一个特有的审批监查虚基类继承？或者用一个处理项目角色关联的类对象组合来重用代码？没有最优答案，根据项目情况有不同的最优解。问题是这样一个只要会考虑如何把自己程序写的更好的程序员就会想到的问题，会被多少缺乏编程经验，闭门造车的系分精英所考虑到？至于那些用例，事务的抽象在他们手中又能有多少可靠度？除了文档，真的带来重用性提高，代码质量提高，开发时间缩短，修改难度降低等等的改善吗？

如果不是在类设计上有太多的不定因素，面向对象设计就不会被人称为艺术。就像我不相信会用PHOTOSHOP就能成为油画大师，能将设计工具用到熟练固然不错，但毕竟还要有自己的东西。对于优秀的系分来说，UML帮助他们统一了说法，沟通更加容易，不会在交流时各自解释了自己的说法后才发现其实是同样的方案，只是给了不同的名字造成了误会。前提是，他们已经精通了面向对象。如果彼此清楚对方的思路，用不用UML并无大碍，只是交流的需要。工具不能代替人的思考。假设等到那一天，只要输入条件，工具就能自动给出最好的设计解，不用自己动脑，那也就是系分蓝领时代的来临。

我相信，UML和设计模式都是很有用的，问题只是在谁手上用，清楚的人如虎添翼，不懂的人只是狐假虎威而已，遗憾的是，在这个坛子上可能是我看的不多，真正清楚的人可以说是屈指可数。不少人还严格按照规范要求进行理想化设计，不要紧，多半还是学生，缺乏实践经验的缘故，接触几个项目后，明白了需求变化不可避免，理想和实际需要平衡也就可以了。另一种是想进入IT，但又听说已经是软件蓝领的时代，为了更好的出路，决定成为更有前途的系分。这对项目就有些可怕了。不过最可怕的是最后一种，有过两三年编程经验，可能还的确是C++，JAVA之类的，不过一直就在集成界面拖拖控件，双击追加事件处理，离开了VC，JBUILD就连程序源文件都看不来了，于是现身说法，程序员没有价值，程序总能动起来的，设计才是最重要的，口中不离最新名词，随时更新工具，这种人在设计上会有多大成就不知道，但那种一二千行的巨大函数多半是在这种人手下指挥出来的。因为第二种人缺乏经验，总还心虚，而这种人已经认为自己代表了编程最高水准了，这才是可怕之处。的确，在国内，程序员缺乏前途，只有往系分，管理转行，是事实。但真正精通面向对象设计的多半在自己的实践积累了相当多的经验，不可能轻视程序员。当然，他们对能写程序，会写程序，会写好程序的不同级别还是分得很清楚的。
面向对象设计，既然是一种艺术，就会有天才，肯定有人能不经过编程就熟练掌握这一技巧，不过如果有2万个天才，恐怕天才的定义得做修正了。比较一下，其他艺术行业出过多少个天才，再算一算，自己会不会是其中之一。如果没有把握的话，还是先好好学学编程吧。先问问自己，编程时有没有经常想为什么，有没有更好的对应方案，由于工期的问题，这次不能修改了，下一个项目时能不能体现这次的心得。如果用C++，是不是认为指针的使用比类继承，函数重载更头疼，是不是见到JAVA时，对类库的FACTORY，对象组合等不觉得奇怪，无难度就能掌握。看《设计模式》能直接一遍看懂，还是一遍一遍看，每次有点豁然开朗，原来如此的感觉。还是一有不明白的地方就到处找人问为什么。主动更新工具（不是项目要求）时是由于前一个版本有不如意的地方，想看新版本有没有解决，还是为了保持随时用最新的工具。自己得意的程序对于一般人来说是从主程序开始就结构清楚，一步步清晰明了还是类之间的关系跳来跳去，无从下手。如果这些答案都能令人满意的话，恭喜，离会写程序的级别已经不远了，请继续努力。
用工具还是为工具所用，是个大问题。能不能区分什么是目标，什么只是手段，则是更大的问题。
不说MS了，IBM，ORACLE，SUN等公司的软件开发分别相当于CMM多少的资格认证？自由软件的旗帜LINUX的开发又相当于多少？嘿嘿，最有趣的是还看到有人鼓吹质量控制人员（测试员？）是为了给程序员服务，而不是挑刺，我就搞不明白，测试员不检查程序员的编程错误，难道还是整理文档，告诉客户因为我们的文档齐全，所以如果有问题的话，就和我们无关吗。反正也是中国国情。一个一个资格去顺利通过吧。果然是优秀的项目管理。
有兄弟认为UMLCHINA误导了新一代IT人，也有人认为UMLCHINA只是提供了一个平台，没有强迫别人接受。我以为，为了宣传软件工程的概念（的确应该），UMLCHINA有意无意的神话了软件工程。问题是对于有经验的人员，知道什么能给自己带来进步，什么只是理论而已，而新一代IT人缺乏经验，以至于不能分别。如果真要在国内推广软件工程，UMLCHINA应该进行一些深度讨论，这样才能吸引真正有所思考的系分。像现在这种环境，虽然好意，但有几个potian会过来教授这些基本概念？平衡取舍的均衡考虑在现在这种一用就灵的宣传下会有用吗。那就不会有人月神话了。

以此文声援那些在此质疑UML的程序员兄弟，UML有用，但绝不是非用不可，更不是万能。

无双

我觉得UML只是一个交流工具,而不是解决软件编程问题的万灵药

gadfly

UML总的来说是一种建模和设计工具。实际上与编码本身并无直接的关系。
虽然UML的外挂工具支持设计到代码的mapping.

在分析和设计中，有规范，有统一的方法和术语，总是比各自为战要好。

无双

如果是小软件的话
那么使用语言或是其它交流方式应该会更高效
而严格按照UML画流程图、写CASE文档的话
会把很多时间和精力花费在上面

如果是大软件的话
那么使用UML交流是有必要的

一无所有

所有的建模工具都是针对大、中型软件的。
  对比较成熟的软件开发公司而言，
  可能大家都已经开始注意到了，
  现在对分析所花的时间（形成相应文档）越来越多。
  一个标准的软件生命周期，编码的时间应该低于35％。
  在这一点上相信大家都有了一个相同的认识。

无双

同意楼上的
所以在那些公司做程序员的话觉得效率特别低

不过我觉得那么多文档并不一定有人看
文档多了后想一篇一篇看很累的

除了你是写文档的人或是对这项目已有了一定了解并且有耐心


还有就是需求的改变很快
文档的更新速度比不上需求或是代码的改变速度

如果更新需求和代码结构时必须更新文档的话
那么效率更低
而且由于各部分关联性

你必须更新所有相关文档

gadfly

所以就有XP这种新观点出现了: 以coding为核心，迭代开发.



如果能组织不同的开发思想的学习和讨论，相信对大家的能力很有提高

无双

确实是这样
程序员最主要的不是编码
而是它的设计思想

一无所有

原帖由 "无双" 发表：
确实是这样
程序员最主要的不是编码
而是它的设计思想

  这个观点也可以这们讲，
  但在一些公司，现在已经将设计和编码分开了。
  可能一部分程序员专门做设计，一些做编码，一些做测试。
  我以前写的“微软的三架马车”，不是是否已经看过，
  但我个人觉得那也有可能会是中国软件管理的一条可行路径。
  设计和编码分开，在我看来是一个公司管理水平高低体现的一个重要标志。

tech_cannon

不能同意UML可有可无的观点。即使是个小项目，UML也是在分析时的一个重要工具。问题不在UML, 而在于分析本身。你不能否认分析的重要，而UML只是分析时所用的语言而已。况且这种语言已经被大家接受。你当然可以用自己的一套，但这是不是舍近求远？

现在我也很看不惯有些浮躁的说话。好像学UML就是学rose， 可笑。