技术债

总结一下今天排查出的一个bug

Technology Debt

如何发现bug

最近屡次有用户报告在我的网络应用上登陆失败，我听到这个感觉很不可思议，因为我的代码逻辑就是直接转发给第三方验证机构，我作为一个中介应该是最不应该出错的地方。所以我的第一反应就是用户输入了错误的用户名和密码。

跟一些用户交流以后，我劝他们再试一次，今天之前这种方法都成功了，于是虽然问题很奇怪，我也没觉得有太大问题。再加上问题无法重现，debug并不是我的选择。

然而今天又出了一次错误，我走到用户跟前看着他输入了一次，应用提示用户名密码错误，换浏览器、清缓存以后都不行，然而让他直接去第三方认证却通过了。这就证明了我的程序逻辑确实存在问题。最终我发现我的HTML代码中有两个id为password的input标签，这就导致jQuery有50%的几率取到空白的值，黄师傅连续多次失败确实挺倒霉，但还好有他，让我找到了root cause.

这次debug的一些措施我觉得值得记录下来，因为面对未知的问题，这些都是很有价值的探索方法。

Debug措施1，加logger

后端有一个转发用户名密码的API，我加入了logger，让它把每一次出错的用户名密码记录下来；也新学习了log4j的配置方法，让该API的log打在一个和普通log不同的文件里，方便查询。

虽然这个措施没有直接解决问题，但是在后续的debug中，logger是决策的基础，看log可以支持我们的猜测，也可以让开发者对于程序更有控制力。

Debug措施2，模拟用户操作

这个应用上需要用户验证的操作叫做“signoff”，这会直接通知所有相关人员这个issue已经完成，所以直接测试的风险是非常大的，我们应该另辟蹊径。

我们建立了多个用来测试该应用的issue，并通告同事这些issue都是用于测试，不需要关注。前段时间为了本地方便测试，我让程序能够基于配置文件来选择issue的数据源，一个选择是从正常通道得到，另一个选择是为了测试，让应用得到的所有issue都是我们自己建立的。由于HTTPS之类的环境差异，本地重现不出生产环境的错误，所以我们把配置文件加入了生产环境，快速测试了身份验证API，然后很快将配置文件改回原来的状态，以防止影响用户。

Debug措施3，分析前端HTML代码

这个方法很暴力，直接右击查看源代码，copy到Sublime Text里分析，这才发现有两个id一样的元素，找到了问题的root cause. 启发应该是每次发布前要用一些工具来测试自己HTML代码的合法程度，这种冗余id的情况明显是会有warning的，如果有好的工具提示的话，就可以避免该错误。