曾经，我认为只要做好详细设计工作，软件编码成为一种体力活。在我印象中传统软件工程理论好像是这么说得：分析和设计是软件生产过程中重要的两个阶段，好的设计产生好的结果，坏的设计产生坏的结果，详细设计文档是软件过程中重要的部分，甚至比代码还重要。国内某人的书中还提到，“只要有了详细设计，哪怕原来的开发人员都离开了，换一批人照着详细设计仍然能把软件做完”。一提到详细设计我的脑子里也已经出现了这样的影子：长长的（或者厚厚的）文档，详细到每个函数，甚至是每个函数参数的名字都定义好了，用这样的详细设计指导代码编写应该是一件多么惬意的事情啊。我推崇这种事无巨细的详细设计，认为只要是设计好能够适应变化，并把软件项目的失败归咎与设计人员的知识、能力或经验不足。这种想法持续了很长时间，直到我有了实际软件项目的经验并开始单独做设计为止。

促使我思想转变的原因是两个字：变化。我原来也知道变化对设计的影响，但是还是低估了变化对设计带来的冲击。现实中的详细设计只是一个看上去很美的东西，开始编写代码一个月后的详细设计基本上不能指导代码编写了，甚至变成和实际代码完全两回事的东西，成了一堆废纸，原因还是那两个字：变化。是的，变化，在某个时间已经很缜密的设计，在下个时间会变得漏洞百出，因为计划赶不上变化，通常情况下，详细设计文档从其完成的那一刻起开始散发出“腐败”的味道。只有没有任何软件开发经验的人才会天真地认为一次做好完备的详细设计，然后可以在其指导下完成软件开发，终得到产品。

在传统的软件过程中，面对逐渐散发出“腐败”味道的设计文档，通常有两种对策，一种是安排专职的文档开发人员，每次在代码中修改设计都及时更新到设计文档中，以保持文档的“新鲜”。其实这种方法也只是一种看上去很美的东西，且不说多数项目组都不会有多余的人手专职做文档开发（有哪个项目组敢在项目还在进行中说自己的人手足够了？），算有这样一个文档开发人员，那么是否每次设计上的小修改都会通知到他（她）呢？显然不会，他（她）必须Review每一个开发人员的代码，并与大家随时沟通，发现与原始设计不一致的修改，这样会累死人的。那么是否可以由开发人员自己负责维护与自己工作相关的那部分文档呢？试想一下，当轰轰烈烈地代码编写开始后，或者头顶着产品交付牌，开发人员是否还有“闲情逸致”时不时停下正在Coding的手去重新修改一下设计文档呢？另一种对策是任由设计文档慢慢“腐败”，把主要力量集中在代码上，毕竟终交付产品依靠代码而不是设计文档。这种情况下原来花费大量时间完成设计文档纯粹是浪费时间，哪怕是对自己人也没有丝毫用处，如果我是这个项目组中补充进来的新人，看到这样的文档和那样的代码，可能会得精神分裂症。