After years of being an engineer, I've realize that the code review process creates real productivity problems in our day-to-day development. Our mission to solve the problems through writing an impactful code could become delayed because of that.
Have you ever felt this? Or maybe you’ve seen a situation like this?
- You just made a pull request and are waiting for your peers to review your work, but your teammates are also busy with their tasks.
- While waiting, you move to a new task and after a few hours, your teammates have reviewed your code and they have some questions or comments, then you need to revisit your code to answer or fix them and request to review back again.
This situation above produces 2 problems: idle time for waiting review and cognitive load for switching contexts.
I believe code reviews are a vital process that helps to improve our code quality, prevent bugs, and share knowledge across the team. However, it could also be an annoying bottleneck for you and your teammates.
So, in this post, I’m motivated to share my experience addressing this problem specifically using Go Language.
Automate your code review
Imagine how good it would be if we had particular engineers working to do code reviews. Unfortunately, that’s not possible. The company won’t pay people to be code review engineers 😂 .
Instead of getting particular “engineers”, we can integrate “engine” to do so by automating the review process for common code review. Automated code review will quickly provide feedback for the code changes that are committed and pushed to your pull request.
To make that happen, we need to prepare these supporting tools:
- GitHub Action
GitHub Actions brings automation directly into the software development lifecycle on GitHub via event-driven triggers. These triggers are specified events, like creating a pull request. All GitHub Actions automations are handled via workflows, which are YAML files placed under the./github/workflowsdirectory in a repository that define automated processes. - Golangci-lint
Golangci-lint have bundles a large number of common linters into a single binary. Linting is the process of running static checks on the codebase to catch common mistakes and provide an automatically-enforceable set of best practices. - ReviewDog
Reviewdog provides a way to post review comments to code hosting services, such as GitHub, automatically by integrating with any linter tool with ease. It uses the output of lint tools and posts them as a comment if the findings are in diff of patches to review.
With these 3 supporting tools, we can run golangci-lint to lint our code changes when an event pull request on github action machine and when linter finds a problem, reviewdog will post a review comment on our pull request code changes. I think each of these tools is really awesome!!
Example the result look like
Under the above conditions, golangci-lint found a potential bug issue because the code tried to access the 5th index while the array was empty.An overview of how it works
How to set up this automated code review tool
We need to setup configuration by creating 2 configuration files for
- Files 1: github action workflows
- Files 2: golangci-lint
Files 1 directory: ./github/workflows/autocodereview.yml for github action workflows.
Every workflow consists of several different core concepts. These include:
- Events: Events are defined as triggers that kick off a workflow. They can be configured to look for one or more triggers and qualify as needed by a developer. They can also be set to run on specific coding branches within a given repository on GitHub. In this case, we set an event on “pull request” to the “main” branch.
- Jobs: Jobs are a set of steps that are executed on the same runner. Each runs in its own VM and in parallel to other jobs, unless otherwise specified. In this case, we use FreeRunner from GitHub using “latest-ubuntu”.
- Steps: Steps are individual tasks that run commands in a job can
be an action or a shell command. All steps in a job are executed on the same runner.
1. CheckoutV3: This action step checks-out your repository, so your workflow can access it.
2. ReviewDog: This action step to call reviewdog with golangci-lint as the linters.
Files 2 directory: ./golangci.yml for golangci-lint configuration
The configuration consists 2 basic configurations
- linter-settings: Sets option based on enable linters
- linters: Make sure disable-all is true (because enable-all is deprecated), and you can choose the list of enabled linters you want.
For more advanced configurations, please see their documentation here: https://golangci-lint.run/usage/configuration.
After all the configurations are in your repository, you can try it by making a pull request with code that violates the linter rules 🎉.
Demo Project
- Repository: https://github.com/Ardiannn08/sampleapp
- Sample PR Result: https://github.com/Ardiannn08/sampleapp/pull/6
Thank you for reading; I hope you found it useful and happy coding! ☕️
