A software developer will have their code reviewed and will review others' code practically every day, and even with this repetition, sometimes we forget a point or two.
This is a guide with basic points to be checked in a code review, feel free to use/modify/improve it, in your company or open-source project.
For the requester
- Write good commit messages (following the Conventional Commits is a good start);
- Review your pull request before opening it, make sure you haven't forgotten any debugger or typing error;
- Keep your pull request small, this makes it easy to review and less harmful to the business;
- Ensure that your pull request passes tests, linters, and builds, and has no conflicts;
- Write a good description;
- Comment on your own pull request if any piece of code is not obvious;
- Wait for the reviewer to finish before starting to fix;
- Choose the right reviewers (example: someone who has already worked on the same part of the code);
For the reviewer
- Be kind;
- Be a thorough person (this document can help you);
- Seek context. Read the pull request description, the ticket, even check the screens (if any);
- Make sure you've set aside the necessary time to understand and make the best code review you can;
- Respect the context. If a pull request fixes a bug, don't ask the developer to refactor the entire component, this can be addressed in the future;
- Make it clear that you are doing the review, comment Reviewing when starting, and Reviewed when finished.
This guide is constantly evolving 😊
Top comments (0)