Skip to content

代码审查

代码审查是软件工程中保证代码质量的重要实践,通过同行评审发现潜在问题、分享知识、统一代码风格。有效的代码审查能在代码合并前发现缺陷,降低维护成本,同时促进团队成员之间的技术交流。

审查的价值

质量保障

发现缺陷:多人审查比单人测试更容易发现逻辑错误、边界问题、性能瓶颈。

提高可维护性:审查关注代码可读性、模块划分、命名规范,减少后续维护难度。

统一风格:通过审查逐步统一团队的编码风格和设计模式。

知识传递

学习机会:新人通过审查熟悉代码库,老人通过审查了解不同模块。

最佳实践:审查过程中讨论技术方案,分享设计经验和最佳实践。

集体所有权:代码审查让团队成员对整个代码库负责,而非仅对自己的代码。

审查流程

提交审查

创建 PR/MR:代码完成后创建 Pull Request(GitHub)或 Merge Request(GitLab),包含变更说明和测试计划。

自审:提交前开发者自查代码,确保无低级错误、格式问题、无用的调试代码。

关联任务:将 PR 与任务管理系统(Jira、GitHub Issues)关联,说明变更背景。

审查检查

功能正确性:代码是否实现了预期功能,边界条件是否处理。

代码可读性:命名是否清晰,逻辑是否易懂,注释是否充分。

设计合理性:模块划分是否合理,是否遵循设计原则,是否有过度设计。

测试覆盖:是否有足够的测试用例,是否覆盖边界情况。

性能考虑:是否有明显的性能问题,如 N+1 查询、不必要的循环。

安全性:是否存在安全漏洞,如 SQL 注入、XSS、敏感信息泄露。

审查反馈

具体建议:指出具体问题和改进建议,避免模糊的"这里有问题"。

解释原因:说明为什么需要修改,帮助开发者理解问题本质。

建设性语气:保持友好和尊重,关注代码而非个人。

分类问题:区分必须修复的问题和建议性改进。

修改与合并

响应反馈:开发者对审查意见做出回应,或修改代码或说明理由。

再次审查:修改较大时需要再次审查,确保问题解决。

合并决策:审查通过后合并到主分支,关闭任务。

审查最佳实践

小批量频繁审查

小 PR:保持 PR 范围小,一次只解决一个问题。大 PR 难以审查,容易遗漏问题。

频繁提交:每天提交代码进行审查,而非累积大量代码后一次性审查。小步快跑降低审查成本。

快速响应:审查者在 2-4 小时内响应,避免 PR 长时间阻塞。

审查深度

重点审查:核心逻辑、复杂算法、安全相关代码需要重点审查。

信任团队:简单代码、格式修改可以快速审查,信任团队成员的能力。

分级审查:根据变更影响范围和开发者经验调整审查深度。

工具辅助

代码 diff 工具:使用 GitHub、GitLab 的 diff 视图,清晰展示变更。

自动检查:CI 自动运行格式检查、静态分析,审查者无需关注格式问题。

审查模板:提供审查检查清单,确保关键点不被遗漏。

审查检查清单

功能性

代码是否实现了 PR 描述的功能?

边界条件是否处理(空值、空集合、极端值)?

错误处理是否完善(异常捕获、错误日志、用户提示)?

可读性

命名是否清晰表达了意图(变量名、函数名、类名)?

函数是否过长,是否需要拆分?

是否有重复代码,是否可以提取公共函数?

注释是否必要且准确(不是解释代码在做什么,而是解释为什么这样做)?

设计

是否遵循现有代码风格和设计模式?

类和函数的职责是否单一?

是否有循环依赖,模块划分是否合理?

接口设计是否简洁易用?

测试

是否有足够的单元测试?

是否覆盖了边界情况和错误路径?

测试是否可以稳定运行(非 flaky)?

性能

是否有明显的性能问题(嵌套循环、不必要的数据库查询)?

是否正确使用了缓存?

是否有内存泄漏风险(未关闭的资源、监听器)?

安全

是否有 SQL 注入、XSS、CSRF 等安全漏洞?

敏感信息(密码、密钥)是否正确处理?

权限检查是否完善?

审查工具

GitHub

Pull Request:内置的 PR 功能,支持行内评论、变更请求。

保护分支:设置分支保护规则,要求审查通过才能合并。

代码所有者:指定文件或目录的所有者,需要特定人员批准。

GitLab

Merge Request:类似 GitHub PR,支持代码讨论和审批。

Merge Request 模板:提供 MR 模板,规范提交信息。

批准规则:设置最少批准人数,强制要求审查。

Gerrit

代码审查专用工具,精细化权限控制,适合大型项目。

变更集:每个提交都是独立的审查对象,审查通过后才能合并。

评分机制:审查者对变更打分(+2/-2),达到阈值才能合并。

审查文化

建设性反馈

关注代码:评论针对代码,而非开发者本人。

解释原因:说明为什么建议修改,帮助开发者成长。

承认不足:承认自己可能理解有误,保持讨论开放。

互信氛围

信任意图:相信开发者有良好意图,不是故意写出糟糕代码。

请教学习:遇到不确定的地方,以请教的态度提问,而非指责。

感谢贡献:审查结束时感谢开发者的贡献。

持续改进

审查复盘:定期讨论审查中发现的问题,总结共性问题和改进方向。

更新检查清单:根据项目演进更新审查检查清单。

优化流程:根据团队反馈调整审查流程,提高效率。

代码审查是保证代码质量和促进团队成长的重要实践,建立有效的代码审查文化需要工具、流程和文化的共同努力。