Improve your Code Review requests

Just before you raise the PR, review your PR on your own. Not something a lot of people do, but I found this as a great practice to follow. This will not only help you to improve your code, but also improve your capability to review a code.

With Github, you can try this approach with a draft PR or do this just before you “Create the new pull request”. You may end up finding some mistakes or areas of improvements you can make on your code. This approach has helped me to raise a better PR that I would most of the time because the PR has already gone through one round of review, from myself . Try this and thank me later :)

Usually I’ve seen that bigger PRs gets merged with minimal comments, where as smaller PRs gets more comments. Most of the time, this is not because bigger PRs are of high quality, rather its because nobody reviews bigger PRs in detail compared to smaller PRs. So if your aim is to bypass reviews, you can raise bigger PRs ;), but if you really want to make sure you get some quality code review, make your PRs smaller. Raise separate PRs for different functionality, mixing up unrelated commits in a single PR is anyway not a good idea in case you need to rollback one change out of it

This is very important too. Reviewers should be able to understand what your change is about just by reading the descriptions mentioned in your pull request. Specify the user story or ticket/bug link associated with this PR in the description so that reviewers can refer them for getting better context about a change.

Add comments to your code wherever required, but along with that add comments to your pull request as well if needed. This is not required for smaller or straight forward changes, but there are cases where the logic is complicated or some special cases where it may not be clear to everyone about why you did something. Use your logic to decide whether something needs a better explanation and if it does and if it doesn’t make sense to add the comment to code itself, put that comment in the PR. That will help the reviewers to understand why you’ve taken a specific approach and they’ll be able to do a better review for your code

It’s a good practice to detail about the testing done before raising this PR. This can include mention about unit tests/integration tests as well as about manual test details and performance test details. This will give confidence to the reviewers to approve your PR, given that you assert that required tests are executed to make sure the changes are working as expected

For the UI changes, it’s also a good practice to give the screenshot of how the new UI looks like in the PR template. This will give the reviewers a clear picture about your changes.

While the user story/ticket may have all the details about your changes, its also a good idea to mention the design doc or external articles you’ve referred for a complicated change or for special cases.

These are some of the best practices you can try to follow while raising a pull request. It’s also a good idea to create a pull request template for the team which everyone can follow. In this template, we can add some of the checklist to make sure required details are added in the pull request.

Related posts:

Considering purchasing a residence in La Jolla, California? The area is one one of the most gorgeous seaside cities in the USA. Living below, near San Diego, has numerous positive rewards. There are…