The Code Review
I like code reviews now days, done right.
Code reviews help to:
- Add to the support base of the code.
- Normalize the development techniques on the codebase.
- Add to team cohesiveness.
- Help developers develop presentation and communication skills.
- Force that last 5% execution of the writing of the code.
- Improve code quality and developer skillsets.
I’ve been and hosted in several different types of reviews:
- Scheduled weekly meeting.
- Present-as-it-emerges.
- Sprint-end code reviews (in Agile).
For these reviews to be successful, I find that these rules of thumb are essential:
- Developers only.
- DEVELOPERS ONLY.
- A place to present; such as a meeting room or a quiet bullpen.
- Projects rule!
- Master of Ceremonies: Let the architect MC, a lead dev MC, or rotate through MC duties.
- Everyone should try to present at some time. Many times there are pairs where a stonger personality will always present. Hogwash. This doesn’t help the other developer at all.
- Food is a good thing to have there.
- This meeting can last a long time, hours, depending on which review style you use.
Some may disagree with the developers only rule. But it is essential; this is not functional review its code review and its all about the developers. Other points of view will create a conflict of interest, especially management, and the goal of the meeting will fail.