欲速则不达，我们是否需要 放“慢”脚步

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

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

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

• 程序员“说”时间不够。
• 程序员设计方面的知识欠缺。
• 程序员被要求快速的完成功能。
• 程序员受到太多干扰。

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

• 代码全写到Code Behind里，然后就迅速的写界面，然后就不停的运行页面，发现问题，修改，最后完成功能。
• 典型的三层结构，写界面，写后台代码，写逻辑层，写数据层。由上到下。运行界面调试，修改。
• 三层结构，定义Model层，定义数据操作层，定义业务逻辑层，写界面。运行界面调试，修改。
• 三层结构，从底层到上层，每一层做充分的测试后再进入下一层，最后写界面。

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

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

• 第一个迭代递交功能了，但质量较差。
• 第二个迭代也递交了，但之前差的代码让我们慢了下来。
• 第三个迭代想递交时，发现差的代码越来越多，开发效率大大降低，客户开始受不了了。通过加班或者延迟提交，终于客户可以看到功能了。
• 第四个迭代刚准备开始时，发现客户反馈了大量的问题，当想修改代码时，发现代码已经一团乱麻，我们自己这个时候会说当时最么会这么些呢？由于什么什么原因太难改了，我们需要推倒重写。Oh My God,客户这个时候会说，见上帝吧，偶尔会有客户客气点说“下次再合作吧”。

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

最后补充一下：

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

• 一天应该做完的，三天都没做完的。
• 三天的活用一天做完，汇报说是干了三天的。
• 在客户的项目里实验各种新技术的。
• 晚上不知干啥，白天眯着眼睛干活的。
• 白天边上网，边聊天，边…, 边写代码的。

转载请注明如下内容:

博客园

王德水

http://www.cnblogs.com/cnblogsfans