Today, we had our first code review with our current development team. For those of you not in the software industry, a code review can best be defined by someone else…like wikipedia!
We have done code reviews in the past, but they were very informal and their effectiveness could be debated. There were a few problems with them, mainly:
- We weren’t entire sure how to do one properly
- They degraded to an attack on the developer, not the code
- They weren’t integrated as part of the process
- We didn’t have enough people looking at the code
Now I am not saying we solved all of these problems, but we started moving in the right direction. At TEK-X, I had gone to a session by Arne Blankerts and Sebastian Bergmann about code reviews that was extremely helpful. I always felt like code reviews are for large teams, but Sebastian and Arne gave me some tips about how to implement them in our small team. It seems for us, the more formal code review process where people have defined roles would not work so well. What we did instead was to have our developers use the projector in our office to “present” their code. Our roles were loosely defined as a presenter, a note taker, and two developers to critique the code.
This approach worked really well! We closed our office door, put most of our computers to sleep, and concentrated on the task at hand. Fewer distractions led to more focus and a better session. We were able to make it through a good bit of code, finding all sorts of stuff that could be improved.
One of the major mistakes we had made in the past was letting the criticism get off the code and onto the coder. To try to curb that a bit, we all had a chat beforehand to set forth some guidelines. As the senior developer, I led with the idea that when we are critical of a piece of code, we’re talking just about the code and not about the developer. The whole purpose of doing these code reviews is to make everyone better at development, not to call anyone out or to make someone feel bad. I feel like it takes a certain amount of maturity for developers to take criticism of their code and not take it personally, and my guys didn’t disappoint. Us senior developers also made a conscience effort to be cordial when doing our criticism and I think it paid off. Everyone participated and still liked each other in the end
After the session was over, I asked the guys what they thought and they loved the feedback. They definitely wanted to do code reviews more often, so we decided that every Tuesday afternoon we would reserve for code reviews. I think this will help us stick with it and make it part of our process.
If you have never done a code review in your team, I’d suggest giving them a try. It is a great way to give feedback to your developers, and you may learn something while you are at it.