Last week I was talking with one of the developers at work and he was telling me about improvements his team was making in regards to (informal/desk check) code reviews. I told him that was great and then followed that up with a recommendation on how to improve even more. Next time there is a code review, start with the tests. This will do two things: 1) Stress the importance of having tests 2) Make the review go quicker, as the tests will either be there and make the intent of the code clear or they won’t be there and the review is postponed until tests are in place.
I know I’m not the first to make this suggestion, but I felt it was worth repeating. Code reviews do have value, even when you pair program. At least, I think they do. Pair programming provides two sets of eyes on the code at the time of creation, but it’s surprising what someone who hasn’t seen the code before will find during a review.
Oh, and if reviewing the tests during a code review doesn’t make the intent of the code any clearer, then I suggest the team investigate behavior driven development (BDD). I’m becoming quite partial to the Cucumber framework for BDD, as I like it’s emphasis on user stories with acceptance tests/examples written in plain text and backed by executable steps.