The Magic Behind Code Reviews

529a64e71605fb6361000428

If your codebase makes you feel like this, you need to do more code reviews.

Code reviews make better software. I’ve worked on teams that do code reviews, and I highly recommend the practice. But why do they work so well?

The magic behind code reviews is that 1 + 1 is more than 2.

A code review happens after a programmer uploads a chunk of code to the team’s repository. Someone other than the author must read and review the author’s code, suggest any changes, and once those changes are implemented, approve the chunk.

A second (or third) set of eyes works wonders for development. Each engineer knows a different part of the system and can offer different comments. Bugs get fixed (or prevented) before they go into production, saving time in the long run. And programmers make better design decisions, curbing technical debt.

The problem with code reviews is that they take time. The author has to wait for approval, slowing down his or her process. While the individual author may be blocked on a certain day, the team moves faster throughout the year. It’s like writing tests: spend an hour today to avoid losing three hours tomorrow.

In the long run, if you want to make great software, do code reviews.

What challenges do you face surrounding code reviews?

 

Advertisements
This entry was posted in Software and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s