别含蓄，面向bug编程，提高命中率！

昨天我在公司查看某个项目上的代码，收获颇丰。这个项目我有段时间没关注了，gitk一看，同事们竟然已经有十多次新的commit了。我一个个查看每次修改。最终留意到同事对之前遗留的一个bug的解决方案。

这个bug简言之，程序运行时，动作A之后会在一个buffer里留下数据，这个数据十分重要，是我们设计的必须的一个流程，不可砍掉。但是在特定的场景B下，动作A的数据对B有负面影响，需要先清掉该数据再进行B剩余的动作。这个bug在场景B下必现，至少两个项目上都存在这个bug且客户已经明确提出。

之前为了“解决”这个bug，同事们想了些办法，比如：

方案I：启用timer：动作A完成一定时间里场景B都没出现的话，就把A的数据干掉，这样对场景B就没有影响了。但时间该定多少呢？尽管有一个相对可靠的经验值，但谁也不能保证小概率事件不发生，况且这是以量产为目标的项目。

方案II：我提出来，封装一个WIN32 API，企图检测另一个场景C，以此来处理动作A的数据。尽管自测ok，但通不过一些特殊的场景D、E、F。只得做罢！

方案III：同事又想出一个办法——注册表！在动作A之后，写入注册表；场景B发生时，先读取注册表，以此来决定是否要干掉动作A的数据。这个方案貌似是可行的，但那之后听说是可能有side effect，这才有了昨天看到的那个解决方案。

最新提交的解决方案，简言之，是直接判断场景B是否发生，如果发生，就把动作A的结果干掉，再进行场景B的剩余动作。这个解决方案不采取多余的动作，直接针对场景B，既不会有side effect，也可以保证100%解决该bug而不是靠经验值。

公司的一面墙上贴了张图，是一个靶子，靶子上面写着“提高产品命中率”。真有意思，回想我们解这个bug的历程，方案I、II、III都是在绕，都是在一个必现的动作A之后采用其他过程来检测、判断和处理，过程绞尽脑汁，结果却那么含蓄。但是最新提交的方案就没去想多余的动作，既然是场景B下必现，那么解决问题时就直指场景B，一击命中！

当然了，最新的方案也是在不断试错后探索成功的。让我感到颇有收获的，是这样的解决问题的思路。正如公司墙上的靶子一样，要提高解bug的命中率，那就直面bug出现的根本原因。还有一点让我感叹的，是组里代码的share，我可以看到有经验的同事们面对一个bug，是如何想办法来规避和解决。

加班一天，值了！