盛大创新院霍炬:UML——一种体系和一种思想
2010-08-27 10:38
267 查看
盛大创新院程序员 霍炬
早年我也喜欢过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程序开发者手册》即将在博文视点出版
早年我也喜欢过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程序开发者手册》即将在博文视点出版
相关文章推荐
- 依赖注入是控制反转的一种实例,也叫反射,运行时从配置文件字符串来创建类,插件思想降低耦合度
- 对等互通 自由共享 P2P更多地是一种思想
- iOS-FMDB本地存储之一种封装思想
- Rabin-Karp-MATCHER字符串匹配算法; 一种效率还不错的匹配算法; 思想是关键.
- 一个软件里透露的一种思想
- 将 SOA 定义为一种体系结构风格
- 核心思想:想清楚自己创业的目的(如果你没有自信提供一种更好的产品或服务,那就别做了,比如IM 电商 搜索)
- 【初学笔记】利用反射、泛类思想操作对象的属性和方法的一种方案
- 从面向过程到面向对象再到UML来看待英语学习,思想才是王道
- CRM是一种流程设计思想
- POJ 1797 【一种叫做最大生成树的很有趣的贪心】【也可以用dij的变形思想~】
- Java是一种先进的软件编程思想
- 注册码实现思想的一种
- 一种基于FPGA有限状态机思想的RS485 C底层驱动
- 一种效率极高的ASP分页思想
- HDU 2058 The sum problem(一种神奇的求和思想)
- 酸酸菜创业之---核心思想体系
- 思想:java中,父类的方法中传入的形参的数据类型是泛型,子类的方法的形参想只要一种确定的数据类型,子类该如何做呢?
- 将 SOA 定义为一种体系结构风格
- MVC不是一种设计模式,而是一种设计思想