• Home
• About

When do you code review?

Posted on March 9, 2008
Filed Under development | 1 Comment

I stumbled across this article in my google reader on code reviews that I found quite interesting. All too often code reviews just don’t happen software projects. Whether they are forgotten about, or there is no company procedure for doing them, or no time is set aside to perform them, if no-one makes them happen, code reviews will not happen. To me that is a great shame, because code reviews are an wonderful place to learn about others in your team and to explore your problem space through the eyes of others. When done right, those teams that hold code reviews, would never dream of letting them accidentally fall of the project plan. Code reviews are an essential part of the development (yours, the teams and of course the product’s) process.

So when is a good time to hold a code review? Weekly, after every sprint/iteration, monthly? The regimented, thou shalt have a code review every X, has never worked for me. You cannot predict what will be going on in a project and shoe-horning a code review is just counter-productive in the extreme. Typically, you should always hold your first code review when you get to a place when you have something to take about. In the article, the author says this is 20% through the build. Maybe. But I think this depends on the project, so its a team gut feel. It’s got to be early enough for changes to made, glaring errors and/or omissions to be highlighted but far enough through to warrant the time and effort that needs to be invested to make it worthwhile.

After the first review, its a judgement call, as to whether another code review is needed. This is where certain design quality and product metrics can be used to help make that call. Are the number of broken builds increasing? Is the test coverage going down? Are the number of dependencies between packages increasing? Is the team producing more complex and/or large methods? Is the source not conforming with pre-defined standards. If so, maybe its time for a code review.

Oh, and before the pure agilists start jumping all over this and say code reviews, isn’t that covered by pair programming throughout. Well yes and no. I think a code review, at a team, rather than just at pair level, is a very important exercise that should not be replaced by pair programming.

Comments

•