晚上跟老爸去遛弯，跟爸聊起工程。老爸是搞建筑工程的，属于现场指挥工人干活的工程师。
从跟老爸的谈话中可以看出，软件工程有以下几个特点：
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等等这些世界级的专家~