Most programmers agree that it's easier to prevent technical debt than it is to pay it off. And one of the best ways to prevent sub-par code from ever seeing the light of day on a production box is to have a solid code review system in place. Over the years, I've discovered some practices that have really made a difference for me. Here's the first in a series.
Although it's traditional to have the technical lead be the "gatekeeper of the code", I believe everyone on the team should participate by reviewing the code. Here's why:
It exposes team members to other parts of the code.
Within a team, it's not unusual to break development tasks up into sections or modules, and have each member tackle one. Although this intensifies each developer's focus, it has the tendency to create mini silos.
But, by allowing all team members to look over code that's up for review, it exposes them to parts of the code that they don't normally see. This gives them a chance to gain a fuller understanding of the project, and an opportunity to see patterns and solutions that they might not have seen before.
Junior team members ask amazing questions!
Experienced developers have a tendency to take best practices for granted. And after approaching similar problems repeatedly, it's easy to get entrenched in particular patterns, without remembering why it's the best solution.
Junior developers ask some of the most fundamental questions that challenge experienced developers' decisions with profound simplicity. Giving them a chance to voice those questions and concerns provides a teachable moment for the junior developer and a chance for the senior developer to think through assumptions. Besides, those junior developers might just have a great idea that you hadn't thought of!
Everyone on the team takes ownership.
The best development teams are the ones where every team member takes ownership of the code. You encourage that sense of ownership by facilitating a review process where team members can tell each other how they feel about each coding decision. Let them argue about stuff! It means they care!
(Just keep in mind -- if they start swinging fists, you let it go too far.)
Of course, at the end of the day, the technical lead is responsible for the code. So if the team can't come to consensus about some issue, then the lead gets to make the final call on it.
Remember, the code review process isn't just about code quality. It's about team building. Create an environment where everyone can care -- where everyone can express their thoughts and feelings about it, and you'll cultivate both better code and a better team.
No comments:
Post a Comment