详细设计成软件开发过程中的浪费
但是现实的情况真的如此吗？我们来反思一下：
(1)详细设计和代码的吻合程度有多高？
假设在项目中，代码在测试后修改完毕提交后，并不修改详细设计，则详细设计和代码之间并不吻合，并且很大程度上，吻合度会非常低。
如果详细设计和最终的代码并不吻合，那么这样的详细设计并不能给将来的维护带来任何帮助。
如果详细设计并不能给后续带来帮助，为什么要书写它呢？
因为——详细设计是用来指导代码书写的。
(2)详细设计对代码的指导意义有多大？
详细设计的类图是用来定义类框架之间的关系的；其中的时序图（有时也用流程图）是用来定义方法之间的调用关系的。
如果说详细设计是这么定义的，那么为什么不直接用IDE写成代码形式？
因为——详细设计的过程是需要记录文档以备后查的。
(3)详细设计是怎么复查和修改的？
详细设计的复查是通过对书写完成的详细设计文档进行阅读和审查，并指出其中可能出现的错误和遗漏。
然后针对提出的问题进行修改，直到修改完成为止。
为什么要这样复查和修改呢？因为详细设计的质量提高有助于早期发现问题。
(4)既然详细设计是用来指导代码书写的，为什么还需要后续的测试？
换句话说，为什么详细设计不能够100%正确。
这么问并不是要求把详细设计100%书写正确——因为这是个不可能的任务。
详细设计是一个猜想的过程，其复查和修改也都是在猜测中完成的。
详细设计到底做成什么样才能够更有效地指导代码书写呢？
(5)详细设计的完成是怎么定义的？
详细设计的完成指标是：详细设计的页数达到若干页，每页复查发现的问题达到多少个。
详细设计是用来指导代码书写的。为什么不从指导代码书写的方面进行指标定义？
详细设计还有问题残留的时候怎么就开始代码书写了？
现实情况是：详细设计的完成是以项目经理的喜好决定的——往往是时间压力决定的，还有时间就继续写；没有时间就算完成了。
(6)为什么觉得详细设计是必要的过程？
因为是规定的。因为别人都这么做。这应该不是答案吧？
那么到底应该怎么书写详细设计呢？答案是：不写！理由如下：
(1) 详细设计的职责不明确
详细设计名将概要设计细化，并指导代码书写。但是反观其阶段结束时间不明确，并且阶段结束的判定标准也没有对如何指导代码书写进行定义，很难说详细设计真的是用来指导代码书写还是将概要设计细化的。
(2) 详细设计没有生产有价值的产物。
据统计，详细设计在项目开发过程中所消耗的工时基本上占编码和单元测试的一半。但是它的产物——UML图可以通过直接书写代码，然后从IDE导出生成，这个过程只需要几秒钟。
但是详细设计还是要做的。这不是和前面矛盾吗？不！
上面说的是写，这里说的是做。
有些处理的条件很多，不是三言两语能够说清楚的，这时候就需要详细设计。
比如：一个由两组条件决定的处理。从需求角度山来说，通过画成二维表可以描述清楚其各个条件组合下的行为
a b c
1 a1 b1 c1
2 a2 b2 c2
3 a3 b3 c3
针对这种情况，如果写流程图，那么代码也将会按照流程图那么书写，代码会变得很冗长。所以流程图并不适合做详细设计。这种情况可以通过类的书写来完成。
假设行条件是时间范围(TimeScope)，分别代表过去(Past)，现在(Present)和将来(Future)而列条件是状态(State)，分别代表申请(Apply)，批准(Approval)和拒绝(Decline)
在类的设计时，以时间范围为主轴，状态为辅轴，那么类定义为:
interface TimeScope {
public void apply();
public void approval();
public voi decline();
} 则Past，Present和Future分别实现相应的方法就可以实现上面需求定义的矩阵。
这种方法叫做桥接模式(Bridge Pattern)
而这个过程并不需要留下文档。
同样大多数情况来说，根据需求可以直接生成代码。而详细设计是一个可以简化到只要几分钟就可以完成的过程。并且，从质量的角度来说，并没有损失。
设想一下，如果一个项目可以略掉详细设计过程，其可以带来的节省有多大。