Code Reviews |
 |
 |
 |
| Written by Graham Stoney | |||
|
Code reviews are the little brother of design reviews, and are another essential verification activity if producing high quality systems is part of your development agenda. Code reviews can take considerable time, but will often find bugs that are not normally identified during testing. To get the highest possible quality, you need to divide your efforts appropriately between code reviews and testing. I've never done a code review that concluded with everything left exactly the same as it started. Invariably some functional changes are necessary either because the design hasn't been implemented exactly, some requirement has been missed, some functional change has been overlooked, or your garden variety bugs have been found. And I'm thinking of products which have undergone a great deal of testing, where the coder was “sure that it was right”, because he had “tested it thoroughly”. Another benefit of code reviews is to educate engineers about good coding practices, including following the coding standard. For this to work, you need to have a coding standard, and have the review conducted by a senior engineer with the authority and clout to have it enforced. The disadvantage of code reviews compared to design reviews is that they can only occur relatively late in the development cycle, when the code has been written. The highest quality for a given level of development resources results from an optimal balance of effort between design reviews, code reviews and testing; determining that balance is a matter of experience but in my experience most organisations would operate more efficiently if they spent more time on reviews, and less on redesigning, testing and debugging poor quality code. Social Bookmark this page:         
|