Synthetic Monitoring
Our best advice on getting the most out of your development team’s code review process? Don’t bite off more than you can chew.
Putting in too much work with unnecessarily heavy code review is a waste not only of the development team’s time, but also your business’s payroll. On the other hand, too little code review can lead to a product release that offers a dismal user experience or erroneous functionality. Code reviews are an efficient quality assurance practice that addresses problems with code and provides an opportunity for developers to learn from each other.
Peer Review
While each member of the development team should review his or her own code before submitting it, the code review process involves putting one or more fresh sets of eyes on someone else’s code. This practice helps work around accuracy problems that arise from code familiarity. In order to get the most out of the peer review process, management should approach catching mistakes as a positive thing instead of a negative reflection on the developers. It’s important for morale to keep the focus on improving the product and preventing mistakes from making it into the final product, as opposed to singling out mistakes or the developers who made them. It’s also a great opportunity for individual growth: Developers can help each other identify bad habits while learning more efficient ways to solve the same problems.
Break It Up!
Code reviewers get less efficient and accurate over time, so it’s best to split up the job to capitalize on the time period where a reviewer is best suited to debug and revise. It’s widely recommended that developers split up review segments into 200-400 lines of code at a time and aim to work at a rate of around 300-500 lines of code in an hour. In real time, that means review sessions should last between 60 and 90 minutes before the reviewers take a break or move on to another job. Inspection rates can vary widely between developers as well, depending on code complexity.
Annotate, Annotate, Annotate
Code annotations are important for documenting what code does, but when applied to the code review process they become more valuable than ever. Sufficient annotation makes the code review process easier because the person reviewing the code will have a thorough explanation of what the code is trying to accomplish and how. Instilling the value that developers should perform annotations before submitting their code is important, because it’s akin to a pre-emptive review. When developers write annotations, they often identify and correct problems within their code.
Verify Fixes
Code that’s modified or replaced during the code review process still needs to be tested before it is released. The review process fails when a reviewer finds a problem with code and replaces it with alternative code that doesn’t solve the problem. It’s essential to make sure the changes worked and achieved the desired result.
Develop a Checklist
Providing your developers with a checklist of things to look for across all review sessions, as well as a checklist unique to the specific code under review, helps guide the process. The checklist also helps prevent reviewers from missing key things to examine. Without a checklist, the review could end up more like a glorified read-over than a critical analysis for accuracy and efficiency.