再次回到设计火候的问题，相当长时间以来潜意识里有一种疑惑，我总想在纸上尽可能详细的设计出来，但是这种做法更加让人疲倦而且慢。

反而稍微做一下设计，然后开始写程序，紧接着再来一次设计，然后进行重构类的修改，反而更加快速。

这个现象我们也见得很多了，敏捷方式的一个表现就是这样，但问题是：why？

为什么我们不能去尽可能的详细，然后一气呵成的把问题搞定？因为信息量。

面对一个规模较大或者新的问题的时候，我们在设计的根节点上可以大致做出框架---比如说这个问题需要用instance来代表每个物体，然后有一个manager统管。这个层次的时候问题信息量很小。

但是如果再往下一级，instance和manager应该承担的具体责任，每个责任要详细的列出来。

这仍旧是可以做的，但是信息量已经很多了，而且这种情况下我们倾向于去定一个完整的解决方案----其中有一些是不必要的。

再往下一级就是实现细节了，每一个需要有什么数据和接口，这一层在我最近几个月编程所解决的问题里面信息量已经大的没法精确控制了。

也就是你仍旧可以去把函数都列出了----我可以去做，但是没有能力做到让我满意的好。

到这一个层面信息量太大，解决方案迎着问题‘而生，但是到了细节这个层面问题是什么？太细太琐碎。因为无法精确的把握，所以会出现很多冗余的实现。所以这个做法并不是不能把问题解决，只是整个过程的方法论不够好，因而生产力不高。

解决方案

【设计】设计到刚才的第二级是刚刚好，要做的事情的本质是：

• 本质的把问题解决方案表达出来----结构和每个模块的职责设计出来
• 最小集----能够把问题定住的解决方案，尽可能紧凑，没有额外的东西
• 这里仍旧没有完全细致的表达“粒度”，只是很粗的说了一下，因为这一块是因人而异的，不能脱离开个人经验和能力甚至心情来谈，直接搞起---痛快，但是常常会需要推到重来，深度设计，前瞻，但是憋闷，不那么爽快。

【第一次实现】这部分关键：

• 保持“最小集”被准确的实现----至于其它部分顺手做了就做了，比如优雅的代码效率上的考量注释等

【重构】在一个版本完成之后，所有细节级的问题就都呈现出来，那么在这个层次去着手解决：也就是重构，时间允许的话就做到完美。

 火候，这个可以说是核心问题，这是一个对具体问题具体人具体分析的一个问题，核心概念是：生产力最大化&个人成长最大化

• 当前你能最大发挥的复杂度----把复杂度分离到各个阶段，以符合人脑和个人特质的方式做事，这样让你可以在体力消耗，产出上找到最好平衡
• 成长：没有挑战就没有成长

本文并不是重复的申述敏捷开发的思想，而是讨论了为什么是这样->如何达到最大的生产力。