Marc Roussy

There are a number of excellent products out there to help make code reviews more effective. Today we’re going to look at ReviewBoard to see how it differentiates itself from its main competitors. ReviewBoard has been quietly improving its product since its initial release in 2009 to provide a great code review experience for teams of any size.

I mention static code analysis tools on a regular basis. It’s an integral part of a well-oiled code review process that ultimately brings value to the product. Let’s do a deep-dive to understand them better, their limitations, and what we can do to get around those limits.

You just finished putting the final touches on the feature you’ve been working on for the last day, and you’re ready to fire off a code review with your colleagues. The next question you may ask yourself is who to include on that list of reviewers. The first instinct is to go with people you’re familiar with, who may be less critical of your code. Unfortunately, that’s not in the code’s best interest, the organization that owns the code, or your own. A code review needs to find defects to bring value. You won’t do that if you don’t involve the best defect finders in your team.

About three months ago I was looking to expand my current playlist of software development podcasts. A quick search came up with a few lists of top development podcasts. There was one that caught my eye, on the Simple Programmer website, that was put together better than the others. I tried a few different podcasts from that list but the one that stuck was from the Simple Programmer himself, John Sonmez. I’d heard John’s name come up on a few other podcasts and had been meaning to check out his YouTube channel and podcast for a while.

An issue that I haven’t seen addressed in depth in is whether you should review every commit to your code base or only aim to cover critical parts of your application. As usual, there isn’t a single answer to the question, and there are advantages (and disadvantages) to both. The answer will often depend on your team’s context, so let’s dive right in to see if we can make some decisions on when to use a certain methodology over another.