When to Review
In this article, we will talk about code review, but let’s look quickly at Wikipedia to learn what all the fuss is about…
“Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in software development, improving the overall quality of software. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections.”
Code reviews should happen before the code merges to the repository’s mainline branch, in many cases, it’s the main “develop” branch. As stated above – “it is intended to find mistakes,” so it’s another step where you can improve your software. Everyone learns from a code review – the author receives feedback on how he or she can improve their code and the reviewer can learn new techniques. Often, code reviews can be the beginning of a great knowledge sharing session.
You’re already doing code reviews in your team? That’s great! But, are all your code reviews as useful as they can be or could you improve the process?
Another question you should ask yourself is, what do you have to pay attention to in the first place and what should be automatized?
So, let’s talk about “the right” code review.
Code Review Feedback
I worked once on an important part of our app and after I sent my code to my teammates for review I received feedback I was not happy with. That new module involved new architectural decisions, a lot of refactoring, I tried to show off my knowledge of SOLID principles and industry best practices in that technology field.
But most of the comments were related to typos, some functions, and variable naming conventions and that’s all. And that led me to wonder, what do we review when we do the code review and in which order?
Code Review Routine
When code review is a part of your workflow, it often happens to become a routine, you can get tired (and even frustrated) of reading someone else’s code when your developer instinct tells you to open that IDE and write a few lines of code yourself. But that doesn’t mean we have to do it (code review) superficially. Everyone does mistakes, and we know it!
Typical Code Review Flow
From the surface to the deepest code review analysis…
- First, we pay attention to typos and style convention
- At the developing stage of the process these steps have to be automatized by using intellisense, spellchecker and different lint extensions for your IDE so you can avoid question such as “where to add a space” and “how many offset spaces there should be”, here are few popular ones:
- Second, we look for names, such as variable, class, interfaces, folders, files, etc.
- The place where the code is added – if that function is added in the right folder, file, class, or if that class is added in the right folder. And sometimes a refactoring is inevitable.
- Is this code even useful? Maybe that functionality already exists in the application but the person who’s responsible for implementation didn’t know about it. Maybe there is already an exact same functionality in the language itself or in some popular third part library (yes, there is String.IsNullOrEmpty() you don’t have to write your own check ? )
- Algorithms and the approach, when the reviewer looks how your approach integrates with the entire solution/system, criticizes the approach, chosen algorithms and tries to understand the big picture of your solution, having also the business logic in mind.
This is how most of the reviews are done. People are quickly looking for typos and some naming mistakes, while little to none look for the algorithms and see the big picture.
A Different Look at the Code Review Order
In my opinion, you have to start from the bottom, from the deepest understanding…
- As a reviewer, you have to understand what the developer tried to solve or improve upon, to look what the chosen approach was, and how that person tried to solve the problem.
- See if that solution does exist already in any form or if it’s even needed – sometimes we tend to overcomplicate things
- Check if that function can’t be created as a more generic one and implemented in some sort of common service or reusable component
- Now look for the names. Does that function name relate to the code inside? Maybe you can break that big function into a few smaller ones for the reusability purposes?
- After this, you can just check if there are any glaring typos, if that person still isn’t using a spellchecker in their IDE
So what are the rules of the perfect code review?
There’s only one rule – Try to go from the most complicated and work toward the most simple, and the simplest has to be automatized.
Focus on the most important, improve and automize! The purpose of a code review is not (only) the number of comments typo related.
Latest posts by Andrei
- Visual Studio Code Extensions –Angular Web Development (and not only) - June 21, 2019
- Code Review – Are You Doing it Right? - December 18, 2018