4 篇博文 含有标签「静态检查」

Reviewbot 是七牛云开源的一个项目，旨在提供一个自托管的代码审查服务, 方便做 code review/静态检查, 以及自定义工程规范的落地。

在日常的编程协作中，Git commit 记录的质量往往反映了一个工程师的工程素养。然而，我经常能看到一些不太规范的 commit 记录。有时，真的不敢恭维。

比如这种:

这种大概率是提交 commit 之后，又有变动，就随手重新复用上一条 git commit 命令了。

这种记录如果出现在个人仓库，可能还好. 但如果是多人协作的仓库，就有点不专业了。

在我看来，这些 commit 记录完全没必要，是非常不好的习惯，完全可以避免。

好在 Git 为我们提供了优雅的解决方案。如果没必要生成新的 commit，那直接使用 git commit --amend 就可以避免。

少用 git merge 多用 git rebase​

比如这种:

Merge branch 'feature-A' of https://github.com/qiniu/reviewbot into feature-B

说的是把远程分支 feature-A 的代码合并到 feature-B 里。这里的 feature-A 通常是主分支。

这种 Commit 信息如果出现在你的 PR 里，那是完全没必要。PR 里的 commit 信息应当仅包含针对本次改动的有用信息。

我个人日常几乎不使用 git merge，即使是为了同步远程分支，我一般都会使用 git rebase。

比如:

git rebase 除了上述好处外，还可以保持主仓库的 commit history 非常干净。所以强烈推荐大家使用。

Reviewbot 的 git commit check​

为了更好的规范上述两种行为，Reviewbot 也添加了 git commit check 能力，就是用来检查 git commit 记录是否符合规范的。

如果不符合规范，Reviewbot 就会提示你:

更多 git flow 使用规范和技巧​

当然 git 操作其实有很多实用技巧，建议大家有兴趣的话可以去研究下。我在 1024 实训营的时候，有给同学们做个相关分享:

超实用! 从使用视角的 Git 协作实战，告别死记硬背 。

文档里面有视频链接，感兴趣的同学可以去看下。

最后，作为专业的工程师，我们应该始终追求卓越的工程实践。良好的 commit 记录不仅体现了个人的专业素养，更是提升团队协作效率的重要基石。

通过合理使用 git rebase 和 git commit --amend，我们可以维护一个更清晰、更专业的代码提交历史。这不仅让代码审查变得更加轻松，也为后续的代码维护和问题追踪带来极大便利。

你觉得呢？

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 问题的分布及修复情况，又该怎么办呢？

如何解决，方向在哪里？​

不可否认，linter 问题也是问题，如果每行代码都能进行充分的 lint 检查，那一定比不检查要强。

另一方面，组织内制定好的工程规范，落地在日常的开发流程中，那一定是希望被遵守的，这类就是强需。

所以这个事情值得做，但做的方式是值得思考的，尤其是当我们有更高追求时。

参考 CodeCov 的服务方式，以及 golangci-lint reviewdog 等工具的设计理念，我们认为:

• 如果能对于新增仓库、历史仓库，不需要专人配置 job，就能自动生效，那一定是优雅的
• 如果能只针对 PR/MR 中的变动做分析和反馈，类似我们做 Code Review 那样，那对于提 PR 的同学来讲一定是优雅的，可接受的，随手修复的可能性极大
  • 而进一步，针对 PR/MR 中涉及的文件中的历史代码进行反馈，在合理推动下，支持夹带修改，持续改进的可能性也会大大增强
• Lint 工具多种多样，或者我们自己开发出新工具时，能够较为轻松的让所有仓库都自动生效，那也一定是非常赞的，不然就可能陷入工具越多负担越重的风险

基于上面的思考，我认为我们需要的是: 一个中心化的 Code Review/静态检查服务，它能自动接受整个组织内 PR/MR 事件，然后执行各种预定义的检查，并给与精确到变动代码行的有效反馈。它要能作为代码门禁，持续的保障入库代码质量。

