Main image of article What's the Best Way to Review Lots of Code?
As a concept, code reviews seem like a no-brainer for any firm that develops software. Such reviews not only discover bugs and vulnerabilities in the code, but also highlight opportunities to improve and refine the overall product. Who wouldn’t want to do them? Except the bigger the project, the more code that needs to be reviewed. Over on Medium, someone from Gitcolony suggests that the time needed for a thorough review can sometimes prove detrimental to a project’s timeline: “We think that code reviews should happen before someone says, ‘I’m ready to merge this into that branch, please take a look at it and let me know your thoughts.’” Gitcolony’s solution involves a workflow system for “proactively” reviewing code as it’s built, rather than at the end of the process. But every firm reviews code in its own way, with many of those best practices centering on the concept of “lightweight review.” A few years ago, for example, SmartBear Software surveyed code reviews at dozens of companies and found that that the idealized code review involved fewer than 200-400 lines of code at a time, went relatively slowly, and relied heavily on checklists and process. According to multiple sources, the other key elements in a code review are verifying that defects are actually identified and solved (i.e., having a moderator or designated reviewer check that alterations have been done), and building a wiki or archive to capture whatever’s been learned throughout the process, so that the next code review goes more smoothly. No matter what the project, however, most teams find themselves confronted by the specter of too little time to review too much code, especially on massive projects. Seized by the urge to plow through as much code as possible before a deadline, a review team might skip over crucial bugs or errors. Undiscovered bugs are inevitable, of course—that’s why all companies release updates and patches. But if the code reviewers focus on finding the most egregious bugs, and don’t let themselves get bogged down in debates over style and elegance, they can possibly move through the code fast enough to meet deadlines.