内容简介:最近我负责维护的一套系统出了不少问题。痛定思痛,决定总结一下。根本原因有两个。在最近的重构中,我重写了一部分功能,导致原来的一些代码成了幽灵代码。导致问题的幽灵代码是一个 getter,它返回一个类的属性。这个属性在旧逻辑中一定会被设置,但新逻辑中不会。因为需要删除的代码很多,我在重构时加了不少
最近我负责维护的一套系统出了不少问题。痛定思痛,决定总结一下。
根本原因有两个。
没有及时删掉不再使用的代码
在最近的重构中,我重写了一部分功能,导致原来的一些代码成了幽灵代码。导致问题的幽灵代码是一个 getter,它返回一个类的属性。这个属性在旧逻辑中一定会被设置,但新逻辑中不会。因为需要删除的代码很多,我在重构时加了不少 TODO
,想的是等测试没问题了再一起删掉。然后就出问题了。一块我没注意到的代码调用了这个 getter,并且依赖它的返回值进行一系列判断,由于拿不到正确的值,这部分功能直接挂了。
这给了我一个教训:删除幽灵代码是实现新功能以及重构的必要工作,而不是后续。不仅仅是要最终删掉,还要删得及时。程序员有种本能想代码多留一会,“万一有用呢”。我们必须去对抗这种本能。
单元测试真的不靠谱
按理说有测试,前面那个问题应该能发现。但实际上并没有。单元测试里该 mock 的东西都被 mock 掉了,包括那个不应该继续存在的属性,导致测试 false positive.
从本质上来说,单元测试之所以不能发现所有问题,是因为程序有无穷多的输入和内部状态,而单元测试只能检测其中一部分,即使代码测试覆盖率达到了 100%。依赖别的组件的测试又往往需要 mock,一旦实际运行状态和 mock 不符,等于什么也没测。因此测试不挂说明不了任何问题。
一般而言,集成测试(integration test)是单元测试的良好补充。然而这套系统是一个 streaming system,数据来源又多,想搞集成测试是真的难,我并没有足够的时间来做这件事。这种情况下,能做的也只有起一个测试环境,手动测试。其实重构后的代码在测试环境里也跑了几天,但我恰恰没去测试那个功能。以前看见 QA 们照着文档一遍遍重复相同的操作,觉得真繁琐,现在想来,这种繁琐和机械化是不可或缺的。
类似的,另外一个 bug 也是因为测试里输入设置得不对,并且最后没有实际验证。
话说回来,如果有无限时间,那么我们完全可以把整套运行逻辑都想得很清楚,检查每一个单元测试是否需要更新,这样所有的问题都可以避免。然而人不是机器,一定会有注意不到事,并且我们也没有无限的时间。因此我们只能尽量运用一些“原则”,去减小犯错的可能或是提早发现错误。
要学的东西果然还有很多啊。
以上所述就是小编给大家介绍的《最近遇到的几个问题》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- Java通过mysql-connector-java-8.0.11连接MySQL Server 8.0遇到的几个问题
- 关于构建数据仓库的几个问题
- 通过几个问题深入浅出Vue
- 关于软件生命周期模型的几个问题
- 网络爬虫设计中需要注意的几个问题
- 关于Java收费这事,回答几个问题
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。