Last time we talked about the different mechanisms and practices we put in place in order to get us to working software, the main metric in agile delivery. We talked about how “working software” means not just that software is functional, it’s built to last. One of the most effective of these practices is code reviews, and we’ll start, as always, with “Why”.
Code reviews with benefits
Usually while we write code, we’re in “functional mode”, getting the code to work. We’re problem solvers, and we try to translate a design we have in our mind (or the one that we’ve reviewed with the team), into code. We’re not just typing, we’re eager to see that it’s working.
While the focus means we’re go forward, we miss out on things on the way. The things that jump at us when we look at the code a week later, and we either don’t understand what we did there, or think “I could have done it differently”. On top of that there are the things that we still miss completely. As agile people, we need feedback.
This is where the code reviews come in, and it brings some awesome benefits.
- Finding problems early
We have other people look at our code, before it gets into production, testing, or even an integrated environment. These problems we’ve missed, when we focused on “making it work”. The impact of the things we didn’t cover can range from holding back development because the build broke, to sneaking bugs into production. Having other sets of eyes on what we think works can uncover issues, and give us an opportunity to fix them before any damage is done. Agile development is about reducing risk, and early feedback does that.
- Fight complexity
Any code we write is already complex. It carries with it not just “what it does” and “how it’s written”, but also mountains of invisible assumptions, multiple dependencies, and personal preferences. Unless a miracle happens and we happen to write the code once and it’s so good it will stay like this forever, we (or someone else ) will get back in there. The more complex it is, we (or they) will have longer time understanding it, maintaining it, and our chances of inserting a bug or two increases.
Code reviews are the opportunity we have to reduce complexity. Make things simpler, readable and isolated. Understand the assumptions and make sure that “the new guy”, coming in to the code in a few weeks doesn’t miss them. And that further maintenance is less costly than rewriting the whole thing. This is another type of feedback we need in agile development, which goes under technical excelence.
- Knowledge sharing
In big projects, we are so focused on “what I write”, and forget that all the other people on the project are also thinking the same. The more people we have, the more assumptions on “how other people think” there are. These differences between how we think, and how they think cause all kinds of shenanigans. They result in longer integrations, unexpected bugs, and fun-filled post-mortems.
Spreading the knowledge of design, requirements and “how things should work”, is a great way to reduce the number of those social events. The more we do it, we’ll save ourselves the heartache involved.
Code reviews are a way to show other people (hopefully people who we integrate our code with theirs) our code. An opportunity to discuss what we were thinking when we were building it, how it solves the problem, and what is still open, or what we should be thinking about next.
Regardless if you’re a junior or a senior, and if your partner in the review is junior or senior you’ll both learn something every time you review code.
We’ll talk about how to do code reviews effectively in future posts, but here’s a spoiler: They are short and frequent, so there are multiple small opportunities to spread the knowledge. Knowledge sharing goes under the agile principles of technical excelence and sustainable pace.
- Promote collective code ownership
One of the principles of Extreme Programming is Collective Code Ownership. There’s no one person responsible for a piece of code, even if she’s the writer of that code. It also means that when she’s on holiday in the Caribbean, and there’s a production problem in that code, we don’t wait for her to return, or even worse, start pressuring her to cut her vacation short so she can come and save us. Everyone on the team should be able to step in and change the code.
We’ve already discussed knowledge sharing in general. But this benefit of code reviews goes a bit further. Encouraging other people to “step into your house” (confirming that it’s not really yours) creates an environment where people don’t protect “their” code from others. They are actually encouraged to make it habitable for other people. And when the partner says “I understand”, that means that the house is ready to be lived in. Collective code ownership is part of agile’s technical excelence principles.
- Maintain conventions
Part of the “I can live in this house”, says “I understand what’s written, and why it’s written like that”. If and when I’ll be called in, I can make changes in the code. The things that make it easier to understand and make changes are conventions.
Conventions can be stylistic, naming related, design, architecture related and more. They can be from where we put the opening braces, to deciding if inlining functions is good or bad, to how we split packages, to when we introduce a new service. They all fall into the “This is how we develop here” bucket. Conventions make our lives easy because there are fewer decisions to make, and therefore fewer things to worry about. The team conventions should always outweigh personal preferences.
There are no “best” conventions (including where to put opening braces). There are those that are good for the team. And code reviews are perfect opportunities to teach them, and enforce them. Once more pillar in agile’s technical excelence principles.
There are lots of opportunities
Code reviews as an opportunity for improvement seem to be a recurring theme. It’s not just chance, though. If we want to get those benefits we need to allot time and prioritize code reviews. More on that next.
Published on Java Code Geeks with permission by Gil Zilberfeld, partner at our JCG program. See the original article here: Getting to Working Software: Code Reviews – Benefits Opinions expressed by Java Code Geeks contributors are their own. |
