A：这里用Integer.valueOf把字符串强制转化为整数，但没有判断是否能转，也没有捕捉异常，太粗暴了。
B：哎呀，和客户端做了约定，这个一定是可转为整数的。
A：……
类似上面的对话，程序员读者一定不陌生。B的行为背后有着坚强的道理支撑，充分相信别人的承诺，让事情变得简单，有何不可？一时竟无法反驳，倒显得A鸡蛋里挑骨头了。
开源项目不靠谱，必须自己写。
这个就不必再开会沟通了，早说过了，大家肯定都知道的。
类似的对话不胜枚举，润物细无声地融入日常生活，以至于没人发觉它有丝毫的问题。
真没问题吗？
你把这段代码的work寄托在了诸多假设上。假设客户端同学正确理解了这个约定，假设他敲代码时没有忘记，假设他写了注释给后人看，假设后人get到且遵守了，假设不会有人恶意调用接口……呵呵。
什么，你只关心它现在能work，才不care以后怎样？滚，别让我再看到你。
Assumption is the mother of all screw-ups.by Wethern
不信？问特斯拉老板去，相信马斯克会用他的“第一原理”呼你一脸，继续滚。
在每一系统的探索中，存在第一原理，是一个最基本的命题或假设，不能被省略或删除，也不能被违反。
眼熟吧，没错，数学里的公理。“两点之间，直线最短”……
基于颠不破的事实、真理，还是基于经验、猜测，决定了事物的生命力。
马斯克牛逼，首先在于他的思考架构，剥开表象，洞察本质，然后从本质一层层推演。
这很难，真的很难。但至少，你得努力。至少，你得开始提防“假设”，下次撞见的时候，祭之以“质疑”，尤其是对你自己的假设。
害人之心不可有，承诺别人不返回null，就努力做到；防人之心不可无，虽然别人承诺了不返回null，但你得“质疑”一下，加个判断，善待生命，远离NPE。
线上又出诡异问题了，你感觉是线程池的问题，决定换个库，发布看看？ 也许你是胡适的粉丝，对“大胆假设”深以为然，但请你也一并记住他的下半句，“小心求证”。没有经过验证的假设都是耍流氓，无法解释现象的措施都是投机。
重构一词，现在越来越高大上了，三天两头听人说，我准备重构下XX模块，似乎没有做过重构的开发，都不好意思叫自己开发。如果真是需求改得面目全非那倒也罢了，如果是之前代码写得烂，呵呵。于我而言，重构虽有废旧立新的快感，更有悔不当初的痛苦。尤其是发现当初把一些不靠谱的假设当成前提，不禁要自问，尼玛，这真是我写的代码？take it for granted的假设残酷地坍塌了，前期考虑不足欠下的巨款，也该还了，然而，摇身一变，它们成了重构的光鲜理由。
这是横亘在通往架构师之路上的一座高山。
功夫在代码外，在于思维起点。是从实际出发，还是从主观出发？从数学出发，还是从规则出发？从需求出发，还是从功能出发？越原始的出发点，越牢靠，在此基础上理性推导，逻辑证实，构建的系统就稳固，重构的需求就低。
因此，在制定方案时，要明确评判标准，记录决策过程的假设，以及假设的论证方式。你得让别人清楚明白地知道这一过程，不论是为了堵上后人质疑的嘴，还是为了供后续重新评估。
已经不再想当然地假设了，可有些东西本身是不确定的，不假设就无法继续啊。没错，不得不承认，这个世界本来就有很多不确定性，这个时候，我们能做的是，遵守延迟决策法则。能推迟就推迟，直到有迹象可以观察，测试和验证，再决策不晚。在此之前，总是选择包容所有可能性的方案，不确定是Integer还是Float，那干脆用Number吧，顺带还有了更宽的适用面。这么看，不确定性不再是负担，反倒成了一种动力，促使代码更通用的动力。
总是保留各种可能性，给自己留后路。鸡贼，但鸡贼得有理有据，这个理就是最大熵原理。算法的应用，不光是写代码的过程，工作乃至生活，无所不在。关于不确定性和最大熵原理，这里不展开了，想进一步了解的，请戳文末的“阅读原文”。
小到一个接口参数，大到一个产品功能，把它当成一种未知，忽略“绝对不改”的鬼话，抛弃主观假设，包容更多可能，前期，多花点时间思考，后期，省出时间喝茶灌水，看路过的世界。