DEV Community

Cover image for 7 Ways to Dramatically Reduce Your Time in Code Review

7 Ways to Dramatically Reduce Your Time in Code Review

Tyler Hawkins on July 11, 2022

Code reviews can be painful. Software engineers often complain that the review process is slow, delays downstream tasks, and leads to context switc...
Collapse
 
brense profile image
Rense Bakker

Hi Tyler, I recently listened to a podcast you were in from React Roundup :D

Fully agree with your list of best practices for speeding up code reviews. I havent personally used PR review apps yet, so I will give that a try!

As a side note, I find that internal PR response time also has to depend on what kind of branching strategy a team is using. For example, with some branching strategies you get a lot of merge conflicts if a PR is open for too long. Obviously we'd want to change the branching strategy to something more sensible, but unfortunately it's not always possible to convince the team :(

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thanks Rense! That's awesome you heard the React Round Up podcast interview.

PR review apps are amazing! I'd highly recommend using them. There are plenty of good options depending on your codebase's infrastructure, but I've used review apps with Heroku, GitLab, and Render in the past, and they've all been great.

That's a great callout on the branching strategy. Long-lived feature branches are the worst, exactly for the reason you outlined: merge conflicts. I'm a big fan of using trunk-based development and merging often to reduce the amount of conflicts that build up over time. Feature flags help a bunch with that since you can merge code into the master branch even before it's ready to be enabled in production.

Thanks for reading and for your comment!

Collapse
 
brense profile image
Rense Bakker

Hmm I'm still working on understanding how trunk based strategy is supposed to work, i come from gitflow myself. Any articles you could recommend?

Thread Thread
 
damian_cyrus profile image
Damian Cyrus

Here is something about trunk based strategy: trunkbaseddevelopment.com/

It is quite frightened at the beginning, but it is also a great experience for the future.

Thread Thread
 
thawkin3 profile image
Tyler Hawkins

This is a great resource from Atlassian as well, and they cover some of the differences between trunk-based development and Gitflow: atlassian.com/continuous-delivery/...

I hope this helps!

Collapse
 
damian_cyrus profile image
Damian Cyrus

I agree on all the points, as experienced this myself.

1: Keep Pull Requests Small

Communicating in some cases is also a very important part. It could also be included in the description of a comment/ticket/whatever you use to communicate.

This is quite interesting how some see "small" like:

The PR has only moved a component to another one place, updated 400 files because of path updates.
Nothing more. Honestly.

OK, the description is bad, but that helps a lot to speed up the process (with trusting the developer) rather than wast time checking all 400 files. In combination with #6: The pipeline will do a check if the path is fine, so no need to look into more than needed.

Collapse
 
thawkin3 profile image
Tyler Hawkins

Great callout! I love leaving little annotations on my own PRs to help my reviewers navigate the PR. Things like an updated file path or formatting changes are great to highlight so reviewers know which pieces are important to look at and which aren't (assuming they trust the code author!).

Collapse
 
jsuddsjr profile image
John Sudds

I have also noticed that PRs created from pair programming sessions also tend to take less time, since much of the architecture discussion happened as the code was written.

You can also use a shared .editorconfig and git hooks to verify linting is done before any files show up in the PR. Verifying in the CI pipeline is also good, but a little too late in the process for my taste. I want to know right away when I've wandered from the team's style guidelines.

Collapse
 
elsyng profile image
Ellis • Edited

My advice -- review immediately, approve immediately.

  1. Give PR's the highest prio.
  2. Leave your suggestions, but approve the PR immediately and automatically. Then leave it to the other person, don't check it, don't chase. Just forget about it.
Collapse
 
amabe_dev profile image
amabe_dev

Going side by side with

1: Keep Pull Requests Small

I recently heard about stacking pull requests. (On episode 491 of The Changelog).

I find it to be great to make small pull requests without being blocked while waiting for everyone to review everything. This way we can tell a story with pull requests that add to one another.

This is a bit harder to manage without tooling but way easier as a reviewer. And it make it possible to have feedback earlier when working on a big feature.

Collapse
 
alexdesi profile image
Alessandro De Simone

Nice tips, thanks!
Another simple way to speed up PR review is just to ping people: "Hey Tom can you please have a look to my PR?"
Simple but effective :)

Collapse
 
shshank profile image
Shshank

I agree on all the points. Thank you for sharing for informative post.

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thanks for reading!

Collapse
 
leob profile image
leob

"Keep pull requests small" (I would say 'manageable') is my number one ... and, add a good and helpful description to the PR would be my number 2.