Editorial Note: I originally wrote this post for the SubMain blog. You can check out the original here, at their site. This is a new partner for whom I’ve started writing recently. They offer automated code review and documentation tooling in the .NET space, so if that interests you, I encourage you to take a look.
In the world of programming, 15 years or so of professional experience makes me a grizzled veteran. That certainly does not hold for the work force in general, but youth dominates our industry via the absolute explosion of demand for new programmers. Given the tendency of developers to move around between projects and companies, 15 years have shown me a great deal of variety.
Perhaps nothing has exemplified this variety more than the code review. I’ve participated in code reviews that were grueling, depressing marathons. On the flip side, I’ve participated in ones where I learned things that would prove valuable to my career. And I’ve seen just about everything in between.
Our industry has come to accept that peer review works. In the book Code Complete, author Steve McConnell cites it, in some circumstance, as the single most effective technique for avoiding defects. And, of course, it helps with knowledge transfer and learning. But here’s the rub — implemented poorly, it can also do a lot of harm.
Today, I’d like to make the case for the automated code review. Let me be clear. I do not view this as a replacement for any manual code review, but as a supplement and another tool in the tool chest. But I will say that automated code review carries less risk than its manual counterpart of having negative consequences.