背景

在项目开发过程中，代码评审还是很重要的，主要是为了解决代码规范、功能开发方式、相互学习等问题，代码是否符合规范，关系到项目成员协作的问题。

如果写出来的代码风格五花八门，那么，在沟通交流上面，就额外增加了难度，而这是完全没有必要的。

除此之外，上面说到的功能开发方式问题，意思就是，每个人都有可能是孤岛，一个人的想法可能会有缺陷，如果多个人沟通以及探讨，相互学习，有可能会从不同视角发现潜在的问题。

人工代码评审

一直以来，我们要做项目代码评审，通常都是有这几种方式，比如项目组成员交叉验收各自的功能代码，然后把问题整理到文档，再一起组织代码评审会议，把问题都过一遍，然后安排任务去调整。一方面解决了代码存在的问题，另一方面通过深入交流，大家相互学习。

还有，就是在 GitLab 代码合并阶段，项目成员发起功能分支合并至主分支，由项目负责人去审查项目成员提交的代码分支。

如果没有问题，则合并到主分支；如果有问题，则反馈给项目成员。待项目成员修复完成再次发起分支代码合并，然后，项目负责人确认之后，合并到主分支。这个应该就是常规的代码评审流程。

但是，随着团队的发展以及对降本增效的要求，开始着手去研究，团队中哪些工作是有可优化的空间？

项目负责人承担的工作事务越来越多，怎么去有效简化无意义的工作，成为了当前亟需解决的问题。

SonarQube

基于上面降本增效的目的，我之前调研了 SonarQube 代码检测工具。

它基本支持了市面上的 Java、Go、JavaScript、TypeScript 等十多种语言，并提供几千条代码规则，用于代码规范检查、代码优化提示等代码质量问题。

支持结合 GitLab 的 CI/CD 做流水线事件中断，方便代码提交人员，自行去查看反馈的问题。

并且，提供 SonarLint 这个 IDE 插件，在代码编写时，就反馈存在的问题，并给出修改建议。

后来为了减少项目负责人的代码评审工作，整个部门的项目，就都接入了 SonarQube 来实现代码问题检查工作。

在使用 SonarQube 的过程中，给我印象深刻的主要有以下几点：

如果一个历史项目要接入使用 SonarQube 工具去检查代码，这个时候，势必会有很多问题反馈，比如可能 2000 个问题，这个时候，是否要立马安排时间去解决呢？

立马安排的话，就需要比较多的时间了，如果不立马安排解决的话，这些问题应该什么时候去解决呢？

SonarQube 提出了一个 “新代码” 的概念了，意思就是，可以不立即就把这 2000 个问题修复掉，而是在项目功能迭代的过程中，逐步把有问题的代码修复掉。

因为项目功能有迭代，意味着，这部分代码就需要去改动，趁此机会，刚好同步解决掉遗留的代码问题，慢慢地，遗留的 2000 个问题就会以这种方式解决掉。

至于哪些没有迭代的，说明功能已经很稳定了，或者功能不重要，那优先级也相对更低了。

SonarQube 官网文档的这篇说明 《Clean as You Code》 提出的这个方法论，我觉得理念还是很不错的：

SonarQube 旨在通过帮助您（开发人员）确保您提交到项目中的每个代码更改都没有问题，从而确保高代码质量和安全性。通过始终提交干净的代码，您可以逐步提高项目的整体质量。我们称这种方法为“Clean as You Code”。

Clean as You Code 的核心思想是将注意力和精力集中在新代码上。在您进行功能和改进时，SonarQube 会在每次新提交时分析您的代码，并在任何代码质量问题和安全问题上提醒您。然后，您可以立即解决这些问题，并确保添加到项目中的所有新代码始终是干净的。

传统的代码质量方法通常强调在每个开发周期结束时有一个单独的审查阶段，在这个阶段发现并解决质量问题。在这个过程中有一个单独的阶段，通常由不同的团队进行，可能会导致问题，因为积累的技术债务量可能变得难以管理，而责任的划分意味着质量问题可能会从裂缝中消失。

