Long used by pilots to prepare an airplane for the every phase of a flight, it serves us in much the same way for code review.
The average suggested time to spend on a code review is between 30 to 60 minutes. So how do you find time to do anything else?
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.