Fork me on GitHub

laike9m's blog

Yuri Is Justice

Google

最近遇到的几个问题

最近我负责维护的一套系统出了不少问题。痛定思痛,决定总结一下。

根本原因有两个。

没有及时删掉不再使用的代码

在最近的重构中,我重写了一部分功能,导致原来的一些代码成了幽灵代码。问题源自一个 getter,它返回一个类的属性。这个属性在旧逻辑中一定会被设置,但新逻辑中不会。因为需要删除的代码很多,我在重构时加了不少 TODO,想的是等测试没问题了再一起删掉。然后就出问题了。一块我没注意到的代码调用了这个 getter,并且依赖它的返回值进行一系列判断,由于拿不到正确的值,这部分功能直接挂了。

这给了我一个教训:删除幽灵代码是实现新功能以及重构的必要工作,而不是后续。不仅仅是要最终删掉,还要删得及时。想把代码多留一会是程序员的本能,“万一有用呢”。我们必须去对抗这种本能。

单元测试真的不靠谱

按理说有测试,前面那个问题应该能发现。但实际上并没有。单元测试里该 mock 的东西都被 mock 掉了,包括那个不应该继续存在的属性,导致测试 false positive.

从本质上来说,单元测试之所以不能发现所有问题,是因为程序有无穷多的输入和内部状态,而单元测试只能检测其中一部分,即使代码测试覆盖率达到了 100%。依赖别的组件的测试又往往需要 mock,一旦实际运行状态和 mock 不符,等于什么也没测。因此测试不挂说明不了任何问题。

一般而言,集成测试(integration test)是单元测试的良好补充。然而这套系统是一个 streaming system,数据来源又多,想搞集成测试是真的难,我并没有足够的时间来做这件事。这种情况下,能做的也只有起一个测试环境,手动测试。其实重构后的代码在测试环境里也跑了几天,但我恰恰没去测试那个功能。以前看见 QA 们照着文档一遍遍重复相同的操作,觉得真繁琐,现在想来,这种繁琐和机械化是不可或缺的。

类似的,另外一个 bug 也是因为测试里输入设置得不对,并且最后没有实际验证。

话说回来,如果有无限时间,那么我们完全可以把整套运行逻辑都想得很清楚,检查每一个单元测试是否需要更新,这样所有的问题都可以避免。然而人不是机器,一定会有注意不到事,并且我们也没有无限的时间。因此我们只能尽量运用一些“原则”,去减小犯错的可能或是提早发现错误。

要学的东西果然还有很多啊。

comments powered by Disqus

top