Clean as You Code 避免了这些陷阱。它阐明了代码质量和代码安全性是您作为开发人员的责任。它还通过使其成为日常工作节奏的一部分，使代码质量的维护保持可控。

另一个让我印象深刻的是 SonarQube 代码检测结合 CI/CD 阻断流水线事件的功能，真正去应用了，才真正感受到这个功能的好处在哪里，比如前端项目，要合并分支并自动化发布到线上，这个时候，如果 SonarQube 检测到代码问题，就会中断发布流程，需要解决掉反馈的代码问题，才可以正常发布到线上，从而简化了项目负责人的代码评审工作。

但是，SonarQube 只是静态的代码检查，固定好规则，然后它就去检查，只是一个相对 “死板” 的检查方式，无法结合代码上下文，去提出更为深层次的问题，比如功能的实现方式，代码性能优化的写法建议等等，还是要人工去做这部分的工作。

AI 代码评审

随着 AI 大模型的爆发，我之前设想的通过 AI 去做代码评审的事情，开始可以去落实。

早在选定 SonarQube 作为代码评审检查工具，从而减少项目负责人的工作之时，我就设想能否通过 ChatGPT 来完成这个事情，这个是之前写的结论。

借助 ChatGPT，利用 GitLab 获取到合并请求内容并发送到 ChatGPT 完成代码审查, 并将审查结果提交评论至修改行。当前环境下，该做法可能有点激进，存在法律和安全方面的风险。时机未成熟。

当时是没想明白，怎么解决掉代码安全的问题，因为我们项目的代码，总不能接入公网吧，而且，GhatGPT 还是外网，还要翻墙，还要购买服务等等问题，就此作罢了。

可现在完全不同了，AI 大模型发展迅速，日新月变，全面开花。在这样的背景下，我知道时机应该成熟了。

我的想法是，能够通过 AI 把项目成员自己提交的代码分支，做一次代码评审，然后将代码中存在的问题反馈给项目成员，项目成员自行根据建议修复之后，再次推送分支，这一个过程完全不需要项目负责人参与。

项目负责人只需要在最后一步，合并分支代码的时候，看下 AI 代码评审报告，确定各方面评价满足预期，则合并分支代码，从而简化项目负责人的工作。

后来通过多次调研，发现 Code-Review-GPT-Gitlab 这个项目比较符合预期，有评分、代码亮点、代码问题、修改建议、修改后的版本等等，就开始着手验证和执行。

不过，当前还有一个点要解决，因为这个评论是需要合并分支代码之后，才可以检查 diff 部分的代码，然后结合上下文，给出代码检查报告的，那么就没有做到阻断事件的效果了。

之前，总认为把这个约束放到人身上，大家自行去看合并后的分支报告就行了，不做强制要求。

但是，这种事情，是没办法去考验人性的，要大家自觉去做，可能一开始还行，时间久了，有什么突发事情、工作进度受阻、准备下班了等等原因，就开始趋利避害了。这个是正常的，所以，只能从源头去解决，那就是完善这个阻断事件的功能。

总结

上面就是代码评审的方式以及演变过程，不过，在实际应用中，AI 代码评审也不是万能的，除非你能把它喂到覆盖你需求的程度，但是，现阶段还是比较难的。

所以，最好还是结合代码评审会议去完善代码评审这个事情，比如一个季度开一次，都看看项目的代码，兴许可以发现一些 AI 代码评审覆盖不到的、团队特有的代码规范、功能实现方式可优化等问题。

在当下降本增效的浪潮之下，强调团队的产出，基于这个目的，各个工作环节，都要深入去分析，是否存在可以优化的要点，通过结合实际情况的分析与论证，比如，先以一个项目作为试点，看看大家的反馈如何，没有什么问题，再全面推进，再加以实施，更能做成一件事情，避免弄得载声怨道，事与愿违。