而 Reviewbot 就是这样一个项目。

Reviewbot 在设计和实现上有哪些特点？​

面向改进的反馈方式

这将是 Reviewbot 反馈问题的核心方式，它会尽可能充分利用各 Git 平台的自身能力，精确到变动的代码行，提供最佳的反馈体验。

• Github Check Run (Annotations)
• Github Pull Request Review (Comments)

支持多种 Runner

Reviewbot 是自托管的服务，推荐大家在企业内自行部署，这样对私有代码更友好。

Reviewbot 自身更像个管理服务，不限制部署方式。而对于任务的执行，它支持多种 Runner，以满足不同的需求。比如:

• 不同的仓库和 linter 工具，可能需要不同的基础环境，这时候你就可以将相关的环境做成 docker 镜像，直接通过 docker 来执行
• 而当任务较多时，为了执行效率，也可以选择通过 kubernetes 集群来执行任务。

使用也很简单，在配置文件中的目标仓库指定即可。类似:

dockerAsRunner:
  image: "aslan-spock-register.qiniu.io/reviewbot/base:go1.22.3-gocilint.1.59.1"

kubernetesAsRunner:
  image: "aslan-spock-register.qiniu.io/reviewbot/base:go1.23.2-gocilint.1.61.0"
  namespace: "reviewbot"

零配置+定制化

本质上，Reviewbot 也是个 webhook 服务，所以我们只需要在 git provider 平台配置好 Reviewbot 的回调地址即可(github 也可以是 Github App)。

绝大部分的 linter 的默认最佳执行姿势都已经固定到代码中，如无特殊，不需要额外配置就能对所有仓库生效。

而如果仓库需要特殊对待，那就可以通过配置来调整。

类似:

org/repo:
  linters:
    golangci-lint:
      enable: true
      dockerAsRunner:
        image: "aslan-spock-register.qiniu.io/reviewbot/base:go1.22.3-gocilint.1.59.1"
      command:
        - "/bin/sh"
        - "-c"
        - "--"
      args:
        - |
          source env.sh
          export GO111MODULE=auto
          go mod tidy
          golangci-lint run --timeout=10m0s --allow-parallel-runners=true --print-issued-lines=false --out-format=line-number >> $ARTIFACT/lint.log 2>&1

可观察

Reviewbot 是在对工程规范强管理的背景下产生的，那作为工程规范的推动方，我们自然有需求想了解组织内当前规范的执行情况。比如, 都有哪些问题被检出？哪些仓库的问题最多？哪些仓库需要特殊配置？

目前 Reviewbot 支持通过企业微信来接收通知，比如:

• 检出有效问题

• 遇到错误

当然，未来可能也会支持更多方式。

其他更多的功能和姿势，请参考仓库: https://github.com/qiniu/reviewbot

Reviewbot 的未来规划​

作为开源项目，Reviewbot 还需要解决很多可用性和易用性问题，以提升用户体验，比如最典型的，接入更多的 git provider(gitlab/gitee 等)，支持 CLI 模式运行。

但我个人认为，作为 code review 服务，提供更多的检测能力，才是重中之重。因为这不光是行业需求，也是我们自身需要。

所以后面我们除了会引入七牛内部推荐的规范，也会调研和探索更多的行业工具，同时会考虑引入 AI，探索 AI 在 code review 中的应用等等。

Anyway，Reviewbot 还很年轻，我们在持续的改进中，非常欢迎大家试用并提出宝贵意见。当然，更欢迎大家一起参与到项目建设中来。

为了方便沟通，我建了 微信 和 QQ 群，欢迎大家扫码加入，一起交流。

感谢大家。

Looking to build a self-hosted code review service? Try Reviewbot, now open-sourced!

When do you need a self-hosted code review service?​

You might need one when:

• You have many repos but still want tight control over code quality
• Your repos are private, and commercial services seem overkill
• You want to continuously improve the process and rules, with full customization

