Code review is one of the most important and beneficial steps that occur during the development process because it has such a big impact on the overall project and the knowledge sharing it requires across the development team. On the surface, it seems like just a good way to help keep the quality code in the main branch, but it has many other positive impacts. Sometimes not all of the potential benefits are realized because of things like short timelines, not enough prior knowledge, or lack of investigation into the code changes. Code review can be especially difficult for newer developers since it is a skill that comes with time and experience. In this post, we’re going to go over a few basic techniques to help maximize the effectiveness of code review.
Looking for Anti-Patterns
The first step while code reviewing is to look for basic anti-patterns in the code. You can think of anti-patterns as the first line of defense because you find many of them by just looking at the structure the code is written in. Arrow Code is one example of this. It’s a pattern that usually identifies unnecessary logic (See Figure 1). When glancing through the change a developer wants to make, Arrow Code can be identified by cascading “if” statements that form the shape of an arrowhead – usually consisting of at least three levels nested within each other. Seeing this anti-pattern alerts the reviewer that they need to take a closer look at that section, without them actually having to read through it. Keeping some of the basic anti-patterns in mind can help increase the speed of the process and make sure the source code has consistent patterns, making it easier to read for other developers.
Another good practice to use after inspecting for anti-patterns is to make sure to ask questions about parts of the code that you may not be familiar with. This can include certain libraries, frameworks, or languages that are needed to address an issue. Sometimes the issues can get really tricky in cases like full stack web development, due to all the different parts that need to interact in order to create a web site. Sometimes it can be tough for even the most seasoned developer to accurately review due to all the technologies that can be used in a single code change. One way to do this is a group code review session where everyone on the team sits and reads through a change together. This improves the knowledge of the reviewer and makes sure the programmer knows enough about how it works to be confident in their solution.
Code Block Assessments
Sometimes when assessing a block of code you may run across lines that may not fit an anti-pattern, but still look ‘off’. Assessing the logic and investigating into unfamiliar methods or syntax can help improve the code quality while allowing everyone to learn a new function or solution. While reviewing a piece of complex code, one easy way to improve the logic is to look for a piece that seems generic enough to be in a library. An example of this came about recently when a coworker was reviewing some jQuery code. He used a bunch of indexing and substrings to remove the last few characters from a string. It seemed like a lot of work for something so simple. After a quick search of the API, we found the slice function that removes x number of characters from the end of a string. That helped make the code much easier to read (See Figure 2). This situation is also common with array or list manipulations since most languages have small differences in their functions or capabilities.
Benefits of A Code Review
When using these three basic code review practices, you will notice an improvement not only in the code base but also in your code review abilities as a developer. Improving the code base and your team’s knowledge leads to gains in the speed and quality of development over time. That’s good for the developers and the business side.
Sometimes when a pull request contains only a smaller change to the code base a developer might just glance over it before approving it. We recommend not taking even the smallest change lightly since a few lines can affect the code base in a large way. If properly reviewed, the developers on a team will be able to know what’s going into the code base and make sure the code is as good as it can be.