The author must trust and respect the reviewers enough to be receptive to their comments. Similarly, the reviewers must show respect for the author’s talent and hard work. Reviewers should thoughtfully select the words they use to raise an issue, focusing on what they observed about the product. Saying, “I didn’t see where these variables were initialized” is likely to elicit a constructive response, whereas “You didn’t initialize these variables” might get the author’s hackles up.
Advice to Reviewers
The developer isn’t there to be sitting duck. Remember the purpose is to not demonstrate who the better programmer is: it is finding defects and to ensuring that the code is simple and maintainable.
Don’t say: “You didn’t follow standard XYZ”. A better way would be to genuinely seek to understand developer’s perspective: “What do you think about Standard XYZ and if it applies here?”, which brings me to my next point
Avoid “why did you“, “why did you not” style questions. It could put people on the defensive. “Why did you make this a global variable?” could be better expressed as “I don’t understand why this is a global variable “. Look for ways to simplify the code. One of the goals of code reviews is to create ‘maintainable’ software.
Remember to appreciate and thank the other person. People often forget how far a simple “great job” or “it looks great” could go.
Advice to Developers
Recognize that you may be attached your code and that it is normal. If you take pride in your work, that’s a good sign that you are someone who cares about the craft.
The reviewer is acting as the second set of eyes and could point things that you might have overlooked. Questions are as valuable as concrete advice.
Ask specific questions. “Does it make more sense to move all these classes into their own package?”
Thank the reviewer for their time and any feedback they might have provided.
Advice to Management
Effective code reviews require a healthy culture that values quality and excellence. Code reviews will not give you the desired results if the team doesn’t believe in delivering high-quality products. You need a positive culture in which people are engaged – one that thrives on constructive criticism and allows the best ideas to win.
It’s cultural and most people don’t want to air their dirty laundry in front of their superiors. Code reviews are best conducted by peers and management should never ask for details it could use to judge people – yes, some managers require check-lists and grades to be produced so they can “measure” and judge people.
Maybe you already have a great culture. Maybe you are half-way there. Creating the right culture depends on many factors (both internal to the team and organizational). It can be extremely challenging and there is no magic formula. Without the right culture, code reviews will not bring desired gains or at extremes, could become counter-productive.
Source from books: