Responsibilities and chores. Maybe just reading these words is enough to tire some people out, but we all understand that whether they’re exhausting or not, whether they’re many or just a few, whether you have to do them yourself or not, they’re required for us to have good/healthy lives. It’s the price to pay for a better outcome in the long-term.
As programmers and humans, we are bound to make some mistakes every now and then. We can prevent many of them thanks to the design phase of development, but writing the code itself is a different story. The way we implement certain functions, the way we manage our resources, the algorithms we come up with, among many other things, will not always be the most efficient. It’s important to periodically go through our code to look for any mistake or to find some details that would need to be changed, and that’s (kind of) what code review is all about. Just like chores, this process is fundamental to achieve better results in the long-term.
Code review is an activity in which one or more persons go through a programmer’s source code looking for said mistakes and details. Formally, the author of the code shouldn’t go through their own code by themselves, since they may overlook certain parts from the code or simply not be aware of an error in it. This “rule” has led to the creation of many techniques or methodologies for a better analysis of the code, which along with systematic processes and specialized software/tools has created many efficient ways for us to get our code revised.
Some of these tools help us checking our code automatically, but I won’t be focusing on those, since they are better suited for what’s called static program analysis. Instead, I want to quickly explain what kind of tools are used for this type of activity. Online software repositories, like Git, are useful since many developers can regularly check for changes, revert them or even write themselves, very useful for code revision. Ticket systems, like Redmine, allow people to collectively review code. There are even more specialized tools for this particular activity, you can take a look at some of them and their particularities in this link.
These tools can be used for multiple different methodologies. Each of them has a different approach as to how the code review is to be performed and, obviously, they require different things. I’ll provide a brief explanation for some of them.
Email Thread. This one is really simple. The main idea is to send a file via email with the code you want reviewed to a colleague or a supervisor. Their workflow will eventually let them download/open the sent file and resend it with the appropriate corrections. This method is simple and flexible, but having to constantly download files and putting all corrections together may be a little more exhausting than it should. This problem could be solved by using a repository like Git, but that wouldn’t be an email thread anymore.
Pair programming. Definitely one of the more popular approaches. This one consists of two people working on the same code at the same time while checking each other’s progress. This combines the programming and its revision, and can be really useful, but I feel like it presents the same risks as if the coding were being done individually, since both people could overlook some stuff.
Over the shoulder. This one is also very simple and very easy to perform. Similar to the email thread, once you finish coding you have to get someone to get your code revised, but with this method you have to walk them through the code and explain why you did it the way you did. Generally this one’s done with people in your same workspace (so no downloading is necessary) and makes it a more informal approach. This one doesn’t need documentation, but a way of keeping track of corrections and changes is very recommended.
Likewise, there are tons and tons of recommended practices for code revision. The ones I’ll mention come from this website in case you want to check it out!
Review between 200 and 400 lines of code at a time. The brain’s effectiveness to process information and detect errors in code can diminish after approximately reading 400 lines of code, at least according to a study by SmartBear.
Don’t review more than 500 lines of code per hour. In a similar way to last recommendation, this one comes from the way we process information. If we do it to quickly, then we are probably not doing it correctly.
Don’t review for more than 60 minutes at a time. Again, since our effectiveness diminishes as time passes, this recommendations intends to always keep us at our best when reviewing.
Now, the whole point of code revision is, of course, to improve the quality of our code. It creates defect-free, well-documented software; it makes our program compile with enterprise coding standards and serves to teach and share knowledge between developers. When done correctly, peer reviews save time, reduces the required amount of work and can even save money. I can’t stress enough how useful it’s to do code review in the long-term.
TL; DR: Try code revision!!!