Rob Howard

Code Reviews: The 13th Step To Better Code, Part 1

In the year 2000, what seems like eons ago in the software development world, Joel Spolsky created a test of twelve easy Yes or No questions that you can ask of your development group. This was a great measuring stick of how well your team is set up for success.  Is something created fifteen years ago still relevant in today’s development world? YES, very much so.  Many of the things in his test we all take for granted now; for example I’d never work on anything, even a small project at home, without a version control or task management system.  Other things on the Joel Test like QA, simple builds, and an up to date specification are key indicators that your team is well prepared to create a long lasting product.

At L4 Digital, we’ve used the Joel Test as a starting point for building our software development process.  Over the years we’ve had the opportunity to work with many different partners, and through these experiences we’ve been able refine our process.  One element stands out as being both remarkably absent from the Joel Test and completely integral to our process: Code Reviews.

The idea of having Code Reviews in the development process is certainly not a new thing, but past tools, concepts, and implementations have made them difficult or completely disruptive to getting things done.  Styles that we’ve all seen in the past include the informal “Go and take a look at the code” request at the end of a development cycle, the Over-the-Shoulder peer reviews, and the email exchange review.  All share a key problem in that they either aren’t easily part of a process, aren’t easily trackable, or aren’t very good at preventing bad code from making it to the repository. Let’s take a step back and talk about why we should even do Code Reviews in the first place. What problems are being solved?  How is this better than before?

Fixing issues with code as early as you can is highly preferred over later steps of development. Fixing issues with code as early as you can is highly preferred over later steps of development.  For example, fixing a bug after a product is shipped to end users will tend to be the most costly compared to fixing a bug that a compiler might catch on a developer’s system.  With software that someone installs, a production bug might mean blocked functionality, time lost, or a potential loss of a customer.  A bug found during compilation only impacts a single developer.  The difference in cost between a bug found in the code review stage and the QA stage or later can be quite large.  If an issue is found before QA then that means there won’t be a build with this issue, no QA defect ticket will be filed, nor will a ticket need to go through triage and verification process that includes all parts of the team.  Others depending on the build also won’t be blocked because the defect would have been prevented before it reaches their system.  Issues that are found during review also are fresher in a developer’s mind; they will remember why they wrote things in a particular way; and prevent future time re-familiarizing themselves with that code.

Code Reviews are also an easy and relevant medium for team collaboration.  It is a key opportunity for team members to stay familiar with areas of the project that they might not have specifically implemented because they will need to understand the item that they are reviewing.  If issues arise in the future, there is a guarantee that at least two people will be qualified to update the code by virtue of having that peer review.  Looking at and approving other’s code helps teams find a common style, making the source clear, consistent, and easier to maintain.  It’s also a learning opportunity for other developers to see different approaches and coding solutions in a pertinent context.

Peer developers are the most qualified to ensure code is consistent, much easier to read, and extentensible. Quality will improve through having code reviews.  Most QA teams focus on the functionality of the code from the developers, but peer developers are the most qualified to ensure code is consistent, much easier to read, and extentensible.  They also see that it follows proper platform architecture patterns like MVC or MVVM.  Proper modularity of software solutions leads to much greater code reuse and allows items to be developed or updated separately.  It would be extremely difficult for a person looking at the end result, like an application on a device, to verify those non-functional items are correct.

For example, having a View class tightly coupled with underlying API calls might not cause an application to fail, but future developers adding features, or changes in the API, will require more work and likely more difficult work than if it was build correctly the first time.  Automated tests and static analysis tools will also have a similarly difficult time finding these types of issues.  Getting the core items right should have just as much importance as passing user acceptance criteria of a feature.  Peer reviews, where one is actually looking at the files instead of the output, are the best way to ensure the quality of the non-functional core aspects of the code.

Tools for Code Reviews have improved to replace email exchanges or the need to be in person for an Over-the-Shoulder review.  They now integrate deeply with code repositories, build systems, and task management systems to make reviews a part of the process rather than an encumbrance.  For example, a potential code change from a developer will first be run through a build, static analysis, and unit tests by the build server.  Without the need of a person, the build server would automatically reject the code change if there are any failures.  This allows teams to move to a bug prevention mentality rather than bug fixing.  QA teams will be able to spend time on what they do best, testing features, rather than a broken build or a build that crashes on launch, because all code changes will have been required by tools to pass through a Code Review.

Joel Spolsky wasn’t wrong fifteen years ago when he left Code Reviews off of his test for better code.  At the time, a majority of the review processes were difficult to implement, maintain, or enforce.  Tool assisted reviews have come a long way since then with systems that work with all parts of the development pipeline.  Reduced bug cost, team collaboration, and improved product quality are easy wins obtained by adding Code Reviews to a project.  “The Joel Test” might have had legitimate reasons not to have Code Reviews on the original list, but today it would be a huge mistake to leave it out of any first class development process.

Check out Code Reviews: Incorporating Code Reviews into Your Workflow, Part 2 here.

Image courtesy of Goran Ivos for Unsplash.

Rob Howard

As Director of Technology at L4 Digital, Rob has built digital solutions on all major platforms. His team focuses on solid development practices, keeping up to date on the latest and greatest mobile and digital development technologies and ensuring clients have a successful execution of their digital strategies.

Share this:

More Posts

Want Alerts When We Post New Stuff?
L4 Digital. All rights reserved. All wrongs reserved. © 2008-2017