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Ā
Let's go.
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.
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Ā whenĀ andĀ whatĀ upfront to align expectations.
TheĀ whenĀ 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Ā
To communicate theĀ what, 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Ā
Small, laser-focused pull requests are the easiest to read. How small? Google Engineering Practices sayĀ
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Ā
AĀ
- 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.
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Ā
For me it has always been an amazing occasion to learn about domain knowledge. Take my PR inĀ
I read about a blog post titledĀ
What I found refreshing in his approach is thatĀ not acting on a pull request is not an option. 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.
To recap the best practices of pull request and code review to accelerate your development cycle
Also Published Here
Want to connect? This article was originally posted on Daw-Chihās website.