Originally posted inefficientuser.com
Everyone has there own set of best practices. Here are the few points which I would like to share with you regarding the code review.
The aim of the code review is to build the team spirit, improve the code quality and collaboratively learn the best practices.
One feature at a time
Make sure your CRR or commits are based on a single feature or story or bug fix. Keeping multiple features or bug fixes in a single code review request will create more confusion. So keep it simple.
Add members to review
Add everyone from the team to your code review request. At least 2 reviewers should review your code before it has been merged to the remote repository.
Information about what has been changed
Add information about what has been changed in the CRR. Add the related tickets/story/bug link in the CRR (in most of the cases). This will help the peer-reviewers to get insight or information about the task.
Notify the team
Send an Instant message to your team when the CRR request is sent or when the individual completes reviewing a particular request.
If you have any automated system like webhook or slack notification, that's fine. Otherwise, it’s OK to maintain a separate channel or group to discuss CRR.
Write it simple and clean
Keep the commit message concise & clear (if it is a bug fix mention it clearly).
When you are reviewing, look into the code and make sure you understand what code does actually; if there is any doubts/clarification needed highlight the code and add comments for clarification.
The aim is to have a readable code so that the remaining team member can also understand.
Be an advisor
If you find the code is difficult to understand or it could be even simpler feel free to suggest the better way to do that.
It’s a good habit to suggest something good instead of just mentioning that a particular piece of code can be improved.
Maintain patience
Don’t urge to get your code get reviewed; Give some time to the reviewer and add a gentle reminder if it takes too long.
Be gentle
Stay humble, all these processes are to improve ourselves in a better way.
The code review process is to improve the code quality and build the team spirit in a better way. Collaboratively we can learn more from Code Reviews.
Happy Coding!
Help me to test whether the comment section is working? Leave your feedback in comment section, please!
Click that follow somewhere in this page to see more content in future!!
Top comments(10)
- LocationUSA
- EducationComputer Science (Eastern Washington)
- WorkSenior Quality Assurance (SDET)
- Joined
I would add, clarify what should be taken care of and what is just future not of later work.
Any comment is generally expected to be resolved before merge. However during reviewing it can be a good opportunity to explore new standards.
- EducationMaster at BITS Pilani
- Joined
Perfect!
I would like to add, if we are working in a team it might happen that we would seek help from a team member. In such case, I would prefer to keep that member out of reviewer's list as he/she is aware of what the code does.
- EducationMaster at BITS Pilani
- Joined
I agree
- LocationOslo
- Joined
Good tips! It's also possible in GitHub to set up templates for pull requests, which can be really useful to encourage people to include the right info.
I usually add a field for:
- Issue the PR is linked to
- Screenshot before & after (if it's a visual change)
- Description of what has changed
- Checklist (mainly unit tests, linting)
You can also link Jira to GitHub, so if you start the name of your PR with the Jira issue number, it will automatically connect the two.
- EducationMaster at BITS Pilani
- Joined
Perfect!
- EducationMaster at BITS Pilani
- Joined
CRR means code review request
Sorry I should have mentioned it clearly
Awesome list of items. We have some cool dev's in our team as well :)
- EducationMaster at BITS Pilani
- Joined
Having a bunch of cool guys makes the team stronger.
For further actions, you may consider blocking this person and/orreporting abuse
