Code reviews can be painful. Software engineers often complain that the review process is slow, delays downstream tasks, and leads to context switc...
For further actions, you may consider blocking this person and/or reporting abuse
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 :(
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!
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?
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.
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!
I agree on all the points, as experienced this myself.
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:
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.
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!).
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.
My advice -- review immediately, approve immediately.
Going side by side with
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.
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 :)
I agree on all the points. Thank you for sharing for informative post.
Thanks for reading!
"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.