If your day-to-day job requires you to review the pull requests from fellow engineers and you find it difficult to review then try the approach defined in this post.
Reviewing a PR is actually can be a daunting experience and requires focus and time especially if you are reviewing a giant PR. Actually, before I share my thoughts on reviewing a PR, I would like you to understand how you should create one.
Whenever you are coding and about to create a PR, keep in mind how would you like to review a PR and try to create a PR the way you would like it.
In addition to that, I have some pointers for that.
1. - Always commit a meaningful chunk of the code.
Tip: If you forgot to commit a part of code or maybe some linter issue remained uncommitted, try not to create a separate redundant commit and squash that commit into the parent commit if it makes sense.
2. - Write an expressive message with your commits.
Avoid adding comments like fixed, fix the problem, etc, and try to be more expressive, your commit message should exactly express what you did in the code.
3. - Smaller the better
Never create giant PRs, smaller meaningful PRs are easy on the eyes.
4. - Create PR with descriptive titles and details.
5. - Try to add comments, and images on your PR whenever you feel it will make the reviewer's life easier.
For instance
- If you committed a big composer.lock file you can add a comment about what exactly did you updated.
- Maybe a new CSS change you did, try adding a screenshot of the change in views with before and after.
- If you commit a change in a compressed file sometimes it's hard to see the actual change and you can add a comment with the actual diff.
If you keep creating PRs like this it will already improve your ability to review them.
Top comments (0)