I love doing code reviews.
I'm far from the best code reviewer. So I'm always looking for ways to improve the code reviewing process for myself and my team. In the past 4 years, I've learned a lot about effective code reviewing.
Here are 3 lessons I found worth sharing:
1/ No one is above code reviews
All code changes need to go under review.
Did a senior or junior developer write the code change? It doesn't matter. Developers are humans and humans will inevitably make mistakes. Hand your code over to a fresh set of eyes. I'm confident they'll be able to catch mistakes (if any) in the code.
Here's a quote from Code Complete about the effectiveness of code reviews:
… software testing alone has limited effectiveness – the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent.
2/ Make it a habit to participate in code reviews
Ever feel like you have nothing to contribute in a code review?
It's OK because you don't need to know everything about the code change to participate. Here are 2 tricks I use to make sure I'm an active participant:
Trick 1: Ask questions
- Is there something you don't understand?
- Does something need more clarification from the author?
- Are you not sure if a specific change was intentional?
Submit your questions to the author. There is no shame in asking. In the worst case scenario, you learn something new. In the best case scenario, you might help the author catch a bug.
Trick 2: Celebrate wins
Give kudos to the author.
Send them a thank you note for fixing the nasty bug. Everyone enjoys a little appreciation. When someone notices my hard work, it makes my day 10x better.
Don't be afraid to celebrate the wins--big or small.
Distribute the knowledge to other team members
There was one questionable habit I had early in my career.
I always assigned the same reviewer to my code reviews. No one else. I did it because I believed that person could give me the best feedback. And I thought it was the quickest way to merge my code.
But there was one problem.
I wasn't being transparent with my team. By not assigning other team members, I wasn't giving them an opportunity to learn about my changes or review it.
I was hoarding knowledge. I was contributing to a low bus factor. Now, I assign all relevant people to the code review. The people I want feedback the most, I make to sure to assign them as mandatory reviewer.
Thanks for reading! Are there any code review lessons you've learned? Let me know in the comments or on Twitter.
Top comments (0)