Every Agile development process strongly stresses the motif that the main goal of developers should not be to concern themselves with side issues, but rather to generate working code. This allows us to implement a variety of features in accordance with our customers’ requirements.
Unfortunately, however, out in the real world, it is crucial to not only strive to implement functionality, but also to ensure your code will be kept clean and without duplicates, being easy to understand, support and extend, makes extensive use of automated tests and presents as little as possible technical debt — that is, valuable work postponed by virtue of restrictive deadlines or other more pressing priorities.
This is why over the years, both customers and programmers have jointly devised a number of solutions for assessing code quality as well as providing projects with the appropriate level of support, throughout development. Of all of these, however, one popular technique distinctly stands out — the exceptional practice of code review.
How it works
Imagine that you were friends with an incredible developer, in whom you could completely place your trust. On a particularly disquieting Tuesday afternoon, you glanced over some questionable code from your current software provider, and instinctively decided it was time to make a change, by turning to your comrade for his expert advice.
Without a doubt, your friend’s input on the quality of code would be greatly beneficial to you, as it’d enable you to report all his comments and concerns in relation to any problems that still needed to be addressed.
This, ladies and gentlemen, is code review in a nutshell.
But of course, unless this were to be repeated on a fairly regular basis, you would never fully reap all the benefits of the practice. If, however, it were to be carried out by your software vendors themselves, you could end up saving yourself an extraordinary amount of trouble.
Your wish is our command!
Thankfully, today, code reviews are commonly performed by a variety of software companies — including our own.
In these professional settings, they can either be executed as a pre-moderation process, in which team leaders or senior developers will carefully review code before giving it the go-ahead to be committed into a repository; or a post-moderation process, where any code already sent out to the appropriate code repository is then reviewed by the aforementioned people.
It is worth pointing out, nonetheless, that this pre-moderation process, though seemingly more prudent, will often result in unwanted workflow bottlenecks.
Benefits of code review
To a large extent, realising the benefits of code review is hugely dependent on the skill level of the reviewer himself, as he or she must be able to remain competently on the lookout for some subtle, far-reaching matters.
1. Catch code errors
Irrespective of what developers are currently working on, it is critical to first ensure that code will behave exactly as intended to, without needlessly causing harm to other parts of the system.
With this in mind, the obvious task of the code reviewer is to find and do away with unwanted code errors, potential security breaches, suboptimal algorithms, unnecessary third-party libraries as well as unsound architectural decisions.
2. Uphold coding standards
Good code reviewers will also remain vigilant for less-than-optimal coding standards. If the new piece of script does not conform to the style variety established in the project, it must be rightfully booted out. The end game is that just as if working on their own piece of code, every programmer should be capable of picking up where their colleagues have left off. As such, ignoring coding standards can quickly create a mess and make it substantially more difficult for newer programmers to join the project.
3. Do away with duplicate code
Especially in larger endeavours, it is not uncommon for programmers to unwittingly end up with a number of implementations of the same pieces of functionality. Code review is able to help here by empowering team members to dispose of duplicate code before any serious problems are permitted to manifest.
4. Simplify things
The technique may also bring to light some of your team’s most inefficient practices. After all, more often than not, developers will attempt to reinvent the wheel when a perfectly adequate solution exists. Thus, code review enables companies to trim their projects down and keep things running as smoothly — and simple — as can be.
5. Promote team learning
Finally, code review is also useful as an incredible educational tool, as it enables engineers at various levels of expertise to be strategically paired with the senior developers best equipped to teach them the most.
Trouble in paradise
While detractors of code review will usually tend to focus on the so-called “time-wasting” aspect of the practice, this certainly pales in comparison to the time it would take to address these issues further along the road. Still, traditional code review does admittedly present a few noteworthy flaws:
1. No tool for code launching and debugging
Although many tools to streamline code reviews exist, this is only with the notable exception of code launch and debugging tools. As a result, reviewers are barred from thoroughly investigating exactly how the code was intended to behave, as they are forced to contend with a script alone.
2. Disproportionate attention to style
In many organisations today, rather than focusing on the optimal way to deliver functionality, an inordinate amount of attention is given to coding style. This approach to development is inherently self-centred, as it ignores the needs of the customer while simultaneously making it easier for developers to sort through code. Conversely, automated tools known as linters may be used to make this task as quick and economical as it really should be.
3. Haphazard levels of expertise
Lastly — and perhaps the greatest disadvantage of code review — is the fact that reviewers are forced to inspectcode that will naturally stem from various levels of expertise. Understandably, this is often a source of brewing conflict and tension. It would be, for example, significantly harder to accept instruction that originated from someone considered a peer than if the tiresome advice had been given by a much more obvious superior.
Room for improvement
While code review should undeniably serve to solve an onslaught of quality-related issues, there is also some indisputable, much-needed room for improvement.
Thankfully, however, Software Planet have discovered that a powerful XP technique can carry just enough double-punch to strike the drawbacks of the practice dead. We are talking, of course, about the incomparable Pair Programming.
An offshoot of code review, in this Agile technique, two developers work alongside one another, at the same computer. While one programmer, commonly known as “the Driver,” writes the code, the other, called “the Navigator,” directs the Driver every step of the way.
In this fashion, pair programming is essentially code review on-the-fly. Not only will the Navigator be inclined to make the soundest technical decisions and thus steer the project’s architectural design, but any questionable code potentially developed by the Driver will never be permitted to see the light of day.
Instead, the Navigator will be with him at all times, reminding him to take heed of important tasks, such as writing unit tests and conforming to established standards.
That is not to say, however, that both developers will always be bound together. In most cases, 30-60 minutes of daily pair work should suffice to afford engineers the foundation they need to go it alone for the rest of the day. At the same time, depending on the features being worked on, pairs may also be switched up with relative frequency.
The end result, unsurprisingly, is that all developers are fully confident in the quality of their code. In fact, even when changes are required, these too may be dealt with considerably easier than before, as more than one developer will now be familiar with the source code.
The good news
As they say, reality bites. But while Agile development indeed turns out to be a lot more than just writing functioning code, through the changing power of code review, we are able to infuse our day-to-day activities with all that additional, indispensable work.
What’s more, by combining the minds of two brilliant professionals, SPG allow you to make the very most of code review — saving time, reducing costs and culminating in outstanding software.
