Kingfish和蜗牛的家

软件工程

对于软件工程我已经思考了很长时间（估计有几年时间了），也在dev2dev的论坛上与很多人分享了一些心得。主要是今天受了大半天的刺激（上软件工程的课），所以把想说的话写到这里。

很多东西到了中国就有些变味道，就比如软件工程吧——拿来的，我们是真正用来解决“危机”吗？我想主要是为了以下两点吧……

1. 能够从容面对我们的客户
• 迁就：合同的签订需要在项目启动之前一次性签订，感觉是用软件工程中的瀑布模型最合适不过了。
• 限制：需求的确认，我只需要对合同订立时的需求规格说明说负责就可以了。变化是肯定的，这样不就可以找一个冠冕堂皇的理由追加钞票了嘛。（题外链接：时间与提供的价值）
2. 掩盖我们内心对于软件的恐惧

• 对传统工程学简单性的依赖以及针对软件方法论本身理论的匮乏
• 一般而言，越简单越好。瀑布（原型）吧。我好控制啊，要不怎么控制？
• 说实话，对于软件方法论我没有搞得很明白。但是项目就要开始啦，就按原来的上吧。我要是用别的方法我搞砸了怎么办？按这个走没人说闲话。
• 符合我们头脑中已有的模式
• 例子只有传统工程学的例子，现在想起来 对于装修来说 也只有需求部分能够体现软件项目的特点。
• “软件方法”这个词在一般人的脑子中还是很空白，说白了：没有概念。只能拿现实世界中的例子，找啊找啊就找到工程上了。
• 能够自圆其说
• 国际理论
• 印度软件产业的成功
• 合适大型项目（一般而言，大的好使，小的能不好使吗？再说小型项目还需要方法论吗？）
• 一种较中庸的方法来面对日新月异的技术
• 用采用现代程序设计技术一言而蔽之，咱们的方法论能够脱离技术，也就是永恒正确的。
• “人力”神化
• 用工程学的方法，拿工程学的工具，走工程学的过程。这样的话人只是流程中的一个可以随意替换的点。领导最希望看到这种情况了，太完美了啊！

但感觉到身边采用软件工程的项目，有点“工程危机”了，系统变得僵硬、易坏、不能响应变化、维护困难、质量低下、工期延期、文档混乱。不要说没有很好地实施软件工程这种话，这个东西是不是本身就有毛病呢？（最近总喜欢用问号）

但是我始终相信，软件方法论的目的是为了更好的软件交付和更好的软件维护。而不是文档交付和商务周旋，我们浪费的时间太多了，我们已经没有多少时间能再让我们浪费了。

we have more compromises,but less time.我们妥协更多，时间更少。
目标只有一个，但绝对不是让自己有口饭吃。