Here I listed down a couple of guidelines to have effective code reveiws
Code reviews not only improve the quality of code but also have a great platform to learn from others and share the experience. Doing and having code reviews is not an easy task. Pointing to or criticizing your colleagues and peers is not something someone would like to do daily. Therefore, doing it in a constructive and positive manner would be beneficial to both the reviewer and the reviewee.
We should aware of functionality to get to know the impact of code changes. When it comes to the review of a particular task and it is definitely required to know and investigate the time on impact analysis of a review to make sure that its perfect shippable code. I have listed out some of the scenarios where it's required to look back ourselves for a review.
- If it's taking you more than 3 hours to figure out something, ask for help, tell your peers/highlight in stand-up what's eating you up
- If something is taking more time than what the team expected earlier then highlight it early so that the team/SM can take necessary actions
- It is always recommended to write the standalone program before incorporating the changes in the component so that it speeds up the development process
- Concentrate on the Test-driven development process it avoids testing and fixing bugs separately
- Keep your head down during code reviews. Humility goes a long way. They're not criticizing you, it's your code they're after. It's not personal
- Experience doesn't matter while reviewing the code changes
- Proper explanation required when implementation is not required
- Design patterns are nice, master them before implementing them to avoid refactoring later
- If you see any un-known area while implementing it better to raise a tech topic and have a discussion with the team, Based on the outcome of the discussion it can take it to further levels
- Impact on consumers of API's/components
- Check documentation change required or not
- Check the impact of performance when using new API/JAR
- Keep functions/methods simple (doing as few things as possible)
- Use/create libraries/services when code will need to be reused. But keep them simple, you don't want a million flags just so you can cram everything into one function And whatever else you might do write comments/document your code. People need to be able to understand what you are accomplishing
- Expose interfaces/API's if other components may chance to use
- Don't re-iterate the cycle. Check if a similar kind of code already exists
- Test coverage required for each review
- Make sure to have NULL checks wherever it's required
- Provide user-friendly messages wherever if possible
- Provide the logs to easy to debug in case of failures
- Be aware of PMD rules so that it can be fixed as part of the review itself
- It is always good to have functional test cases along with unit test cases
- Do the required reading before you get knee-deep in the code.
Use the review features extensively like raising defects for a comment, priority of comment, spaces, alignment, etc..
Anyone who justifies something by saying it's "an industry best practice" actually has NO IDEA why they're doing it then think about it and if it is an added advantage then implement otherwise conveys it properly why it's not required to implement
- Industry best practices do exist, and yes it’s good to be able to articulate why it’s a best practice. However, doing something because that’s how others do it does not make it wrong. Learn why it’s a best practice.
- Focus on your growth and don't compare yourself to others. You should be inspired by other people's accomplishments.
- Don't just make data-driven decisions. Let the data guide you.
Finally, We are in the fast-growing world! You have the chance to make a real impact on your communication and technical skills. Go out & do it your way.
Prepare: 1) Adhere to coding guidelines or make one with your team members.
Use the right words: 2) Avoid using negative words and comments like "Remove", "Change", "Not needed", "No", "Bad", "I don't like this" etc... 3) Don't use sarcasm. 4) Avoid referring to code as "mine", "yours", or "theirs". 5) Ask questions instead of giving orders. Use questions like "Do you think this would be better?", "What do you think about...?" 6) Be positive. Don't say words like "I didn't do this", "It wasn't me" etc...
Clarify: 7) Explain the reason behind your comment and how it will improve the code. 8) Express yourself clearly and provide arguments. If needed, link to other code snippets or PRs. 9) Ask for clarification if the code is unclear. If there are too many questions it would be better to ask them in person. 10) Be clear in the feedback. If a lot of discussions is needed it can be done in a different session.
Accept: 11) Learn from the comments and how others tackle the same problem. 12) Don't take it personally, code reviews are about the code and not you as a person. 13) Accept all feedback. Whether you are a Junior or Senior take feedback positively. 14) Be open to other ways of writing code or methods. 15) Don't turn the feedback into an ongoing argument. You can always talk to the commenter in person.
Support: 16) Be supportive. Help by pair-programming or showing an example. 17) Be responsive. Provide more information or clarification in the same day or after one day. 18) Be quick. Don't leave too many Pull Requests open. The codebase will grow, and the PR will stay behind. 19) Give positive feedback when the PR is accepted, like using the Like emoji or saying words like "Great, well done". 20) If feedback helps, inform the reviewer how you find that helpful. Use words like "Good catch, thank you" etc...
Having a constructive and positive code review will foster a healthy work culture and allow team members to express themselves freely without the worry of shame and negative feedback. This will create an environment where team members feel respected, valued, and productive. In the end, it will allow an agile environment, knowledge sharing, and growth.