Peer Code Reviews: How Did We Do?
This is the sixth in a series of posts on our peer code review process at Loose Cannon Studios. Here’s the full series so far:
- Peer Code Reviews: the “what” and “why” of code reviews for our studio
- First Attempts: our version 1 process that didn’t go so well
- Success: the final process and tools that we ended up with
- Good Commenting Practices: some best practices for making review comments
- About Our Crucible-Perforce Bridge: about our tool that creates Crucible reviews from P4V/Win
Time to analyze how the process worked out. Did we get the benefits we expected? Did we run into the problems we predicted we would? What new things came up that surprised us? Or did it all just devolve into a nit-picky passive-aggressive waste of time?
I’ll compare the last twelve months, where we were doing reviews as per my “success” post, with the six months before it, where almost no reviews were being done and it was the wild west as in the “first attempts”.
Code Reviews Strongly Recommended
Given the number of posts I’m doing on this subject, it should be obvious that I consider our peer code review process to be one of the most vital and successful things we’re doing at Loose Cannon. In fact, I’ve come to believe that code reviews should be a part of every studio’s process.
Not the way we’re doing it, necessarily. Our process was the result of planning by senior team members plus a lot of ongoing feedback from the team to keep it relevant and effective. So it’s necessarily specific to our culture, personalities, and projects. Another studio may need different tools. Or they may ditch the primary reviewer group, or go with pair programming instead.
But I think every studio needs some kind of code review process. I’d do it even with a team size of two.
Revisiting Our Goals
First things first. Let’s revisit our original goals and see if we hit them. Did code reviewing live up to its promises? The short answer is a definite “yes”. Here’s the list from the first post:
- Share Knowledge
- Catch And Correct System Misuse
- Raise The General Quality Of Code
- Mentor Junior Engineers
- Educate About And Enforce Standards
In all of these areas, we had significant improvement.
Share Knowledge
This was a clear win, but there are tradeoffs that highlight the differences between using a real-world conversation and a virtual-world tool. You could say that, ideally, sharing knowledge is best done face-to-face. In person, you get a tight feedback loop that quickly cuts off irrelevant discussion. And obviously speaking and listening are a lot faster than typing and reading, so you can cover a lot more ground.
Yet I already covered how, in our first code review attempts, face-to-face reviews had logistical issues. But more importantly, in the context of knowledge sharing, the spoken word doesn’t get a permalink. None of it gets captured. It can’t be referenced nor linked. It can’t be adapted into a wiki page. It has no recorded history and can’t be searched. It’s inherently private, not public, so we have a lot of duplication, on top of the warping that happens when it becomes the “telephone game”. It gets more difficult and time-consuming the more people that are involved. Lots of problems.
Once the conversation is over, it can only live on as tribal knowledge.
With a code review tool, every comment gets a permalink and is publicly viewable and searchable. Everything gets captured by design. And it’s captured directly in context, right with the lines of code that are being discussed.
Page 1 of 5 | Next page
