零雨其蒙's Blog

做优秀的程序员
随笔 - 59, 文章 - 13, 评论 - 58, 引用 - 0
数据加载中……

软件工程与建筑工程

        晚上跟老爸去遛弯,跟爸聊起工程。老爸是搞建筑工程的,属于现场指挥工人干活的工程师。
        从跟老爸的谈话中可以看出,软件工程有以下几个特点:
        1、模式比较固定,需求很明确。比如说盖饭店就是饭店,盖写字楼就是写字楼。说一层有几个房间就有几个,说几个大的几个小的,几个厕所,都规定好的。楼梯什么样,也都有现成的模式。
        2、分工明确。领导们开会决定需求,设计院负责设计,然后拿到现场由现场的工程师将图纸放大,而且完全遵照图纸,建筑工人来最后实现(砌砖、搭梁什么的)。
        而我想软件工程可不是这样啊!需求总是变来变去,有时软件都编完了,客户才明白自己想要什么。这是个软件工程永远也解决不了的问题。从需求到设计再到代码,中间的鸿沟相当大,如果说能按照设计者的设计直接翻译成代码(就像建筑工人一样,不需要思考),那设计量相当恐怖了。
        正是某些人直接将软件工程和建筑工程画了等号,才出现了瀑布模型这样的错误方法和软件蓝领、代码工人之类的说法。觉得程序员和民工一样。在20世纪80年代美国已经意识到这个问题,国防部、IBM都废弃了瀑布方法,而改用了IID,而在国内,很多项目还在继续遵从着瀑布模型,而且教学中依然在强调瀑布模型,即使强调了迭代开发之类的,要么就是说一套做一套;要么就是在迭代方法上附加瀑布模型的对迭代的错误理解(看过一本书上说每个迭代就是一个小瀑布,其实这是对瀑布模型理解的错误,分析、设计、开发、测试、实施并不是瀑布模型的专利啊)。而且我还得知,盖一栋8层家属楼,才需要1000多万,而我们现在正在做的这个项目光软件开发费用竟然高达8000万,看来,从这点来看,建筑工程是不能跟我们相比的。
         正如Craig Larman在《UML & 模式应用》 中说软件是高创造性活动,具有高风险的特点。作为对风险的控制,显然UP/XP会起到积极的作用。从这点上来讲,建筑工程是不能跟软件工程相比的。
         在软件活动中,程序员应该受到尊重,而且程序员是构造软件的核心。伟大的设计师必是优秀的程序员(借用Fowler在《重构》中对自己的评价:觉得自己只是个有着好习惯的优秀程序员),很难想象,一个不会编程的设计师怎么能理解设计模式(反正我因为看不太懂C++的代码,觉得理解设计模式相当困难,很多模式是因为在编写Java程序时遇到过同样的问题(所谓的context),自己想到一些方案,发现有些模式正好可以更好的解决我的设计难题,觉得比较受启发),同样想成为一个好的架构师,则更应该如此了。还有一些人毕业之后想去做顾问,我很难想象读了一些网上的文章,就可以去给使用Spring的团队做顾问了?(当然如果你有深厚的EE功底,理解并使用Spring也并非难事)总之,实践出真知。而所谓实践,大抵对于软件构造活动就是编程,软件活动的最终产物不是报告,而是可以运行的软件,偏离了这点,就是本末倒置了。
        最近在看《UML & 模式应用》,觉得大受启发,刚看完领域模型这一章,但是这已经解决了我先前的很多疑问了。比如到底什么是领域模型,怎么写用例(原来以为用例的根本是画用例图,结果大师告诉我,用例的本质竟然是文本,具体的我会单独撰文),先前的很多自己摸索的实践,在看书的过程中,不断提炼,联系实践,感觉真的很不错~

         还记得有人这样评价Robert Martin:Robert Martin是一位具有三十多年开发经验的老程序员,尽管今天已经是世界顶级的专家,但他对于“一切必须落实到代码”的思想,仍然抱着无比坚定的信念。

         希望我自己能成为像Robert Martin,Martin Fowler,Rod Johnson,Craig Larman,Kent Beck等等这些世界级的专家~

posted on 2007-02-01 20:25 零雨其蒙 阅读(696) 评论(0)  编辑  收藏 所属分类: 程序生活


只有注册用户登录后才能发表评论。


网站导航: