背景
我们在做一个 application engine ，涉及到今天要讲的内容有两部分，运行时环境和对象解析库。运行时环境顾名思义就是用户代码运行时的环节，类似于 jvm ，而对象解析库就类似于 javac ＋ classloader 。这两部分基本上同时进行开发的，也就是说在运行时环境还没确定已何种方式使用对象解析库时，对象解析库就开始了设计和开发的工作。而我就是那个设计和开发的人。
需求
因为当时运行时环境还在设计和开发中，而我拿到的需求是写一个较为通用的解析库，负责解析对象文件并装配上一些预定义的方法。
设计
因为对象具体的行为是由运行时环境来执行的，而解析库又要负责解析对象应该具备哪些行为，并把相应的行为定义上去。所以我就定义了一个接口来表示所有的原子行为，然后解析对象并装配上行为（有可能是原子行为或原子行为的组合）。当运行时环境需要使用解析库时，实现原子行为的接口即可。
选择
解析库是在运行时之前开发完成的，之后我又去做了别的事情。等到运行时需要使用解析库时，才发现两个设计人员的概念模型是不一致的。在我的想法里，解析库是可以运行在不同运行时环境的，所以我定义了一组原子行为由运行时环境来实现。而设计运行时环境的人想法是由环境对外提供一个标准方法，解析库通过这个方法实现所有对象的行为。
可以说解析库就是为运行时环境而生的，所以解析库要改。那么有两个选择摆在我面前。
重构解析库
写一个适配器，适配器使用环境提供的标准方法实现解析库借口定义的原子行为
其实我的优先选择是重构，但考虑到时间因素，最后采取了第二个方案。
重点来了
适配器很快就写完了，整个系统也通过跑了几个简单的 demo 得到了验证。于是我又去忙别的事情了。之后的莫一天，有一个验证别的模块的功能跑不通，于是怀疑是解析库的 bug 。业务逻辑是这样的：
环境先提供了一个标准方法来解析一批对象，这时候对象的表现是正常的。
环境又提供了另一个标准方法来解析另一批对象，这时候这批对象的表现也是正常的。
接着环境再调用第一批对象时就表现出了异常。
其实碰到这样的问题，最简单的方式就是在解析库里加一个这种场景的测试，就知道是不是解析库的问题了。然而当时我的第一选择是通过逻辑推断来定位 bug ，因为当解析完成时，对象和方法的关系就已经绑定了，如果起先没有问题，而后来出现问题，那很有可能是这个方法被变更了。所以基本上花了十几分钟来检查环境的代码和 demo 的代码可能存在什么问题。然后又大概花了五分钟来说明我推断的理由，所以差不多浪费了二十分钟后，我终于选择增加一个场景测试来判断问题。而加入这个测试只花了不到五分钟，然后两分钟后就定位到问题了，最后修改的代码在十行内，当然修改方案想的时间比较久。
事后下班回家的路上我在想当时的选择是否正确？在我听完 bug 描述之后，几乎本能的要写一个测试来证明这不是解析库的问题，然而后来我的选择却不是这个，我试着分析自己的心理。首先无论引起 bug 真实的原因是什么，这个测试都是要加的。但如果加了测试以后证明不是解析库的 bug ，问题还是没有解决，需要继续寻找问题的所在。而当时听完描述之后我自信的认定这不可能是解析库的问题，所以想要跳过写测试的那一阶段，直接进入找问题的阶段。
这里看上去是我过分自信的问题，其实自信不是问题，而是我的判断依据出了问题。在我的概念模型里对象和方法的关系在解析时就做了绑定，而解析库在解析时实际的行为是绑定对象和原子行为实现类的关系。运行时虽然定义了两个不同的方法，但原子行为实现类却是一个（原先的概念模型里一个环节一个实现类是合理的）。问题就在于我脑子里的概念模型与系统实际的概念模型不一致，所以才导致我认为不会出问题的地方出了问题。这其实也是当初我优先选择重构解析库的原因。
