You are currently browsing the tag archive for the ‘Code Review’ tag.
Short summary of a cisco case study (pdf):
“The largest case study ever done on lightweight
code review process; data and lessons”
We believe our results allow us to conclude the following:
- LOC under review should be under 200, not to exceed 400. Anything larger overwhelms reviewers and defects are not uncovered.
- Inspection rates less than 300 LOC/hour result in best defect detection. Rates under 500 are still good; expect to miss significant percentage of defects if faster than that.
- Authors who prepare the review with annotations and explanations have far fewer defects than those that do not. We presume the cause to be that authors are forced to self-review the code.
- Total review time should be less than 60 minutes, not exceed 90. Defect detection rates plummet after that time.
- Expect defect rates around 15 per hour. Can be higher only with less than 175 LOC under review.
- Left to their own devices, reviewers’ inspection rate will vary widely, even with similar authors, reviewers, files, and size of the review.
The only free and usable plugin: Jupiter
Update-Site: http://csdl.ics.hawaii.edu/Tools/Jupiter/Download
Works good, adds marks/comments in the editor.
Drawback:
Comments are saved as XML in a folder, which must be shared with all other developers (SVN(each comment = new Revision) /Samba)
Conclusion:
Make 1 review on 1 checked out source and commit OR create a samba server and link it to the review-data-folder, so reviews can be shared without commits.
