• 没有及时删掉不再使用的代码
• 单元测试真的不靠谱

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

根本原因有两个。

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

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

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

单元测试真的不靠谱

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

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

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

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

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

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