Until humans successfully merge with robots (which is probably not far off) we will make mistakes. We make mistakes writing software, much like we make spelling and grammatical mistakes on the first go around of everything we create (especially this blog). A first draft always needs more work, spelling and syntax errors corrected, and style improved. Code review is essentially the same idea; it’s quality assurance. Code reviews should ask these questions:
- Does the code contain logic errors?
- Are automated tests sufficient for the new code? Do new automated tests need to be written for the code?
- Does the code adhere to style guidelines?
These are necessary questions to ask when writing software, yet so many companies skip formal code reviews, or review only portions of their code. Why? Code review is, admittedly, a pain in the ass. Michael Fagan is credited with drafting the first formal code review process, and to spare your sanity, we’ll just say it’s a heavyweight process characterized by four participants, accompanied by multi-step, multi-layered processes. It’s a monster of a process, so, naturally, developers dread the task. Because so many companies are focused on speed of iterations first and foremost, code review often gets sidelined, half-assed, or some combination of the two.
Why Do Code Reviews
There are obvious reasons for code review: the more eyes on the code, the higher the quality, the more bugs are caught, so on and so forth. The subtleties of code review are perhaps more important.
When developers know their code will be reviewed immediately, miraculously things happen and result in higher quality programming — social pressure is no joke! The ego effect automatically makes for better, more conscientious developers. Sharing of knowledge is a symptom of code review too. As developers take a step outside of their compartments, familiarizing themselves with many different components of code, a natural broadening of skills takes place. Not only is this beneficial to helping developer teams learn and broaden their skills, it’s a safety net in the event that an individual leaves the team. When at least two people know and understand the code, the team won’t be left hanging when someone leaves for vacation or for greener pastures.
Efficient Code Review
We know code review is important, but how can we avoid that pesky issue of time? There is a way, in fact there are a few ways, to do code reviews efficiently. Types of code review actually support and enhance agile methodology. Given any problem, there are always different ways to solve it, and code review is no different. There are plenty of ways to accomplish code reviews, but let’s take a look at four commonly utilized agile review methods that will help you streamline the process.
- Over the Shoulder: This essentially means that a developer will ask a teammate to come over and go through their code with them. From there, it’s pretty self explanatory: the developer walks the reviewer through the code, the reviewer stops them for mistakes/questions, and the developer fixes bugs. This method works well because it’s fast and easy to implement. The downside is that it’s sort of informal, meaning it’s difficult to enforce any consistency in the process or the results. There’s a lot of room for human error here too, since the developer is talking and explaining at his/her own pace, while the reviewer is just along for the ride.
- Email Pass Around: This is pretty much just what it sounds like. Developers package up their work and send it to reviewers via email. The only consideration to make with email pass around is the difficulty of finding and collecting files under review, and then checking those into version control together. If the reviewer is looking at changes, the author will need to identify files added, deleted, and modified, and then copy them and download the previous file versions so that reviewers can visualize what has changed. A good version control system helps; it can send out emails automatically when changes are made. With an organized system in place for sending out files, this method can be really quick and others can easily be brought into a conversation for more expertise. The downside: often the communication threads, comments, etc, become overwhelming to read and sort through.
- Pair Programming: Pair programming is a bit like over the shoulder, but it’s continuous. The pair sit together and create code side-by-side — one person is the ‘driver’ and the other is the ‘reviewer’. Pair programming is proven to be efficient when it comes to catching bugs and promoting knowledge transfer among developers. Some developers truly enjoy working socially, and feel they are better able to solve problems with a second set of eyes. Complaints of pair programming are that the reviewing developer is too close to the work, and can’t step back and see the flaws, and that it consumes a lot of up-front time.
- Tool Assisted: Tool assisted review refers to any method where software gathers files, transmits and displays files, provides commentary, and defects among the files. It will give metrics, providing product managers and administrators autonomy over the workflow. This can be expensive, especially the upfront cost because the team either has to pay for a tool or create its own. It’s important to note that tool assisted review can work symbiotically with any other method, and is an important back-up to have in place. For example, automated file gathering saves developers from wasting time gathering and separating ‘changed files’ from the rest. Let the tool do that, and focus on the actual review. Automated tools also perform metrics collection, and monitor workflow. Tool-assisted review shouldn’t work entirely on its own, but these tools are so widely varied it’s difficult to say how efficient any one tool can be. No doubt however, a good tool customized to a job, and used in combination with other methods is one of the most efficient ways to review code.
Code review is an important part of quality assurance, and should not be skipped out on. No matter how talented a developer team is, there will be mistakes. Code review doesn’t have to be a drag, it can be done efficiently and return enormous benefit to the overall quality of work. Picking the most efficient method for your team requires individual attention — look at how your team works, how your office is set up, what your biggest issues are, etc. Agile code review will help you streamline your process so that code review doesn’t have to be a nightmare, and most importantly — you’ll catch bugs before they get unwieldy and start creating mounds of technical debt.