TL;DR 🏎 Learn how to accelerate the code review process to maximize your productivity 🔬 Learn the best practices I came across for code reviewers ✏️ Learn the best practices I came across for pull request authors Imagine this. You just implemented a feature and wrote all the test cases. You felt great about the code so you opened a pull request and let your coworkers know. After days passing by, your pull request looked exactly the same as before. Seemingly untouched. No comment. No change request. You asked your coworkers again for code review and they agreed. Another week went by and nothing happened. You asked again and they told you that they needed more time because it wasn't a small PR and there was a lot to take into consideration. Finally, you saw a notification about a change request and you jumped on it right away. After resolving merge conflicts and fixing the edge cases, you requested a review again, and waited. Another change request appeared after a few days and you repeated the process again. You got an approval after another revision and the PR was finally merged to the trunk. After 4 weeks since you opened the PR. If you can relate to it, you're not alone. Many teams experienced such a slow code review process. In fact, it's in the development cycle. So I want to share with you the best practices of code review I learned to speed up the development and help you ship code faster. one of the major blockers Let's go. For Pull Request Authors The number one thing I've learned to boost code review productivity is to be thoughtful as an author. Other than producing clean code, there are many small things you can do to help your reviewers understand your pull requests proactively. Be The Driver You, the author, are the driver of the pace. Knowing that you rely on your coworkers during the code review process, you can clearly communicate the and upfront to align expectations. when what The is the most important to communicate because it tells your reviewers how urgent it is. The reviewers can plan their work accordingly. It's a great way to set a for the review process, and it's also a great way to show respect to your coworkers' time. when timebox To communicate the , make sure you include a PR description that focuses on helping your reviewers understand the purpose and code design of your changes. Instead of listing functionalities, start with an opening paragraph explaining the background and why this PR is needed helps the reviewers to build their . Other descriptions I find very useful are: what mental models : a helps the reviewers to and react quickly to your pull request. Code design diagrams screenshot of your high-level code structure review the overall design : a list of simple sentences like helps the reviews look for missing functionalities and test cases. Acceptance Criteria "An acknowledgment email is sent to the user after submitting the form." Keep It Concise Small, laser-focused pull requests are the easiest to read. How small? Google Engineering Practices say . has shown that the code review quality decreases as the code change increases. The longer your reviewers review at a time, the less defects they catch. So it's important to keep your pull request small and focus on one thing. If the feature you're developing is too large, you can consider splitting it into multiple pull requests using the technique. "can't make it small enough" A study "stacked pull request" It replaces a large pull request with a sequence of small pull requests. It helps the reviewers to focus on one thing at the time and aligns brilliantly with the principal of . continuous integration and continuous delivery For Code Reviewers Be Mindful about Biases A found that pull request authors faced different levels of pushback that varied depending on the authors' demographics. According to data, they that study published by Google in 2022 found Women faced 21% higher odds of pushback than men Black+ developers faced 54% higher odds than White+ developers Latinx+ developers faced 15% higher odds than White+ developers Asian+ developers faced 42% higher odds than White+ developers Older developers faced higher odds of pushback than younger developers We should be more mindful about the unintentional biases, especially in a diverse workplace. By being aware of it, we can avoid unnecessary pushback in code reviews and help accelerate the process. It's A Great Place for Learning, Not Snob Regardless of your level of experience, working as a developer is about constant learning. Pull request is an invaluable "marketplace" for developers to communicate and exchange feedback. So make sure it's a place of respect and always . aim for knowledge sharing For me it has always been an amazing occasion to learn about domain knowledge. Take my PR in , I learned so much about from a member. If he was to dismiss my request , the teaching moment would have never exist. Airbnb JavaScript Style Guide ECMAScript Language Specification Ecma TC39 without constructive feedback Inaction Is Bad I read about a blog post titled by a tech lead at Instagram a year ago. He claimed that an effective code review consist of "Aggressive Code Review" decisive action ASAP aiming to reduce the cost of mistakes demanding small pull request and move fast What I found refreshing in his approach is that . It minimizes the lead time to review and it has been very beneficial to me and my team. We are able to ship fast because we take proactive actions to code review. We don't let pending pull requests linger and we review with our business cases in mind. not acting on a pull request is not an option Final Thoughts To recap the best practices of pull request and code review to accelerate your development cycle establish clear communication about the and of a pull request when what create small and self-contained pull request that focus on one thing be mindful about biases be respectful to the author and fellow reviewers take decisive review action as soon as possible References - Emerson Murphy-Hill, Ciera Jaspan, Carolyn Egelman, Lan Cheng The Pushback Effects of Race, Ethnicity, Gender, and Age in Code Review - Emerson Murphy-Hill, Research Scientist, Central Product Inclusion, Equity, and Accessibility Using research to make code review more equitable - SMARTBEAR Best Practices for Code Review - Google Small CLs - Dr. Michaela Greiler Stacked pull requests: make code reviews faster, easier, and more effective - Reddit Code reviews becoming a blocker - Reddit Code review bottleneck - Wikipedia Timeboxing - James Clear Mental Models: Learn How to Think Better and Gain a Mental Edge - GitHub AppLand extension for VSCode - Google What to look for in a code review - Nathan Donaldson https://www.boost.co.nz/blog/2010/09/acceptance-criteria - Daw-Chih Liou Ex-Principal Engineer's Guide to Design Thinking and Continuous Delivery - GitHub Add Class Private Identifier - Ecma International ECMAScript® 2023 Language Specification - GitHub Ecma TC39 - Reddit Getting ripped apart in code reviews, is this normal? - Bobi Aggressive Code Review - Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko. Google, Inc. Modern Code Review: A Case Study at Google Also Published Here Want to connect? This article was originally posted on . Daw-Chih’s website

AirBnB

Different

Google

Instagram

Keep

Mind

2022 - HackerNoon Contributor of the Year - Leadership

2022 - HackerNoon Contributor of the Year - Learning

2022 - HackerNoon Contributor of the Year - Product Management

2022 - HackerNoon Contributor of the Year - Software Engineering

2022 - HackerNoon Contributor of the Year - Typescript

Coding Guru of 2022

Check out my website!

Nominated for 2022 - HackerNoon Contributor of the Year - Product Management

Nominated for 2022 - HackerNoon Contributor of the Year - Typescript

Nominated for 2022 - HackerNoon Contributor of the Year - Leadership

Nominated for 2022 - HackerNoon Contributor of the Year - Software Engineering

Nominated for Coding Guru of 2022

Nominated for 2022 - HackerNoon Contributor of the Year - Learning

Too Long; Didn't Read

Get free API security automated scan in minutes

What to do When You're Tired of Slow Code Reviews

What to do When You're Tired of Slow Code Reviews

Too Long; Didn't Read

People Mentioned

Companies Mentioned

@dawchihliou

RELATED STORIES