It’s been two months since my teams last code review.
After spending a lot of time thinking about the best way to introduce them, and then finally rolling them out on a project, the process quickly lost momentum. The plan was to have code reviews on all new projects at first on a weekly basis, with the tech lead on each project leading the way. Instead we did one review which went fairly well, and then never followed up on the mandatory changes and never held another code review meeting for new code. The ball was dropped, and I was the fumbler.
Some obvious things to rethink as I get ready to relaunch them:
- Make sure I have time to really dedicate to the process. The code review process isn’t going to happen on its own.
- Try to rethink buy-in. Given that no developers really ran with the process, I’m certain they still have doubts about it. Of course in that case dropping the ball is a really bad way to reinforce those doubts.
- Set my sites lower. Maybe code reviews only happen on one pilot project to begin with.
- Possibly take over scheduling and selecting all the code for the reviews and doing the follow-up meetings. This would reinforce the commitment, but risks again getting real buy-in. (Though I’m not sure code reviews are every very easy to get buy-in on unless there is some management backing. This is also why code reviews are obviously easy if you do pair programming, but we’re really not there yet at all.)
- Revisit tool support. Most of the team has migrated to RAD now so we could use the free Jupiter plug-in. Tim Shadel has a few podcasts and posts around it which make me think it might be worth considering.
One thing I did learn on the project we tried out code reviews on was that using Checkstyle was the single most successful way to ensure some good coding practices were followed. The developers really wanted to knock down the warnings to practically zero which helped clean up a lot of small issues like magic numbers instead of constants or long method bodies.
Technorati Tags: