Code review is a significant part of every software development process. There are at least four primary purposes of this activity:
- finding and fixing mistakes,
- improving code quality and performance,
- enhancing code readability and maintainability,
- developing engineers' skills and experience.
Generally speaking, code review is a communication process between the author and the code reviewer. Therefore, ethics and morale might play vital roles during this collaboration. I want to suggest several basic rules that can be very useful and efficient in a code review.
1. Always explain why you suggest some changes and specify links for useful coding standards, corporate documentation, best practices, and patterns. Clear and convincing comments might help to avoid the same errors in the future.
Bad example:
"You have to check the naming convention in the company repository."
Good example:
"I believe it would be better to follow our company's naming convention in order to make the code more readable and understandable. Here is the link to the company repository, where you may find examples. Please check it out."
2. Stick to a positive and respectful manner when you make some comments during a code review. Avoid rude statements, swearing, judgment, sarcasm, and jokes from your comments. Remember that a code review is a sharable responsibility for code quality for an author as well as for a code reviewer.
Bad example:
"You must always close a file in this scenario. Fix this stupid error immediately."
Good example:
"As I know, the best practice is to close a file in this scenario in order to avoid errors in the next function. Could you please check it?"
3. Try to follow an objective point of view and concentrate your attention on a code, not the person who wrote it.
Bad example:
"I've told you a thousand times to make separate methods for each scenario. Are you deaf or dumb?"
Good example:
"It might be a great idea to create a separate method for each scenario in order to make this piece of code less overloaded and more transparent. Here is a good example of how you can change your code."
4. Remember to pay tribute to the author for the work done, point out the good parts of the code, effective solutions, etc.
Bad example:
“…”
Good example:
"This class is brilliant, so simple and efficient. I've never seen before such an approach. Well done!"
5. Never blame your colleagues for errors. Try to create an environment of trust and safety within your team so that teammates are not afraid to make mistakes.
Bad example:
"What nonsense have you come up with here? Don't ever do that again."
Good example:
"You've come up with an interesting solution, but I'm afraid it may be ineffective in several cases. Let's think together about how to optimize this solution."
6. Try to avoid direct instruction. Instead, put a conversation on learning and discovery mode.
Bad example:
"Fix this error immediately. The method works terribly slow."
Good example:
"I am sure there is a more effective solution to this method. I suggest checking this example and discussing together how to speed up the work of your solution."
7. Consider the author's context: is he/she a new hire? adding a hotfix quickly? from another team? or pushing some architectural changes? It might be important in order to suggest an appropriate solution.
Bad example:
"I don't understand anything about your code. It looks like you wrote it in 5 minutes and didn't check it."
Good example:
"It seems like you had to prepare a hotfix very quickly and show a demo to our client. It's an incredible job to make a fix so fast. I believe, now, it would be better to make a few changes in order to improve the performance of your solution."
To summarize, a code review is a process that opens up opportunities for sharing skills and experience in order to improve code quality and code efficiency. From my point of view, the code review should be considered not as a routine process of finding and correcting errors but as a way to share experiences and improve technical and communication skills by following the above tips.