促使我思想转变的原因就是两个字：变化。我原来也知道变化对设计的影响，但是还是低估了变化对设计带来的冲击。现实中的详细设计只是一个看上去很美的东西，开始编写代码一个月后的详细设计就基本上不能指导代码编写了，甚至变成和实际代码完全两回事的东西，成了一堆废纸，原因还是那两个字：变化。是的，变化，在某个时间已经很缜密的设计，在下个时间就会变得漏洞百出，因为计划赶不上变化，通常情况下，详细设计文档从其完成的那一刻起就开始散发出“腐败”的味道。只有没有任何软件开发经验的人才会天真地认为一次做好完备的详细设计，然后就可以在其指导下完成软件开发，最终得到产品。
在传统的软件过程中，面对逐渐散发出“腐败”味道的设计文档，通常有两种对策，一种是安排专职的文档开发人员，每次在代码中修改设计都及时更新到设计文档中，以保持文档的“新鲜”。其实这种方法也只是一种看上去很美的东西，且不说多数项目组都不会有多余的人手专职做文档开发（有哪个项目组敢在项目还在进行中就说自己的人手足够了？），就算有这样一个文档开发人员，那么是否每次设计上的小修改都会通知到他（她）呢？显然不会，他（她）必须Review 每一个开发人员的代码，并与大家随时沟通，发现与原始设计不一致的修改，这样会累死人的。那么是否可以由开发人员自己负责维护与自己工作相关的那部分文档呢？试想一下，当轰轰烈烈地代码编写开始后，或者头顶着产品交付倒计时牌，开发人员是否还有“闲情逸致”时不时停下正在Coding的手去重新修改一下设计文档呢？另一种对策是任由设计文档慢慢“腐败”，把主要力量集中在代码上，毕竟最终交付产品依靠代码而不是设计文档。这种情况下原来花费大量时间完成设计文档纯粹是浪费时间，哪怕是对自己人也没有丝毫用处，如果我是这个项目组中补充进来的新人，看到这样的文档和那样的代码，可能会得精神分裂症。
文章来源于领测软件测试网 https://www.ltesting.net/