͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏

Forwarded this email? Subscribe here for more

You are now 161,001+ subscribers strong.

Let’s try to reach 162k subscribers by 30 July.

Share this post & I'll send you some rewards for the referrals.

How to Scale Code Reviews 🔥

#78: How Great Software Engineers Do Code Reviews (4 Minutes)

Neo Kim

Jul 25

READ IN APP

Get my system design playbook for FREE on newsletter signup:

This post outlines tips for reviewing code. You will find references at the bottom of this page if you want to go deeper.

Share this post & I'll send you some rewards for the referrals.

Once upon a time, there was a 2-person startup.

Yet they had a tiny website and only a few customers.

So they merged the code directly into the main branch.

But one morning, their site became extremely popular.

And the number of customers and feature requests started to skyrocket.

So they hired more developers and implemented extra features.

Yet each developer wrote code with their personal preferences.

Thus worsening the code quality and standards. Also increasing the number of bugs.

So they started doing code reviews before merging new code into the codebase.

A code review means someone other than the author reviews the code.

Although it temporarily solved their code quality problem, there were newer issues.

Here are some of them:

1. Developer Velocity

They followed a strict review process and spent time on minor issues.

Put simply, they asked for low-priority changes on a tight deadline ticket.

It means delayed pull requests and slow developer velocity¹.

Besides having teams across different time zones worsened the situation.

2. Personal Conflict

They didn’t have set guidelines for code reviews.

So developers forced their personal preferences during reviews.

It means unnecessary disagreements and demotivated developers.

Also feedback with a toxic and mean tone made things worse.

3. Miscommunication

There’s a risk of misunderstanding feedback in remote or asynchronous reviews.

Also a reviewer must understand new code and how it works with the codebase.

So the reviewer might get overloaded with code reviews and parallel development tasks.

Besides the reviewers might miss bugs even with thorough reviews, especially in large pull requests.

Onward.

I’m happy to partner with CodeRabbit on this newsletter. I’ve seen code reviews delaying feature deliveries by days and overloading reviewers. I genuinely believe CodeRabbit solves this problem.

Try CodeRabbit

How to Do Code Review

Let’s dive in:

1. Best Practices

Both the author and the reviewer should respect each other’s time and efforts.

Here are some guidelines for the code author:

Follow the project's style guide².
Keep the changes small to make the reviews easy.
Review the code yourself before asking others to save time.
Use existing code patterns, and not personal preferences, if a style is unspecified.
Tag only the fewest number of reviewers to save everyone’s time.
Write a clear message about the changes for the reviewer to understand easily.
Use facts and data to resolve design debates, rather than opinions.

Code reviews are each software engineer's responsibility.

Here are some guidelines for the reviewer:

Respond to a review request within 24 hours.
Reserve at least one calendar slot each day for code reviews.
Keep the reviews polite and constructive; don’t criticize the author.
Document common review points and use a review checklist for consistent reviews.
Discuss the issue directly with the author when there’s a disagreement. Then document the solution for future reference.
Share the documentation in review comments if necessary to encourage knowledge sharing.
Approve the pull request when it’s good enough and allow minor issues to be fixed later.

Remember, code reviews are about making progress and not perfection. So just make sure each change maintains or improves the codebase's health.

Let’s keep going!

2. Code Review Flow

Version control platforms, such as GitHub and GitLab, include pull request features for code review. They allow inline comments, approvals, and automated checks. Also there is peer review software, such as Gerrit, for advanced workflows.

Here’s the code review workflow from a developer perspective:

Pull Request
- Write code on a separate Git branch to isolate changes.
CodeRabbit Giving Instant Feedback
- Get instant feedback and fix suggestions with code editor extensions, such as CodeRabbit. Thus catching problems even before creating a pull request³ and saving infrastructure resources.
- Commit code with a clear commit message and push it to the remote repository.
- Open a pull request from the current branch to the target branch.
Continuous Integration
- Run automated checks on the code, such as unit tests, static code analysis⁴, security scans, and linting⁵, to ensure code correctness. It finds style issues, code smells, or security vulnerabilities, so reviewers can focus on high-level feedback.
CodeRabbit Finding Potential Issues
- Find issues and get auto-fix suggestions using CodeRabbit. This approach improves developer velocity.
Code Review
- Tag one or more relevant team members to ask for review.
  CodeRabbit Summarizing Changes
- Generate a summary of code changes using CodeRabbit. It helps reviewers understand complex changes quickly. And assess the impact on the codebase.
- The reviewer checks the changed files and leaves constructive feedback via comments.
Code Update
- Fix the code based on the reviewer’s comments.
- Upload changes to the same pull request and make sure automated checks pass again.
- Reply to the reviewer's feedback and resolve comments.
Deploy
- At least one reviewer approves the pull request.
- Merge the pull request into the target branch and trigger continuous deployment (CD).
- CD pipeline builds and deploys the change to the staging environment.
- Once the staging tests pass, the change gets released to production.

Continuous integration means merging code changes regularly into a central repository. While Continuous deployment is about automatically releasing changes that pass checks into production.

CodeRabbit is an AI code review tool to reduce developer workload.

Here’s how it helps with code review flow:

Do routine checks and reduce the time spent on reviews from days to minutes. Thus improving developer velocity.
Do consistent reviews without getting tired or biased. Thus reducing the risk of missing important issues from human mistakes.
Provide mentorship to junior engineers through detailed feedback.

Put simply, CodeRabbit complements human reviewers. It serves 1+ million repositories and has reviewed over 10 million pull requests. And it remains the most installed app on GitHub and GitLab.

Subscribe to get simplified case studies delivered straight to your inbox:

Author Neo Kim; System design case studies — **Find me on LinkedIn | Twitter | Threads | Instagram**

Want to advertise in this newsletter? 📰

If your company wants to reach a 160K+ tech audience, advertise with me.

Thank you for supporting this newsletter.

You are now 161,001+ readers strong, very close to 162k. Let’s try to get 162k readers by 30 July. Consider sharing this post with your friends and get rewards.

Y’all are the best.

References

Speed and efficiency of delivering high-quality software.

Rules for writing clean, consistent, readable code.

Proposal for merging code changes into the main branch.

Checks code for errors, bugs, and style issues without running it.

Checks code for style errors and formatting issues.

Share this post & I'll send you some rewards for the referrals.

Comment

Restack