昨天我在公司查看某个项目上的代码,收获颇丰。这个项目我有段时间没关注了,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,是如何想办法来规避和解决。
加班一天,值了!