NEW COURSE RELEASED! - 21 HOURS, 200+ VIDEOS - Master DevOps with Docker, Kubernetes and Azure DevOps
Code Review is one of the most important components in ensuring great Code Quality in your projects. How do you ensure that code reviews in your projects yield expected results?
You will learn
- What is code review?
- Why do you do code reviews?
- When should you do a code review?
- How can you become a good code reviewer?
- What are the things to look for in a code review?
- What are the code review best practices?
Free Courses - Learn in 10 Steps
- FREE 5 DAY CHALLENGE - Learn Spring and Spring Boot
- Learn Spring Boot in 10 Steps
- Learn Docker in 10 Steps
- Learn Kubernetes in 10 Steps
- Learn AWS in 10 Steps
This is the fifth article in a series of eight articles on Code Quality
- 1 - Introduction To Code Quality
- 2 - Introduction To Coding Standards - Java examples
- 3 - Five Important Coding Standards
- 4 - Best Practices in Static Code Analysis with SonarQube
- 5 - Code Review Best Practices
- 6 - What Are Code Smells?
- 7 - What Is Refactoring?
- 8 - Continuous Integration - 5 Important Questions or Tips
Why Code Reviews
What could be the reason for doing a code review?
Remember that a code review is not a tool to find fault with others efforts.
Here are a couple of important goals:
- A code review is done to add value to the system and the people in the team.
- It also adds to a list of best practices that team members can follow.
Adding Value To The System
Code reviews add value to your system. Aim of the code review is to make the system more maintainable. Your aim is to check for bugs in adhering to functional and non functional requirements - scalablity, performance, security etc.
Adding Value To The People
Code reviews should be used as a way to enhance the knowledge of the developers involved and a way to spread the best practices.
Adding To Best Practices
An important step of code review should be to identify best practices. Common error patterns can be identified and documented.
When Should You Do Code Reviews?
Review As Early As Possible
It is preferable to do code reviews as early as possible.
Review with Normal Focus
Normal focus refers to typical code review done during the course of a sprint for a run of the mill user story.
Review with High Focus
There are times during development when peer reviews need to be done with high focus.
New Developers Joining In
A good example is when a new developer joins a team. A new developer takes time to get familiar and start implementing code that meets the team’s coding standards. An effort should be made to encourage them to learn from code reviews.
New Methodology Or Technology Implemented
When a new methodology is being adopted, or a new technology is being brought into the code base, it is important to have focused code reviews.
Building A Vertical Slice
In the initial stages of the project, you generally build a vertical slice. Vertical slice helps in solving technical challenges.
Vertical slice becomes a reference for the project. It is important to have focused code reviews for the vertical slice.
How To Do Code Reviews?
Encourage Pair Programming
Ideally, I would love to have pair programming reviews. A lot of times, it is much easier to refactor code almost immediately during the review, than at a later point in time.
Code Review Best Practices
Let’s quickly review a few other best practices related to code review.
Use Static Analysis Tools
Make use of static analysis tool such as SonarQube.
- Check the components in code, their sizes, and their interactions with other components in the code.
- Identify and look closely at certain types of code hot-spots, such as:
- Large classes
- Complex methods
- Large components
- Lot of dependencies
- Uncovered code
Review the Junits for complex method and classes, and see how readable the code actually is.
Junits are often a very good signal of the readability of code. If the code is difficult to test, the code is definitely difficult to understand.
Check Readability Of Code
Look at the readability of the code, by focusing on the Four Principles Of Simple Design.
What do you look for in a code review?
There are various aspects to be considered while doing a review of the code.
Review The Architecture
Have a look at various points, such as:
- The choice of frameworks in the code base
- The way the code components communicate with other systems
- How testable the code is?
- The architecture of the components themselves
- The extent of code reuse - Are common components are identified and abstracted away for use in other places?
Review The Design
Review the following aspects:
- What is the nature of the interaction between the various classes? How loosely are the classes coupled, and what is the cohesion between them?
- Have a look at the layer responsibilities, and see if the layers are clearly demarcated, and do not overlap in functionality.
- How well are the core object oriented principles followed in the code design?
- What is the nature of the unit tests? How easy or difficult is it to unit test the code under review?
Review The Code
- Make sure the code follows the Four Principles Of Simple Design
- Ensure the code got the basics right
- Will the code be scalable and performant?
- How does the code handle important security concerns?
- How well are the unit tests written, and are they readable?
- Are language specific standards being adhered to? In Java foe example, the following language constructs have certain purposes:
For example, Enums are preferred to strings wherever possible, and this makes the code more readable.
Review Engineering Practices
The quality of code in an application depends greatly on the kind of engineering practices followed in the team. You can check
- How often the code is committed?
- Review how often builds are broken
- Review the entire continuous integration process
In this article, we had a good overview of code review best practices for a team, or organization. The core principle behind doing code reviews is to add value - to the system, to the people involved, and to the best practices as a whole.