I’ve been doing a bit of traveling lately on the second leg of the Getting Git Right tour. It’s been a blast meeting so many devs from around the world. It’s been particularly incredible to see how much git adoption has grown amongst attendees in the few months since we did the first leg of the tour. When we presented in July, almost all attendees raised their hand when we asked “Who’s using git?”. However, there is one low point during every evening that I’ve hosted: the moment after I ask the question “Who in the audience is doing code review at work?” Typically less than half the audience sticks up their hand. This makes me sad, because code review has been incredibly valuable to me during my career. In fact, I would recommend code review over any other practice or technology as the single most effective way to incrementally increase the quality of any given codebase. And the DVCS implementation of code review – the pull request – is a particularly amazing tool. Here’s my top 3 reasons why: Better code The first reason is pretty obvious: having developers with different levels of experience, different technical specializations, and different perspectives grokking your code means you have a far higher chance of catching bugs and stemming technical debt – before your code reaches your customers. If you’re using pull requests, these issues are caught before your code even hits the main branch, so issues caught in review impact nobody at all. This means that the quality of your codebase and the product that you’re shipping goes way up. Knowledge sharing The second reason is a bit more subtle. Those developers that are reviewing your code aren’t just providing you a free service with no benefit to themselves – they’re learning too! As a junior developer, sitting on code reviews taught me more about software patterns and libraries than any book that I’ve read or presentation that I’ve attended. As a senior developer, code reviews have unlocked a lot of tribal knowledge that is specific to a particular software project or team. Each application has its own stack, patterns, and idiosyncrasies that shape the best way to patch a bug or implement a feature. Code review does a really good job at spreading this information around the team. Communal ownership The third reason is the most overlooked, but arguably one of the most important for the long term health of your product. If you’re a developer, you’ve probably shipped a bug to a customer at some point. It is a terrible feeling. You see the bug report pop up in JIRA during a triage session, you read the oddly-familiar description with a sinking feeling and realize that the code that you authored and shipped is causing a customer (probably multiple customers) a world of pain. However – and this is a dirty little secret – if you’re doing code review as part of your development process, that bug is not your […]
Previous Topic
