《程序员修炼之道》- 务实的方法（5）

面对未来不确定性变化编码

量子力学里的薛定谔的猫。

假设一个封闭的盒子里有一只猫和一颗放射性粒子。这颗粒子有 50%的概率裂变成两个。如果分裂了，猫会被杀死。如果没发生裂变，猫就没事。那么这只猫死了还是活着？根据薛定谔的理论，正确答案是两者都是（至少在盒子保持关闭状态时是这样）。每当一个亚核反应发生时，宇宙就会被克隆。在其中一个宇宙中，事件发生了，而在另一个宇宙中则没有。猫在一个宇宙中活着，在另一个宇宙中死了。只有当你打开盒子后，才知道自己处于哪个宇宙。

不以当前目标为标准，而要以未来的目标为标准，支持更多可能的变化。这并不是要我们能实现那么多功能，而是在架构上更容易支持切换。

系统设计越灵活可能就越复杂，实现的时间就越长。我们需要找到平衡。我个人的经验就是把那些经常变动的地方考虑进去即可。比如我们设计一个奖励系统，每个角色完成某个或多个任务就会有奖励。那中间可能变化的就是角色和奖励任务。我们要假设他是一定会变化的，在设计中把奖励任务和角色做得更灵活，可配置，而不应该只以现有奖励的任务和角色来写。

估算时间

对任务做估算是项目中最常见的活了，但实际上除非我们以前做过相同的项目，我们是很难精准给出一个完成时间的。

想要给出相对准确的时间，首先是给系统建模。

建模的过程，从长远来看，既富创造性又实用。通常，在建模的过程中会发现一些表面上看不出来的潜在模式和过程。你甚至可能会去想重新审视最初的问题：“你要一个对做 X 的预估，然而这事很像一个 X 的变种 Y。而 Y 用一半的时间就能完成，仅仅只比 X 少一个特性而已。”

建模会给估算过程引入不准确性。这不可避免，但也是有益的。你在用模型的简单性来换取精确性。在模型上加倍的努力可能只会换来精度上的微小提升。经验会告诉你何时应停止精炼。

我的理解是，建模就是把经验积累用标准的方法输出，比如登录注册这个功能做过了很多次，大概花费的时间在哪些参数上。然后在参数不变的情况下，我们能得到相对准确的时间。如果每个参数我们都能评估，那总的时间就能评估出来。

正常工作的开发时间，都是从需求原型来评估的，根据原型效果来看功能。根据功能来拆解成每天的工作。然后把所有人的计划合在一起，确认联调时间、测试时间和上线时间。当然这里有很多假设，比如开发中不会遇到技术难点，需求理解已知且需求不微调等等。我们需要对这部分时间做时间上的调控。