How to conduct a code review |
 |
 |
 |
| Written by Graham Stoney | |||
|
I'd conduct a code review differently from a design review in that I wouldn't bother asking all the reviewers to read the code before the review meeting; unless they're really keen. I also suggest a smaller review team; maybe 3 or 4 of the most closely related engineers. All of them should be familiar with the design, and of the requirements for the code before the review, but invariably you will end up discussing requirements and design aspects that are weak. If they haven't been nailed down by now, they're sure to pop out here. In the review meeting, read through the code function by function, traversing either depth-first or breadth-first. I lean towards depth-first, to ensure everything is covered. Print the code ound and use a highlighter to mark what has been reviewed. Pay attention to detail, including coding standard violations and mistakes in comments. Lack of attention to detail in the non-functional parts of the code are hints of lack of attention to detail in the important bits; so set a high standard here. Don't actually design fixes in the review, but keep a check-list of things for the coder to address afterwards. You want to proceed as rapidly as possible to avoid getting bored and fatigued, so try to keep things moving. If you're the author of the code, avoid getting defensive as this will simply frustrate the process. Take the feedback on-board. The aim is to maximise the quality of what you have produced, not to take pot shots at you or criticise you for not having got it perfect first-time. Take pride in what you're doing by accepting constructive criticism on how to make it even better. Social Bookmark this page:         
|