代码审查普遍存在的6大问题
极客时间编辑部
讲述：初明明大小：4.30M时长：04:42
你好，欢迎收听极客视点。
将代码评审作为开发流程不可或缺的一部分有助于形成一种健康的反馈文化，越严格的代码审查越有利于将隐患扼杀在摇篮里。近日，一位网名为“松花皮蛋 me”的京东工程师在InfoQ发文，总结了一些代码评审过程中普遍存在的问题，以下为他的自述。
1. 忽视变更的说明
说实在的，注释和变更说明真的是一对难兄难弟，我们经常对他们视而不见，完全没有在开源框架中注意到他们。其实不难发现框架的代码注释和变更说明是非常多的，包括使用示例、开始支持的版本号等等，同时也不难发现我们的代码库提交变更注释满屏都是 “update”，满怀期待地打开下一页，终究还是被打脸了。或许背后是规范问题，或许是因为我们还没有开始问候前人。
2. 滥用异常捕获
不少项目中都会出现一些奇怪的操作，每个控制器方法都使用了全局的 try-catch 异常捕获，然后在其 catch 方法中处理可用率下降埋点。编程容易产生模板化思维，可能你自己不觉得有什么不妥，但是这种方式实在不优雅。我们完全可以使用全局切面进行统一异常处理，根据返回的错误码进行可用率下降埋点。假如控制器方法返回不是统一的规范结果对象，那就停下手中的工作开始重构吧。另外优化前的方法，很容易让我们对中间结果放松警惕，毕竟有这么大而全的异常捕获，是不是非空判断或者非法判断统统都可以省略了？
上面说的问题完全不会影响代码的运行，但是场景切换到事务操作，就不得不小心了，因为生吞异常会导致事务回滚没有机会执行。所以，如果调用者关心异常，就尽情往上层抛。
3. 过度相信第三方
过度相信第三方的意思，包括前端传过来的参数没有进行校验、调用上游接口返回的结果没有进行判断、不进行参数校验就调用其他团队提供的写数据接口，这有可能导致 SQL 漏洞攻击，即使主要责任不是自身。不过，我在真实开发中就因为过度相信第三方差点体验了一把删库跑路，我从类中拷贝了几行代码，当参数非空时就执行更新操作，但是当前端没有传该参数时，该参数类型为非包装类也就是默认非空，从而覆盖数据库记录。这种错误也是新手处理空值判断容易犯的。
4. 变量的作用域过大
我们会不经意间开始随意玩弄变量的作用域，比如把变量的创建和赋值操作以两个不同的方法实现，这显然给系统增加了不确定性。另外，变量太多容易淹没主干逻辑。如果它们有联系或者会产生协作，应该共用一个方法专门管理。
5. 处理过程缺少阶段性结果
没有程序员喜欢阅读大量的判断语句，而提前异常判断快速返回结果是一个基本的优化方法，比如当校验不合法时直接返回，再比如移除控制标记，来减少循环嵌套。语义再拔高点不就是处理过程要有阶段性结果了吗？这样代码更加有层次感，整体流程也更加清晰。
6. 日记打印问题
大部分公司都采用了微服务架构，这种架构的痛点之一就是问题的快速排查，特别是涉及到跨团队时。而封装日记信息就是我们唾手可得的利器，记录参数、中间结果、返回结果、异常信息，有了这些信息后，找上游反馈问题就更加理直气壮了，而不需要修改代码添加日记后重新上线。所以，尽量多记录一些异常信息，尽量多添加一些 INFO 级别的日记。不过，日记记录毕竟是旁路逻辑，因为记录而产生的空指针异常或者内存溢出就得不偿失了，所以记录时要避免序列化空对象，避免使用无界的异步队列。
以上就是代码审查过程中容易犯的六种错误，包括忽视变更的说明、滥用异常捕获、过度相信第三方、变量的作用域过大、处理过程缺少阶段性结果、日记打印问题，希望对你有所帮助，也欢迎你补充更多代码审查的问题。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
程序员二师兄代码审查会是一个漫长的过程，总会有人不遵循规范、不按套路出牌2
小斧1. 缺少变更的说明 2. 滥用异常捕获 3. 过度相信第三方 4. 变量的作用域过大 5. 处理过程缺少阶段性结果 6. 日记打印问题
种树早点总结： 1. 变更说明 2. 异常捕获，宜抛出到最上层 3. 永远不要相信第三方，不要将自己命运的决定权交由其他人 4. 变量作用域过大 5. 处理过程缺少阶段性结果 6. 日志打印要全面，尤其是异常信息
收起评论