Reviewbot 开源 | 为什么我们要打造自己的代码审查服务?
Reviewbot 是七牛云开源的一个项目,旨在提供一个自托管的代码审查服务, 方便做 code review/静态检查, 以及自定义工程规范的落地。
静态检查不是个新鲜事。
我记得早在几年前,我们就调研并使用过 sonarqube 做静态检查,但当时并没有大范围的推广。主要原因在于,一是发现的问题多数是风格问题,较少能发现缺陷; 二是 sonarqube 社区版的 worker 数有限制,满足不了我们大规模代码扫描的需求。当然,也是因为前一个问题,感觉付费并不是很划算。
而由于七牛主要使用 golang 语言,所以在静态检查方面,我们基本使用 go vet/fmt/lint 等,再就是后来的 golangci-lint,好像也够用了。
但随着代码仓库的增多,以及对工程规范的不断强化,我们越来越发现当前的落地方式,已经开始无法满足我们的需求。
Linter 工具的引入与更新问题
以 golangci-lint 为例,其是 go 语言 linters 聚合器,内置了 100+ linters,使用也很简单, golangci-lint run
一条命令即可。但你知道吗?如果没有特殊配置,你这条命令其实仅仅执行其中的 6 个 linter,绝大部分 linters 都没有执行!
另外,工具本身需要更新,且很多时候我们也会自己定制 linter 工具,这种时候该怎么做呢?如果仅有少量仓库,可能还好,但如果仓库很多,那维护成本就上去了。
还有就是新业务,新仓库,如何保证相关的检查能够及时配置,相关的规范能够正确落地?
靠自觉一定是不行的。
Linter 问题的发现与修复情况
如何确保发现的问题能够被及时修复?如何让问题能更及时、更容易的被修复?
埋藏在大量 raw log 中的问题,一定是不容易被发现的,查找起来很麻烦,体验很差。
历史代码仓库的存量问题,谁来改?改动就需要时间,但实际上很多业务研发可能并没有动力来跟进。同样,变动总是有风险的,有些 lint 问题修复起来也并不简单,如果因修复 lint 问题而引入风险,那就得不偿失了。
如果想了解当前组织内 lint 问题的分布及修复情况,又该怎么办呢?