37-AI 时代,代码评审方式究竟怎样优化?关键要点有哪些?
背景 在项目开发过程中,代码评审还是很重要的,主要是为了解决代码规范、功能开发方式、相互学习等问题,代码是否符合规范,关系到项目成员协作的问题。 如果写出来的代码风格五花八门,那么,在沟通交流上面,就额外增加了难度,而这是完全没有必要的。 除此之外,上面说到的功能开发方式问题,意思就是,每个人都有可能是孤岛,一个人的想法可能会有缺陷,如果多个人沟通以及探讨,相互学习,有可能会从不同视角发现潜在的问题。 人工代码评审 一直以来,我们要做项目代码评审,通常都是有这几种方式,比如项目组成员交叉验收各自的功能代码,然后把问题整理到文档,再一起组织代码评审会议,把问题都过一遍,然后安排任务去调整。一方面解决了代码存在的问题,另一方面通过深入交流,大家相互学习。 还有,就是在 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 会在每次新提交时分析您的代码,并在任何代码质量问题和安全问题上提醒您。然后,您可以立即解决这些问题,并确保添加到项目中的所有新代码始终是干净的。 ...