一次程序bug的排查

Posted 2020-09-18

这周准备下一个QA测试的版本，把版本发到测试环境就开始发现各种问题，修修补补搞了一周，总算告一段落了。

 

分析一下几个bug的问题，都集中在程序模块的整合中。一个模块的一个小的修改，造成另一个模块的连锁反应。这种bug在排查的时候非常花时间，因为往往程序出错和报错的地方并不是程序真正错的地方，对着本来就没有问题的代码一遍一遍的看是看不出来问题的。这次我们最后解决问题，用了一个笨办法。我们把从上一个版本到现在的有关的commit都看了一遍，最后在一个很不起眼的地方找到了问题。

 

在retro过程中，和同事讨论了一下以后如何减少这种bug的出现。

 

首先，当这种bug出现的时候，我们不应该纠结于我们认为问题在的地方。特别是当自己不确定的时候，我们最好找个同事一起来看。如果两个人四双眼睛半个小时都看不出来问题，这就很有可能是因为方向错了。这个时候，跳出来换个思路可能是更好的选择。

 

第二，因为单元测试已经把上下文的环境都固定了， 这种bug单元测试对它是无效的。回看这周遇到的bug，每个代码修改都有充足的单元测试，但是这些单元测试从假设就搞错了。对于这种bug，我们更需要有上下文的集成测试。写好和维护好集成测试是一个很大的工程，但是对发现这种跨模块的问题会很有帮助。同时，可以考虑使用一些BDD的测试框架，这些框架经过包装可以让QA对很多测试自动化。当有新同事的时候，让他们从集成测试中开始了解系统，也是很好的选择。

 

最后，我们在软件的设计和开发中还应该注意什么呢？通过对这几个bug的分析，我们认为代码在最初的设计中使用了很多继承来提高重用性，避免重复开发。这些代码经历了4，5年一代一代的程序员，现在已经过于臃肿了，很多最初的设计考虑也在人事更替中慢慢消失了。当一些代码进入维护期的时候，我们更希望它们小而精，这样的代码更加便于维护，也就更加容易修改，而更有生命力。相反，这种在当初强调高重用而设计的大而全的代码，反而非常难以修改，面对一个1500行的class，我们几个人经过讨论，最终决定推倒重建。