97 Things Every Programmer Should Know

(Chris Devlin) #1

Collective Wisdom from the Experts 29


Be gentle during code reviews. Ensure that comments are constructive, not
caustic. Introduce different roles for the review meeting to avoid having orga-
nizational seniority among team members affect the code review. Examples
of roles could include having one reviewer focus on documentation, another
on exceptions, and a third to look at the functionality. This approach helps to
spread the review burden across the team members.


Have a regular code review day each week. Spend a couple of hours in a review
meeting. Rotate the reviewee every meeting in a simple round-robin pattern.
Remember to switch roles among team members every review meeting, too.
Involve newbies in code reviews. They may be inexperienced, but their fresh
university knowledge can provide a different perspective. Involve experts for
their experience and knowledge. They will identify error-prone code faster
and with more accuracy. Code reviews will flow more easily if the team has
coding conventions that are checked by tools. That way, code formatting will
never be discussed during the code review meeting.


Making code reviews fun is perhaps the most important contributor to suc-
cess. Reviews are about the people reviewing. If the review meeting is painful
or dull, it will be hard to motivate anyone. Make it an informal code review
whose principal purpose is to share knowledge among team members. Leave
sarcastic comments outside, and bring a cake or brown-bag lunch instead.

Free download pdf