Code reviews are a great opportunity for developers to learn from each other and improve their skill set. At the same time, it's our last chance to avoid shipping bugs to production. Make sure you make good use of them instead of falling into a common trap
Why are code reviews important?
The value it brings to the team
Code review is one of the most crucial processes for ensuring knowledge transfer and best practices throughout a development team. As important as code reviews are, we typically leave it up to the reviewer to improve their process and this usually results in inconsistent review quality across a team. The poor reviewers become known and folks looking for an easy approval know who to go to.
Your team is only as good as your weakest reviewer.
Catching errors early
One part of managing a software-engineering process is catching problems at the "lowest-value" stage - that is, at the time at which the least investment has been made and at which problems cost the least to correct. To achieve such a goal, developers use "quality gates", periodic tests or reviews that determine whether the quality of the product at one stage is sufficient to support moving on to the next.
Knowledge Sharing
A code review has 4 purposes:
- To make everyone on the team better
- To make everyone on the team better
- To make everyone on the team better
- To catch errors or code smells before they become bugs or tech debt
That's not me forgetting to change the 2nd and 3rd reasons. The first 3 reasons are the same because it's that much more important than anything else you do in a code review.
Making knowledge communal makes everyone better.
Making everyone on the team better means that everyone understands the codebase. Everyone understands the data flow. Everyone understands the reasoning behind not just the mechanics of why something is the way it is. At least someone at the code review learns something and this does not necessarily have to be the person whose code is being reviewed. While this may not always happen, it should always be the goal.
Promoting Collective Ownership
The original intent and a continued motivation behind the code review process is that they help us take collective ownership in the creation of our software. In other words, we're all stakeholders in the development process by having a hand in controlling the quality of our products.
Code Review Best Practices
Keep reviews small
Giving a valuable code review requires that pull requests are small. It's unfair to give a reviewer a diff consisting of hundreds or thousands of lines of code changes. They'll end up spending anywhere from 30 to 60 minutes reviewing that diff and then have to do re-reviews when the reviewee makes the suggested changes.
A larger review also leads to a lot more time spent in the process and a lower quality output than desired. This effect has been measured by multiple companies and is documented below as the inverse correlation between lines of code and defect density. (i.e. number of defects discovered in the code review stage)
Always discuss architecture
Making sure that things are architected in a consistent and correct way is really important. This doesn't just benefit the piece of code being added, but also future hires. If things are consistent in terms of architecture it's easier for new people to understand how things fit together.
Link to relevant style guidelines
If you find code that needs to be changed to conform to your team's style guidelines or language guidelines (like PEP8 for Python), link to a document that outlines this.
If you find yourself commenting on style frequently, you should automate code style through hooks. The idea should be to focus on reviewing the code for correctness rather than style!
Constructive criticism
It is very important to cultivate a constructive criticism culture in your team and value it the most.
To have someone say all kinds of stuff about your code can be tough. We learn that criticism means you did something bad, you screwed up. And we tend to take it personally, to get offended, to feel not good enough. This is one attitude each and every one of us needs to get over. To not take criticism personally but as a suggestion of how to become better and constantly improve.
It is very important to have someone that challenges your code constantly. There is no faster way of becoming a better programmer.
As a senior developer, should I be doing code reviews?
Absolutely. In fact, you should be doing more code reviews as your responsibility on the team grows. There are multiple reasons around this:
- There's always something to learn, even from more new developers.
- You can understand the problems that particular developers face and help them out.
- Spotting repeating problems allows senior developers to start thinking about raising those issues in team meetings, creating more guidelines around them, giving presentations or writing articles, or possibly writing custom static analysis rules to catch these problems before code reviews.
Communication is key
As a code reviewee, it's fine to conduct a drafting/work in progress review to solicit preliminary feedback (especially for large changes), but make sure to explicitly communicate this with the reviewer to avoid confusion. Also, make sure to communicate with your reviewer when your review has left the "drafting" state.
As a code reviewer, remember that reviews don't need to be finished in one sitting (especially large ones). If the review is large, review a chunk of code at a time and communicate your progress. Communication is important to avoid multiple back and forth and to avoid giving a false sense of being near to completion to the code reviewee. This will then allow the code reviewee to plan their day and other tasks accordingly while also communicating the correct estimations to the project lead and manager.
Point out good lines of code
It is good practice to let the code reviewee know when you were impressed with a particular code snippet or learnt something new from their code review. This behaves like a morale booster for the reviewee and also lets them know that the approach they tried was better than the status quo of the code base.
A shout out like this also leads to a permanent registry of this new way of doing things in their mind (and the team's mind!) and might encourage them to try more of their ideas in the future instead of sticking to the way things are usually done on the team.
Give shoutouts when you learn something new because it is in those moments that you level up from your local maxima as an engineering team.
Thank you for reading❤️
Top comments (0)