盛大创新院程序员 霍炬
早年我也喜欢过UML,觉得是对复杂工程的解决之道。后来碰上越来越多的实际问题,发现UML并不能很好地解决。一方面,要能精确地用UML定义问题,需要长时间的训练。就好像用一门不熟练的语言说话,时常会导致误解,UML也一样。多年前我曾经在团队里推行过UML,结果发现有大量问题表述不清,最后还是要靠面对面地重新描述问题和讨论解决思路,沟通效率很低。在这方面,UML并没有能成为一种统一语言,甚至比自然语言更难以取得统一。另一方面,当年很多人和公司都迷信用UML直接生成代码来提高生产力。这似乎不是我一个人的误解,Rational曾经出过不少软件,不光建模,还要做代码转换,生成代码框架。这部分实际使用效果不够好,生成的代码机械、复杂,经常难以理解,并且因为是自动生成的,阅读修改都很困难。
最近这些年,我慢慢理解了软件开发模式的变化——从软件模式到互联网模式。这里有如下几层意思。
- 软件的简单化。即由一个功能极多的复杂软件,变成了功能很少,但难度很高、非常深入的系统。
- 开发速度加快。在互联网环境下,没有过去那种可以从容进行设计、建模、填代码的时间。从2000年开始的一系列开发思想,基本上都是在寻找快速开发的方法论,或是给这种方法论提供技术保障,比较有代表性的就是XP、重构、单元测试等,前者是方法论,后两者是技术保障工具。
- 开发工具轻型化。Python、Ruby等动态语言开始流行,界面开始转向用HTML+JS创造,大大降低了复杂度。而在大量项目中,界面部分占用了相当比例的代码,也容易产生大量Bug。基于浏览器的应用程序规范了用户形式,大大降低了开发难度和代码量,也解放了程序员的生产力,让界面构建变成非工程师也可以完成的工作。
- 开发人员逐渐由多次完成重复的任务,变成不断深入到一个任务中。过去,外包项目多;现在,产品项目多。后者的维护周期长得多,也不太重复,前者是高度重复和少量修改。
在这种快速迭代下,可以把任务拆分成小块,一个个快速进行。没有巨大的工程也就不需要UML那么复杂的东西了,在这种小块任务驱动的项目中,UML很可能比语言本身还复杂得多。
规模巨大的开源项目,也很少见到基于UML的成功经验,基本上用文档+图片+代码描述,就可以让思路很清晰。我个人更推崇这种方式。我始终把外包项目单独分出来研究,因为外包项目是高度重复、高度定制的劳动,开发周期长,修改成本极高,这种项目应该是适合UML的。
比起漫无目的的猜想和不规范的文档图表,UML确实更加工程化,但它不过是一种体系和一种思想,仅靠它来形成工程师思维还不够。我们从小的教育就没有特别培养过这一素质,靠成年进入职场后形成,就显得特别难。看看周围有多少人,碰上问题是喊出来,而不是去读文档?这种思维需要慢慢培养。互联网带来的开放交流环境,使大家对问题进行讨论交流的频率大大增加,带来的思维冲击远比从前更多和更密集,而且对一个问题形成基本共识有着10年前不可想象的速度。90后的年轻人,他们的学习和研究能力比10年前的我们已经有很大提高,相信他们会比当年的我们更容易具备工程师的思维。
(本文来自《程序员》杂志10年08期,更多精彩内容敬请关注08期杂志)
由霍炬等翻译的《Cocoa程序开发者手册》即将在博文视点出版