Our cloud best practices for reviewing pull requests

Pull requests tips for the Developer

Make it easy on yourself and your team by working in a unified way. Use tooling to your own advantage and make agreements about the quality requirements you set. Not only to your code, but also to your work process.

• Keep it Simple! Small PRs (pull requests) are easy and quick for a reviewer to review, making the feedback loop quick and short and allowing you to get on with processing the review comments. Or on to the next task of course!  
• Do not link more than 1 task to your pull request and limit changes to the PR to the change required for that task.
• Clearly describe what the change to your PR entails so that it is clear to the reviewer what the context of the change is.
• Use tooling to automatically check/check off things like coding standards.
• Ask for a "second opinion" from a second reviewer when you and the reviewer disagree on something.
• When processing review comments: put a short note with each comment showing that you have modified it. Do not set the comment to "Resolved" but leave this to the reviewer. This makes it easy for the reviewer to see which comments are resolved and which are not.
• Automatically create a build of the code in your PR to prevent the build from breaking after your changes are approved.

Trust us. It makes your life as a Developer a lot easier. You have overview, guarantee speed and quality. And you make it a joint result.

Pull requests tips for the Reviewer

Are you familiar with the 4-eye principle yet? We just 'hammer' it into him again, you know. Joost-Jan wrote about it earlier and Anton also discusses it in the Golden Path video series. Moral of the story? Collaboration is key! Read more on TeamValue - The Golden Path.

• Check that the code in the PR conforms to the generic architecture principles and/or standards your team uses.  
• In addition, take a step back and see if the changes in the PR fit into the bigger picture of the system the code is part of.
• In addition, check that the code meets the specific acceptance criteria associated with the task and/or Product Backlog Item associated with the PR.
• Use Azure DevOps' built-in feature to "put a check mark" for each file you've reviewed. This allows you to see at a glance what you need to review again after an update to the PR. You can read much more about it on Microsoft's site. Review and comment on pull requests - Azure Repos | Microsoft Docs

Conclusion: a Developer creates the code to realize the functionality described in the user story and makes a pull request. A fellow Developer performs a peer review ensuring the 4-eye principle. The latter approves the pull request after completing the review and incorporating any review comments.

Our golden tip that will lead you further to The Golden Path

And then the golden tip! The (peer) review process in a team is super important! Therefore, make an agreement in your team that when the build breaks and/or a bug that should have been seen during a review, the reviewer is responsible for it. Is something missed? Then the reviewer should treat! Just watch how seriously the review task is taken after making this agreement.... ;-) An additional advantage if it does go wrong: everyone learns from it and there is, for example, delicious cake in the office. Rather not get too fat from too many treats? Then follow the tips above. Watch how quickly your team realizes the value of your own golden path.  

Want to read more from our cloud colleagues? > TeamValue - Blog