Jack Franklin

Better code reviews

When you get a code review request from a colleague, what do you focus on? What reaches the bar for what you consider something that's worth commenting on? And do you make it clear when you're making a comment on something vs considering something so important to change that the code review shouldn't be merged without it?

Code review is hard. I've seen people do it really well and people do it really badly, but most of us are somewhere in the middle. Giving feedback to people is hard, and it takes practice to be comfortable taking feedback on that large piece of code you've spent the last couple of days thinking about. Code reviews are so crucial to a team's pace, but also their happiness. I've seen bad code reviews become almost infamous and hurt a team's culture because people start to feel unsafe sharing their code for review. A good code review process gets you better code in the codebase whilst at the same time boding your team, increasing knowledge sharing and providing a great opportunity for team members to learn from each other.

With that in mind, here's some things I've learned that have helped me improve code review - both reviews that I get from others, and reviews I give others:

We'll definitely be revisiting the topic of code reviews in future blog posts; they are a great way to think about the code you're writing and its potential confusion points (in my head I like to think "what would a reviewer say about this?" or "what is non-obvious to the person reviewing this code?") to help me improve my code.

In the mean time, I'd love to hear about your team's practices when it comes to code review; feel free to let me know on Twitter.