面对未来不确定性变化编码
量子力学里的薛定谔的猫。
假设一个封闭的盒子里有一只猫和一颗放射性粒子。这颗粒子有50%的概率裂变成两个。如果分裂了，猫会被杀死。如果没发生裂变，猫就没事。那么这只猫死了还是活着？根据薛定谔的理论，正确答案是两者都是（至少在盒子保持关闭状态时是这样）。每当一个亚核反应发生时，宇宙就会被克隆。在其中一个宇宙中，事件发生了，而在另一个宇宙中则没有。猫在一个宇宙中活着，在另一个宇宙中死了。只有当你打开盒子后，才知道自己处于哪个宇宙。
未来不可知，今天的代码，在未来必然需要被改动。面对不确定性的未来，我们要如何编码？
不以当前目标为标准，而要以未来的目标为标准，支持更多可能的变化。这并不是要我们能实现那么多功能，而是在架构上更容易支持切换。
系统设计越灵活可能就越复杂，实现的时间就越长。我们需要找到平衡。我个人的经验就是把那些经常变动的地方考虑进去即可。比如我们设计一个奖励系统，每个角色完成某个或多个任务就会有奖励。那中间可能变化的就是角色和奖励任务。我们要假设他是一定会变化的，在设计中把奖励任务和角色做得更灵活，可配置，而不应该只以现有奖励的任务和角色来写。
估算时间
对任务做估算是项目中最常见的活了，但实际上除非我们以前做过相同的项目，我们是很难精准给出一个完成时间的。
通常我们给出时间都有很多隐含前提，而这些前提我们经常会忽略。比如：“假设没有交通事故，车里也有汽油，那么我会在 20 分钟内抵达那里。“
想要给出相对准确的时间，首先是给系统建模。
建模的过程，从长远来看，既富创造性又实用。通常，在建模的过程中会发现一些表面上看不出来的潜在模式和过程。你甚至可能会去想重新审视最初的问题：“你要一个对做X的预估，然而这事很像一个X的变种Y。而Y用一半的时间就能完成，仅仅只比X少一个特性而已。”
建模会给估算过程引入不准确性。这不可避免，但也是有益的。你在用模型的简单性来换取精确性。在模型上加倍的努力可能只会换来精度上的微小提升。经验会告诉你何时应停止精炼。
我的理解是，建模就是把经验积累用标准的方法输出，比如登录注册这个功能做过了很多次，大概花费的时间在哪些参数上。然后在参数不变的情况下，我们能得到相对准确的时间。如果每个参数我们都能评估，那总的时间就能评估出来。
正常工作的开发时间，都是从需求原型来评估的，根据原型效果来看功能。根据功能来拆解成每天的工作。然后把所有人的计划合在一起，确认联调时间、测试时间和上线时间。当然这里有很多假设，比如开发中不会遇到技术难点，需求理解已知且需求不微调等等。我们需要对这部分时间做时间上的调控。
这个给我的启示就是，记录每一次功能的预计时间和实际开销时间。然后找原因，原因一般都是某些地方（参数）不对。只要记录足够多的功能和参数。下次在评估工作量就会越来越准。
