Code review chopped up. Many approaches can be taken during the…
By: Patryk Studniak
Tags: Software Architecture, Software Development, Code Review, Software Engineering, Software

Key code reviewers

Knowing the architecture and the specifics of the project is the responsibility of most involved and experienced engineers. And they are the key code reviewers. They can easily find low cohesion, violation of SOLID rules, layers nomenclature leaks, and other possible mistakes that may bite our tongue in the future. They can propose splitting, extracting, reusing, or moving parts of the code for easier maintenance and readability. And the whole rest of the benefits it can give us. Foreseeing consequences of the proposed solution, considering possible code misplacement or duplication is what they can do best.

Those are the things that should be at the top of our minds when reviewing the code.

For sure architecture violations bring the worst consequences. Worst than a couple of arguments in one method or too many lines of the class.

Three levels of code review

Considering all of the mentioned rules and ways of doing code review brought to my mind splitting code review in a hierarchical order based on its importance and effect.

Architecture

First and the most important should be an architecture focused code review. Here we should consider project specifics and agreements we made before. This level of code review should be done mainly by the most experienced programmers who understand the architecture of the project. Juniors can try to do this level code review as well and it can be a good exercise. However, they don’t have to stretch their minds too much if they don’t feel strong enough to do this.

At this stage, it’s very important to recognize possible nomenclature leaks and violations. There may be a rule that is clear to you because you know the project, but not necessarily everyone is aware of this or it may be transparent for them. This is a good point to start a discussion and figure out the motivation of the author.

Architects and engineers on the architectural level code review should also keep in mind the needs of scaling and reusability of a proposed pull request. Knowing this can unconditionally change the implementation.

Application security is also one of the key factors to keep the focus on here.

There are other architectural things that we can consider doing a code review. I think you’ve already known how valuable it can be to find an issue on this level.

Code clearance

In the second phase of code review, we can dive deeper into the code itself and be more detail-focused. It can be called a code clearance review.

Now we can argue on cohesion levels and class composition. It’s beneficial to discuss all of the doubts and confusions to better understand the thinking process behind the code. We always should ask first before blaming someone. It’s maybe something as clever that we couldn’t understand it.

Speaking of “clean code” (claps to Uncle Bob Marting and his “clean code” book) we can’t forget about SOLID rules and testing. If any of these rules are violated, we should quickly figure out why. There could be a reason why an engineer decided to not follow this rule, but it could be a mistake as well. Ah, good catch!

One of the hardest parts of programming is naming. It’s difficult to name variables, methods, functions, classes, and data structures in a proper way. Some names may be so obvious to you and totally unacceptable for others. Even that we should always try to find the best “names”, second-level code review is a place to start discussing it.

Polishing on the surface

Third and the last phase would be polishing on the surface code review. Here we can point out things that usually can be automatically caught by linters or compilers as code formatting, missing semicolons, and other trivial issues.

It’s also time for small sorting/grouping updates, complaining about used data structures, whether it’s a List<> or Set<> and so on.