在软件开发时，经常会出现质量下降的时候，从我自己做过的项目来看，主要的原因是开发的太“快”了。这里的快不是真正的快，而是有问题的快。

　　这里可能有的人说了，我们要的是快速的反馈，我们要的是“敏捷”。这里我想说，如果只是给客户演示产品最终是什么样的（这只能是Demo），那么这种快，也许可以接受，但是我们很多时候做的都不是Demo产品吧。

　　我说过这个问题，但有人反驳说：“我们不需要过度设计”。然而，我的经验是我们设计不足的情况比过度设计要常见的多，为何设计不足？大概有一下几个原因：

　　● 程序员“说”时间不够。

　　● 程序员设计方面的知识欠缺。

　　● 程序员被要求快速的完成功能。

　　● 程序员受到太多干扰。

　　上面有两种情况都是太快了（怎么解决上面的问题，这里就暂不提了），举个Web开发的例子（以下的三层开发，都是指单个功能的，而不是指整个层全部完成才进入下一层，因为常常是增量开发）：

　　● 代码全写到Code Behind里，然后就迅速的写界面，然后就不停的运行页面，发现问题，修改，最后完成功能。

　　● 典型的三层结构，写界面，写后台代码，写逻辑层，写数据层。由上到下。运行界面调试，修改。

　　● 三层结构，定义Model层，定义数据操作层，定义业务逻辑层，写界面。运行界面调试，修改。

　　● 三层结构，从底层到上层，每一层做充分的测试后再进入下一层，最后写界面。

　　上面的4种方式，第一种最先看到界面（但常常最后完成，因为代码有问题，调试修改很麻烦，应为代码多时很难定位错误），第二种次之，第四种最后。第一个迭代（或者说项目的早期）第一种方法最先完成，第四种方法最后完成。所以有不少人人习惯了前三种方式，然后被一种“高效率”的假象所欺骗，这往往会瞒过管理人员甚至是客户。但最终回过头来看，整个过程是“快、慢、更慢、项目停止”。我不是危言耸听，经常会出现这样：

　　（下面的四个迭代只是说明顺序关系）

　　● 第一个迭代递交功能了，但质量较差。

　　● 第二个迭代也递交了，但之前差的代码让我们慢了下来。

　　● 第三个迭代想递交时，发现差的代码越来越多，开发效率大大降低，客户开始受不了了。通过加班或者延迟提交，终于客户可以看到功能了。

　　● 第四个迭代刚准备开始时，发现客户反馈了大量的问题，当想修改代码时，发现代码已经一团乱麻，我们自己这个时候会说当时最么会这么些呢？由于什么什么原因太难改了，我们需要推倒重写。Oh My God，客户这个时候会说，见上帝吧，偶尔会有客户客气点说“下次再合作吧”。

　　通过上面的分析，有时侯我们太快了并不是好事，我们是否需要慢下来，为每一层的方法加上测试，一步一个脚印，而不是急于展示自己的“成果”呢？ 我们每一步都走的很自信不是很好吗？

　　最后补充一下：

　　有以下几种慢，是不同于本主题说的慢，我一般认为是人品有问题。

　　● 一天应该做完的，三天都没做完的。

　　● 三天的活用一天做完，汇报说是干了三天的。

　　● 在客户的项目里实验各种新技术的。

　　● 晚上不知干啥，白天眯着眼睛干活的。

　　● 白天边上网，边聊天，边…， 边写代码的。

　　本文转载自：http://www.cnblogs.com/cnblogsfans/archive/2009/07/29/1534523.html