推迟编码，还是设计已死？

项目到了编码阶段，往往有一半甚至更多的时间，是用在调试上。如果项目成员的编码经验都比较充足的话，在每个模块内部能找到的Bug是比较少的；如果这种Bug的密集率高于平均值，说明需要采用措施来提高代码的质量，这种措施是比较多而且经过实践证明的，比如review，pair programming等等。

但是另外一种情况也经常出现，code本身的质量比较好，调试时发现的错误，往往来自各个模块交互的位置。经验丰富的程序员可以在自己掌控的模块内部保证一个稳定的Bug/Line的出现率，但保证各模块间稳定、顺畅、按预计设计来进行交互，就是整个团队需要共同努力的事情。

回想我们的项目，仔细考虑自己debug的时间，很多人都会有共识，就是太多的时间用在了intergration方面。更进一步，我们是不是用了太多的时间debug？

debug是程序员喜欢做的事情之一，也是经理们喜欢的之一，因为这个过程中花费的精力和产生的成果都是比较清晰的。我是说，“我们加班了五天，终于解决了这个大问题...”这样的报告，是不是更容易打动老板？

但是，我们也可以不要debug，如果没有bug话。

Zero Bug！Impossible！

我知道你会这么说。不需要Zero Bug,只要能有一些微小的改进。我们用于debug的时间是这么的多，所以只要有一点点改变，就能获得很多的收益。

回到debug的内容上来，如前所述，我们似乎还没有非常好的办法，来依靠经验、技巧或者其他实践过的方法来降低那些游移在模块边缘的难以捕获的缺陷。

直觉上来看，既然缺陷都在模块的边缘和交互时出现，我们就需要像注意模块内部那样来注意模块的交互部分。我们需要投入更多的时间来设计，将设计细化到能直接映射到编码上。把编码部分推迟再推迟，在设计真正完成之前一行code都不写。在设计和review设计的过程中，注意那些交互的部分，用考虑细节、考虑实现的规则来要求我们注意那些边缘化的东西，而不是像我们常常做的那样，定义了些看上去很理想的接口后，就匆匆忙忙的开始编码的阶段。

这是个办法，我知道有些团队是这样做的，而且有很好的效果。设计阶段被真正的重视起来，缺陷被消除在它们产生之前。干软件这行，从一堆代码找出问题所在并且小心翼翼的修好它，总是比别让它出现更费神。

事实上，解决一个问题永远有无穷多的方法。有时向南走或者向北走都能达到目的。

XP所说的Simple Design，看上去也不错。先确定一个核心，然后往上一点点垒东西。只要每一步别出大漏子，你总是能接近目标的。要让程序员们注意的，是充分了解XP的精神，免得把Simple Design变成Zero Design。如果用这个模式，我们只要写一点点的设计文档，就能开始用code实现我们的想法。恩，关键点在于，不像过去的瀑布法搞好几百个模块后大家一起上，现在我们从最核心的那么一两个开始，让旁支末节们一点点生长出来。很难想象这个过程会引入大量的交互上的缺陷。

不过现实永远比理论更难以琢磨，我们总是要考虑政治啦，管理啦，文案工作啦等等各方面。让程序员们沮丧的是，这些东西往往比一个漂亮的项目流程更强有力。

于是我们只能老老实实的两天写出几千行代码，然后用几周的时间来找bug。天天填好加班单，来表示我们是多么的忙碌和尽职。深夜里灯火通明的办公室、大家忙忙碌碌的测试、调试、修改、再编译，这比一堆人默默把早就找不到bug的code重构一下来得热闹的多，不是吗？

明明知道实现不了，还坐在这里想着怎么改进开发过程，居然能写出这么多字，啊啊，我真是无聊。