Of Code Reviews And DonutsDevelopment reviews are an important tool for encouraging high quality, maintainable software. Here are some tips on how to optimize code reviews.by Robert Northrop Picture this common code review scenario: A bunch of developers, tired and stressed about their own deadlines, sit comatose in a room, thankful that a colleague brought donuts. The code's author plops down a veritable pallet worth of printouts and simply asks, "Any questions?" For what seems like hours, amidst blank stares and soft snoring, the developer translates into pseudocode, praying that feedback won't mean any rework. As they go through the motions, a coding standard violation is identified, further explanation of a requirement is requested, or, occasionally, a formidable idea is suggested. But even the good ideas will usually be dismissed with a patronizing "With the software going into production tomorrow, a change is too risky." The code review that feels like hours usually ends in less than one. Yet, the code is usually no more stable, defect-free, or maintainable. The software will likely have critical bugs and frequent crashes, potentially resulting in incorrect data and user frustration. Because it's less maintainable, these defects will require more time to fix, affecting other projects and further compounding the users' loss of confidence in custom-developed applications. Effective code reviews can prevent these problems. If for no other reasons, quality control and education make development reviews well worth your time. Quality control isn't unique to software; in fact, most industries do a much better job. Whether it's "Inspected By" labels in jeans pocket or assurances of a "288-point quality inspection," the message to consumers is "quality is important." In contrast, high quality isn't the first thing that comes to mind when you think of in-house, custom software development. Although most organizations have software quality assurance in place, these practices primarily evaluate the software's functionality, not its complex inner workings. Issues such as memory leaks, buffer overruns, poor inline documentation, single points of failure, and security holes are very difficult to find with black box quality assurance alone. In most organizations, the developer that writes the system usually ends up supporting it. These weary developers vacation with laptops and yearn for unlisted home numbers. Effective reviews serve as knowledge-transfer sessions to other developers who can then also maintain the application, eliminating the dependence on specific developers. A development review should not only resemble a manufacturer's quality inspection but also a marketer's focus group session — the potential consumers are those who will maintain the software. Like a brand manager at a focus group, in the reviews that I have conducted, the code author isn't allowed to speak, as her code should speak for itself. If the author needs to explain something during the review, it's a good sign that the explanation will need to be provided again during a late-night, outage crisis; the author should improve the code's clarity. It's About ProcessW. Edwards Deming, considered the father of quality, proposed that quality is more about evaluating processes than inspecting widgets. In manufacturing, statistical analysis on inspection data helps identify process flaws. But this technique is difficult to apply to software development. Still, reviews should strive to tweak development processes to improve the overall quality, not just that of the individual components. The following best practices are essential to engraining effective reviews into the development process:
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
|
|