开发调试之确定原则

所谓的确定原则，指的是对于开发过程中遇到的问题，我们解决问题的思路应该是从胜利走向胜利、从确定走向确定，而不是相反，即从失败走向胜利、从不确定走向确定。这个原则虽然说起来简单，但能成为习惯，遇到问题就按照这个原则去解决却不太容易。

         举个例子来说明，比如某软件的 v 0.66版本发现某 bug，而回归到 v 0.60 版本却无此问题，对这个bug ，我们的工程师应该怎么查呢？经过观察，一般有三种思路：1 是根据bug的现象推测问题在哪，然后根据推测调整代码，接着发布版本进行测试；2 从 v 0.66 版本开始，接着 v 0.65 等等到 v 0.60，看哪个版本开始没问题，然后再进行分析和调整代码； 3 从 v 0.60 版本开始，接着 v 0.61 等等到 v 0.66，看哪个版本开始出现问题，然后再进行分析和调整代码。

         第一种思路是程序员的第一感觉，如果简单的bug，这种思路是最好最快的解决问题思路，但是对于比较困难的 bug，这种思路就会显示出它的弊端，常常效率会比较低。我一般是建议先允许工程师花2天的时间按照自己的推测来查找bug，两天过后如果还没定位问题，则要求工程师采取最稳妥的版本回归的方式进行bug的修复。

         第二种思路相对而言，比第三种思路更常见，给我的感觉是程序员潜意识里就喜欢这种方法。其实，根据前面所说的确定原则，我们应该选择的版本回归方式是第三种思路。

         初看起来，第二种思路和第三种思路差别不大，甚至有人会说，如果bug仅发生在 v 0.66 版本时（即 v 0.65 版本仍然是好的），第二种思路仅需做一次回归即可定位问题，而第三种思路却要回归五个版本才可以定位问题版本。

         我的意见是，如果造成该 bug 的错误仅仅是一处（即某个版本），确实两种思路区别不大，但是如果造成某个错误现象的原因超过一处的话，那毫无疑问第三种思路比第二种思路要好太多了。

         举个极端的例子，假设系统在输入变量值为10 的情况下，输出的正确值是 100，也就是 v 0.60 版本（正确版本）的输出是 100；然后很不幸，v 0.60 后的每个版本新增模块都有些问题，并且导致每个版本的输出都不一样，他们分别是 v 0.61 输出 150， v 0.62 输出 180，v 0.63 输出 200，v 0.64 输出 250，v 0.65 输出300，v 0.66 输出 500。在这种极端情况下，如果用第二种思路去解决问题，我们看下解决问题的过程。首先，因为从 v 0.65 版本开始找，找到了第一个没问题版本，即 v 0.60，然后修复 0.61 版本中的问题，修复之后，发现 v 0.66 版本的值仍然是错误的（因为 v 0.62 到 v 0.66 的错误并未被修正），这时候工程师就会陷到一个纠结的境地，即如果认为是 v 0.61 新增模块导致的bug，那么修复之后bug应该消失，可是现实是没有消失；如果认为 v 0.61 没问题，那问题到底出现在哪儿？实际上在这个例子中，单纯修复任意一个版本的bug 都无法最终解决问题。

         对付这样的极端例子，按照确定原则来做的话，bug总是可以很容易的解决的。首先，找到第一个出错版本即 v 0.61 版本，然后专心修复该版本的 bug，即确保 v 0.61 版本的输出是正确值 100。这时候把修复过的代码合并到 v 0.66 版本测试，此时依然会发现 v 0.66 版本无法输出正确值。但是没关系，此时只需要迭代的运用第三种思路即可，直到问题的最终解决。

         确定原则是一个很重要和实用的工作原则，在实际开发工作中，遇到问题一定要有意识的把这个原则运用起来，否则的话，就很容易跑到潜意识中的第二种思路了。