Benefits of a self-hosted code review service​

While many linter tools and engineering practices exist, they're often underutilized:

• Powerful tools like golangci-lint (with 100+ integrated linters) are often used with default settings, ignoring most features
• Linter outputs get buried in logs, making issue-finding a chore
• Configuring CLI-based linters for multiple repos is tedious, especially for ongoing improvements
• Monitoring code quality across repos can be daunting

A self-hosted service can automate all this. As a DevOps or QA team member, you can easily centralize control, monitoring, and customization of code quality across all repos.

Enter Reviewbot - your solution for self-hosted code review.

What can Reviewbot do?​

Reviewbot helps you quickly set up a self-hosted code analysis and review service, supporting multiple languages and coding standards. It's perfect for organizations with numerous private repos.

Issues are reported during Pull Requests as Review Comments or Github Annotations, pinpointing exact code lines.

• Github Check Run (Annotations)

  

• Github Pull Request Review Comments

  

This approach saves PR authors from sifting through lengthy logs, streamlining problem-solving.

Reviewbot's Design Philosophy​

Focused on:

• Security - Self-hosting for data control
• Improvement-Oriented - Issues reported as Review Comments or Github Annotations for easy fixes
• Flexibility - Multi-language support with easy tool integration
• Observability - Alert notifications for timely issue awareness
• Configurable - Customizable linter commands, parameters, and environments

Built with Golang, Reviewbot boasts simple logic and clear code for easy maintenance.

Main Flow​

Reviewbot primarily operates as a GitHub Webhook/App service, accepting GitHub Events, executing various checks, and providing precise feedback on the corresponding code if issues are detected.

Github Event -> Reviewbot -> Execute Linter -> Provide Feedback

And you can easily Add a New Linter or do Customization.

Monitoring Detection Results​

Reviewbot supports notification of detection results through WeWork (企业微信) alerts.

If unexpected output is encountered, notifications will also be sent, like this:

More​

Check out Reviewbot. Feel free to have a try.

Btw, this article is also published on medium website.

Stay tuned for more updates!

为什么要谈这个 topic？​

实践中，质量保障体系的建设，主要针对两个目标: 一是不断提高目标业务测试覆盖率，保障面向客户的产品质量；二就是尽可能的提高人效，增强迭代效率。而构建全链路质量卡点就是整个体系建设的核心手段。笔者用下图来描述这整个链路:

可以看到，虽然保障业务迭代的方向性正确排在最前面，但在具体操作上，这一步需要的是强化流程规范和构建企业文化，同时对各负责人技能培训，可以说多数是软技能。而保障基础代码质量环节发力于自动化建设链路之始，是可以通过技术手段来消灭潜在的质量问题，所以构建好的话能极大的降低心智负担，非常值得关注。

我们都知道，代码的好坏会直接影响到业务质量，团队协作，以及后期技术债等。有一个经典的图来描述代码质量的好坏，当能深切表达程序员的内心:

而同时我们相信，绝大部分程序员都有追求卓越的初心，且会尽可能的在自己能力范围内编写高质量的代码。

但是，保障基础代码质量光靠程序员的个人素质一定是不全面，是人就会犯错，可能会疏忽。我们最需要的是一种自动化的机制来持续确保不出问题。这也是自动化的魅力，一次构建，持续收获价值。

此类工具在业界一般叫 linter，不同的语言有不同的实现。本文主要探究 Go 语言相关的。 在介绍相关工具之前，我们先看看几个经典的代码坏味道: 这段代码常规运行不会有问题，但是在一些场景下循环执行，那可能就会有问题了, 我们来看看: (注:ex2 是上述代码编译出的可执行文件名字)

很明显，有句柄泄露。原因也很简单，http response 的 body 没有关闭。但这个关闭语句，一不注意也容易写错：

