Code review is quite necessary in software development, especially in an Agile workflow.
Recently, I was reviewing code for a feature on a project I’m working on. I was doing the review quite late - I should have done it a few days earlier but I was reluctant to. Why? Because I trusted those who wrote the code. There’s probably no need to review the “good work” they must have done, I thought.
Even world-class code deserves world-class review.
Why? Because I still needed to review the code in order to be familiar with the codebase. But that’s not all. There’s more to code review than getting familiar with the codebase. So I took a look at some resources and decided to put down the summary of what I found in one piece.
Here, I’ll be talking about what code review is, what code review is not, why code review and tips to encourage code reviews.
What is code review?
Simply put, it is systematic examination of computer source code.
It is intended to find bugs overlooked in the initial development phase and improving the overall quality of source code - hence the software.
Some people believe that code should be reviewed by teammates alone, but I believe that it should be the writer as well as their teammates because naturally, even as the writer you would figure out some faults while you review your code - this would also make your teammates more willing to review your code because they would believe that everything must have been well examined by you. Only faults that you probably would not figure out without a third eye would remain after you have reviewed your code.
There are some questions that you should be able to answer while reviewing any piece of code:
- Are there any logical errors or obvious security vulnerability in the code?
- Looking at the requirements, are all cases fully implemented?
- Does the new code conform to existing style guidelines?
- Are there sufficient automated tests for the new code?
- Does the code follow SOLID principles?
- Are there performance glitches in the new code? E.g Making avoidable calls to the backend (or external services) or using the wrong data structures for certain operations.
I think that is the most useful thing that a community of programmers can do for each other - spend time on a regular basis reading each other’s code. –Douglas Crockford.
What code review is not.
Code review is not nitpicking. It is not an avenue to show that you know how else something could have been implemented when it will not improve the system.
It is not an opportunity to hit back at a teammate or colleague that found a glitch in your code earlier.
It is not damning. It shouldn’t condemn others efforts and thought process.
Code review is not the habit of just putting that nice comment or a thumbsup on a PR without actually going through the code.
Why code review?
The essence of code review can not be overemphasized, here are some of the reasons - mostly beneficial - why we (should) practice code review:
- To facilitate knowledge sharing across the code base and across the team.
- To ensure maintainability of code - hence the project, especially when a team member has to leave the project.
- To learn new technologies and techniques, as we’re never always on the same level of knowledge with all of our teammates.
- To reduce code smells.
Tips to encourage code review
- Make your code usually less than 200 LOC (lines of code) and never more than 400. When code is too lengthy reviewers get overwhelmed, so they either stop uncovering defects or they stop reviewing totally.
- Be open to feedback in terms of review and be happy to discuss about it when necessary.
- Only raise your code for review after all tests have passed and it has a successful build on CI.
- If possible, notify your teammates when you have completed a new feature and it’s ready for review.
- As a reviewer, always ensure that your review is healthy to the self-esteem of the writer of the code.
The act of reviewing code should only get better if we want to keep crafting better softwares, I hope this helps in that direction.
Big thanks to the writers of the following articles - they helped me a lot!