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

盛大创新院程序员  霍炬

 

早年我也喜欢过UML，觉得是对复杂工程的解决之道。后来碰上越来越多的实际问题，发现UML并不能很好地解决。一方面，要能精确地用UML定义问题，需要长时间的训练。就好像用一门不熟练的语言说话，时常会导致误解，UML也一样。多年前我曾经在团队里推行过UML，结果发现有大量问题表述不清，最后还是要靠面对面地重新描述问题和讨论解决思路，沟通效率很低。在这方面，UML并没有能成为一种统一语言，甚至比自然语言更难以取得统一。另一方面，当年很多人和公司都迷信用UML直接生成代码来提高生产力。这似乎不是我一个人的误解，Rational曾经出过不少软件，不光建模，还要做代码转换，生成代码框架。这部分实际使用效果不够好，生成的代码机械、复杂，经常难以理解，并且因为是自动生成的，阅读修改都很困难。

最近这些年，我慢慢理解了软件开发模式的变化——从软件模式到互联网模式。这里有如下几层意思。

• 软件的简单化。即由一个功能极多的复杂软件，变成了功能很少，但难度很高、非常深入的系统。
• 开发速度加快。在互联网环境下，没有过去那种可以从容进行设计、建模、填代码的时间。从2000年开始的一系列开发思想，基本上都是在寻找快速开发的方法论，或是给这种方法论提供技术保障，比较有代表性的就是XP、重构、单元测试等，前者是方法论，后两者是技术保障工具。
• 开发工具轻型化。Python、Ruby等动态语言开始流行，界面开始转向用HTML+JS创造，大大降低了复杂度。而在大量项目中，界面部分占用了相当比例的代码，也容易产生大量Bug。基于浏览器的应用程序规范了用户形式，大大降低了开发难度和代码量，也解放了程序员的生产力，让界面构建变成非工程师也可以完成的工作。
• 开发人员逐渐由多次完成重复的任务，变成不断深入到一个任务中。过去，外包项目多；现在，产品项目多。后者的维护周期长得多，也不太重复，前者是高度重复和少量修改。

在这种快速迭代下，可以把任务拆分成小块，一个个快速进行。没有巨大的工程也就不需要UML那么复杂的东西了，在这种小块任务驱动的项目中，UML很可能比语言本身还复杂得多。

规模巨大的开源项目，也很少见到基于UML的成功经验，基本上用文档+图片+代码描述，就可以让思路很清晰。我个人更推崇这种方式。我始终把外包项目单独分出来研究，因为外包项目是高度重复、高度定制的劳动，开发周期长，修改成本极高，这种项目应该是适合UML的。

比起漫无目的的猜想和不规范的文档图表，UML确实更加工程化，但它不过是一种体系和一种思想，仅靠它来形成工程师思维还不够。我们从小的教育就没有特别培养过这一素质，靠成年进入职场后形成，就显得特别难。看看周围有多少人，碰上问题是喊出来，而不是去读文档？这种思维需要慢慢培养。互联网带来的开放交流环境，使大家对问题进行讨论交流的频率大大增加，带来的思维冲击远比从前更多和更密集，而且对一个问题形成基本共识有着10年前不可想象的速度。90后的年轻人，他们的学习和研究能力比10年前的我们已经有很大提高，相信他们会比当年的我们更容易具备工程师的思维。

金山软件刘鑫：有限使用UML

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

 

 

 

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

由霍炬等翻译的《Cocoa程序开发者手册》即将在博文视点出版