Great developers are those who are continuously on the quest to grow through learning in order to improve the type of code they write. In software development one of the ways to measure growth is through the quality of code written and output of work. Feedback is a great way to learn to correct past mistakes and one can only benefit from this process if they are receptive and open to constructive engagement or feedback.
I believe successful teams are those who have mastered the art of good communication and are able to give each other feedback on the code they are working on as it bears a lot of fruit in the long run & improves both the efficiency of the team and quality of work.
This article will focus on how best teams can approach code reviews as well as what I believe are good code review processes that can create great developers and teams.
What is a Code Review?
A code review is feedback given to a developer on the code that they have written. When a reviewer goes through the code line by line, these are the primary things they need to check for:
- Are there any errors or potential errors?
- Does it adhere to the coding standards and existing style guidelines?
- Is the code readable and understandable?
- Based on the requirements, have all the problem cases been implemented?
- Is the quality of code consistent with the application design?
- Does the code work as the author intended?
- Is the code any more complex than needed?
- Is it appropriately tested?
This is an important process that should be part of the development cycle of all teams, it does not bear a lesser priority on your work than actual coding. Everyone in the team should be involved in code reviews, from juniors to seniors for each and every piece of code that is written.
Some teams have struggled in the early stages of implementing code reviews because often no one is interested in reviewing code as developers feel it takes them away from writing code which is more ’productive‘.
Teams need to have open discussions and iterations for the whole team to be on the same page regarding the importance for them to take code reviews seriously. The process of code reviews becomes easy when everyone supports the process, from the developers to the managers and product owners.
Benefits of Code Reviews
Regardless of a team’s development methodology, code reviews are beneficial in a number of areas:
- Project benefits - There is nothing as essential as writing clean code and building a clean codebase with no bugs. This can be achieved through ensuring that each new feature added adheres to the code style and standard that the team has set for itself. Most importantly there is always room for improvement, and this process allows the teams to refactor the application code to improve the performance and implementation.
- Team benefits - One sign of successful teams is collaboration. Code reviews encourage team members to work together through sharing their thoughts and experiences and ensures all team members are aligned to the coding standards and styles that each team member is expected to adhere to. Knowledge sharing is also an important aspect that teams can benefit from and allows for decentralisation, this ensures no one is the only person who knows a specific part of the code base, everyone is familiar with the entire project. Lastly it reduces the amount of technical debt in the future, making the maintenance cost lower.
- Reviewee benefits - As a developer whose code is being reviewed, one gets to learn from other team members on how best to improve the code they write, and avoid certain mistakes. This exercise builds better developers as they learn best coding practices, approach and problem solving skills.
- Reviewer benefits - As a reviewer you get to familiarise yourself with the codebase and features that other team members are working on as well as learning various approaches to problems from the way other developers have implemented them. It also gives a reviewer an opportunity to share their knowledge on certain aspects were they think the code may need improvement on.
A code review is a great way to make sure developers deliver code without or less technical debt and reduces the bus factor (more on this later). In addition, teams can save money and time spent fixing bugs in an imperfectly written application.
Types of Code Reviews
There are different ways in which feedback can be given to developers regarding their code. Some will yield better results than others, but what is important is for teams to experiment and try different methods and figure out what works for their team. In this section we will explore the different ways in which code reviews are conducted in various teams.
Pull Request (PR) Reviews
A pull request (term used in the development space) is a request to change code in a codebase / repository. Before the changes can be merged into the master branch or published live, your team members will give you feedback on the written code. It is important that reviewers of the PR are thorough in their review. They should analyse each line of code including the engineering approach to the solution implemented and logic behind the changes. Based on their analysis of the code review they can either approve or request changes to be made. It is important that each team puts in a great amount of effort to give a constructive review. The feedback will be helpful in ensuring you build a clean codebase as well as imparting knowledge to the reviewee.
Bugs will definitely be introduced in your codebase if your approach to reviewing PRs are like this old man in the video below👇🏾.
The person who wrote the code should also do due diligence, ensuring that before and after they submit a pull request, they take some time to read and test the code they write. The 5 minutes spent reviewing one’s own code, will reduce the code review comments significantly. The obvious things to take note of are:
- Remove debugging console logs
- Remove orphan code
- Make sure your variables are named correctly
- Look for edge cases
Automated reviews
These are essential for all projects. Developers need to ensure that they have implemented automated tests, linters and performance benchmarks. The use of tools like Prettier and Integrating Linter checks in your development environment and CI, filters out typos and syntax issues as the first automated part of any pull request. This automation reduces the amount of needless checks (missing commas and semicolons), and let’s you focus on the logic behind the changes, rather than syntax errors and typos.
Code reviews are asynchronous processes and so often developers cannot expect instant feedback on the code they have written, which is why it is important to mix automated and manual code review. This enables the most effective code analysis by saving time and energy.
Pair Programming
This is an agile development process that was brought into the mainstream by the Extreme Programming movement and has since gained popularity. It is a technique were two developers work together at one workstation, one writes the code (the driver) whilst the other observes each line of code being written. Through this process, the two developers get to discuss the problem and come up with a solution before writing code. Pair programming doesn’t necessarily have to be the defacto to how teams function, but there are circumstances which may require it, such as:
- You’re the only person who knows how something works (knowledge transfer)
- You’re making big architectural decisions.
- You’re stuck
Pair programming is by far the best tool for sharing knowledge and getting consensus on code, and it ensures there is never a single point of failure in terms of knowledge or we avoid the bus factor. The bus factor being the measure of the number of people in a team who if hit by a bus (illness, vacation, and departure from the company) might put a project in jeopardy because no one else has knowledge about the project / codebase. There is no doubt that pair programming increases the bus factor.
Teams need to find the right balance between pair programming and time spent coding alone. What is important for us is that we are able to deliver the best work we can within the time we have allocated ourselves to complete a sprint.
Quality Assurance
The QA process reviews the output of the code. Is the implemented functionality working as expected and is the UI implemented as expected in the given design. When building a product that you will put at the hands of your users, you want to ensure you maintain the highest standard of what you ship out.
Guidelines
It is important that each team implements and figures out what works best for them. There is a need to find a good balance to how efficient and effective code reviews are whilst ensuring you foster knowledge sharing between teammates and open communication.
Receiving feedback on your work, especially from various sources with different personalities, can be difficult to consume and communication plays such a pivotal role to the success of code reviews in teams. Team leads and managers should play a vital role in fostering a healthy culture.
Tone of the Review
The tone of the code reviews greatly influences the attitude and spirit of the team. It is important that teams cultivate a non toxic and non hostile space were reviews are not harsh. Opinionated and strong language can lead to individuals being defensive and contrary, a professional and positive tone can lead to more inclusivity and collaboration. Make comments about the code and never make comments about the developer.
A Code review is a conversation, not a queue of commands.
Explain your reasoning
It takes time to come up with a solution and developers who are reviewing code should be cognisant of the fact that in most cases, the developer has given their best. It is important to articulate the rationale behind critique whenever you request changes to be made as the reviewee cannot automatically assume that the other person is right without clearly understanding their reasoning.
Contribute to other code reviews
Sometimes it can be quite intimidating to review other people’s code because you feel like you are not skilled enough as a junior. It is vital that you don’t become the developer who is always a submitter and never a reviewer. There is always something that you can contribute into and for you to learn and grow it is essential to read other people’s work to see how they implement their solutions.
Be kind & Empathetic
As a code reviewer, ensure that you do not take on the same attitude that you dislike. Just because some teammates are brutal when giving you feedback doesn’t mean you have to return the same attitude. Kindness goes a long way in building healthy teams. It’s a good gesture to include technical explanations and links to useful articles or resources whenever requesting a change.
Conclusion
Code reviews are essential, make no mistake, all you have to do is to ensure you curve the path of least resistance for your team and you will reap the fruits of your commitment in the long run. Be open to listening, learning, sharing and you will definitely grow as an individual and as a team.