这时候如果百度挂了，上述程序程序就会因为空指针引用，造成非预期的 panic，非常的不优雅。所以正确的做法应该是在 err 判断之后再行关闭 body(关于 Client.Do 具体的各种限制，大家可以参考这里: https://golang.org/pkg/net/http/#Client.Do)

如此种种，此类小问题在实际编码活动中非常常见，且不容易一眼看出问题。甚至常规的测试可能也难检测出来，可谓非常棘手。好在 Go 语言的开发者们为我们想到了这一点，内置工具链中的 vet 命令，就能方便的检测到很多类似的问题。

还比如下面的代码场景，我在实际的测试用例和业务代码都看到过：

go vet 可以很容易检测出这个问题(其他 vet 功能，可以参考这里: https://golang.org/cmd/vet/)。

go 的工具链中，还有一个不得不提，那就是大名鼎鼎的 go fmt，其了却了其他语言经常陷入的代码风格之争，是 Go 语言生态构建非常巧妙的地方。另外 golint 也是 google 主推的 go 语言代码代码风格工具，虽非强制，但强烈建议新项目适用。

Go linters 业界现状​

上面主要说到 Go 工具链的内置工具，还有一些非官方的工具也比较有名，比如 staticcheck, errcheck在 github 上 Star 都较多。此类工具有个专门的的 github 库，收集的比较全，参见 awesone-static-analysis

同时还有些项目旨在聚合此类工具，提供更方便的使用方式，以及一些酷炫的产品化。比如golangci-lint, 其衍生的商业化项目，可以自动针对 github PR 做代码审核，对有问题的地方自动 comments，比较有意思。

如何才能优雅的落地 linter 检查？​

linter 工具必须为产品质量服务，不然就是做无用功。实践中，我们应该思考的是如何才能优雅的落地 linter 检查，如何才能建立有效的质量卡点。

推荐针对 PR，做代码检查，保障入库代码质量。基于 PR 做事情是我比较看好的，因为这是调动所有研发力量，天然契合的地方。且进一步讲，这也是测试基础设施更能体现价值的地方。

目前 Github 上有很多这方面的集成系统做的都比较好，能够快速的帮我们落地 PR 测的检查，比如 Travis, Circle CI 等。另外就是著名的 Kubernetes 社区，也自行构建了强大的 Prow 系统，其不光是基于 CICD 系统，还构建了 chat ops 模式，为参与 Kubernetes 的社区的贡献者提供了方便。

细看 Kubernetes 库，会发现，其会针对每个 PR 都做如下静态检查:

• gofmt： https://github.com/kubernetes/kubernetes/blob/master/hack/verify-gofmt.sh
• govet: https://github.com/kubernetes/kubernetes/blob/master/hack/make-rules/vet.sh
• golint: https://github.com/kubernetes/kubernetes/blob/master/hack/verify-golint.sh 因为 golint 只是纠正代码风格，并不是强制，所以 k8s 官方就弄了比较软的方案，对于当前已经存在的代码如果有问题，先排除掉(如下)。对于新生代码，如果检查失败，ci 就挂掉。 https://github.com/kubernetes/kubernetes/blob/master/hack/.golint_failures

Kubernetes 只利用了官方的几款工具, 在检测准确性上比较有保障。有了这些检查点，也能倒逼研发人员关注提交代码的质量，会迫使其在本地或者 IDE 上就配置好检查，确保每次提交的 PR 都能通过检查，不浪费 CI 资源。这也是合格工程师的基本要求。

总结​

高质量的代码是业务质量保障的基础。而编写高质量的代码是技术问题，同时也应该是企业文化问题。因为当大家都开始注重技术，注重代码质量时，自然会朝着精益求精的路上行进，视糟糕的代码为仇寇。

我的一位老板跟我说过，要做就做 Number One。而在没达到第一的时候，那就要向业界标杆看齐，比如 Netflix，Google，Facebook 等。当大家都非常注重自己代码质量时，工程师才有时间去关注解决更加系统性的问题，而不用一直在 Low Level 徘徊。笔者深以为然。