How To Raise Really Good Pull Requests(PR)
Code Reviews are the most essential part of software development cycle. If you are pushing unreviewed code to master branch, Sadly, your product is destined to be doomed and destroyed by your own hands.
We all would admit that CODE REVIEW IS HARD. As a reviewer it is your job to ensure that the code is correct and of high quality before it gets merged into master. You are expected to do that by looking at a diff and list of files changed. You have to understand what the PR is trying to achieve, what’s going on, what approach is being taken, and how all these files fit together — enough that you may potentially suggest an improvement to the code. Also you will be looking out for typos and style erros. That’s really a LOT of stuff a reviewer needs to do, especially if the PR is large.
As a good software developer, it is our job to ease up the PR process for reviewers.
Here are some simple(I hope!) guidlines we all can follow to achieve the above said.
- Raise smaller PRs. This can be simpler than it, the larger the PR, lesser the chances a reviewer will be able to understand what the heck is going on in the code, even lesser chances that he/she will be able to suggest any improvement to the code being merged. Very high chances, review will just do “+1 LGTM” and let the code pass with potential bugs being taken to master. Smaller the PR, better the review.
- Write Useful title and description. Our job as a requester is to make sure the reviewer understand the content and the context both. We can add more information about the changes being done in both title and description of the Pull Requests. This will save reviewer a lot of time and better be the results of the review process.
- To the point on-commit messages. Commit messages are the 2nd most ignored part of PRs and can be used to better up the same. Commit messages should be telling What and Why of the code, not the How(How is evident from the diff of files).
- Add comments on your pull requests to help guide the reviewer(before reviews are even requested). This is most ignored part of the PRs and rarely used by the requesters(supposed to be used by reviewers only). A requester can also add comments to PRs, speciallybefore they are taken up by reviewer for the review process. As a requester can not only add such comments to each file but to multiple parts of a single file, this will potentially help the reviewer navigate through the PRs. (Such comments should not be explaining the code itself, but the context of it only).
- Make it Visual. For front end related changes, we can add screenshots of changes being done, to help reviewer understand the code and context better. It’s a simple trick with high impact.
These are not rules, just guidelines which can be used to make your overall review process more effective.
Courtesy to https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests
If you want to get in touch with me, here are the links
LinkedIn https://www.linkedin.com/in/rishi-prakash-developer/
Instagram https://www.instagram.com/rishi.prakash.barawal/
Facebook https://m.facebook.com/barawal.rishi
