I must admit,that I am fan of pair programming and peer review.I had a some experience with that (sort of) and it improved my code quality a lot and teach me to use design patterns, paradigms and much more in practice.
In Jason Cohen's article they described a 11 practices :
- Review fewer than 200–400 lines of code at a time.
- Aim for an inspection rate of fewer than 300–500 LOC per hour.
- Take enough time for a proper, slow review, but not more than 60–90 minutes.
- Be sure that authors annotate source code before the review begins.
- Establish quantifiable goals for code review and capture metrics so you can improve your processes.
- Use checklists, because they substantially improve results for both authors and reviewers.
- Verify that the defects are actually fixed.
- Foster a good code review culture in which finding defects is viewed positively.
- Beware of the Big Brother effect.
- Review at least part of the code, even if you can't do all of it, to benefit from The Ego Effect.
- Adopt lightweight, tool-assisted code reviews.
It seems to me that good peer review should :
Developers should review fewer than 200-400 lines of code at a time.Inspection rate should be less than 300–500 lines/hour and review should be around 1hour long per session.As during that time ,you will get best results . I agree that author of code should re-scan code before review as it helps author to re-think about code and decisions made. It helps find many of the defects during that time before the review even begins! As result it saves a lot of time and improve bug finding performance.
Everybody makes mistakes .Pair programming and peer review are great tools to produce very good quality code that require much less code maintenance in future. It uses more time during development but it saves a lot of time during maintenance.
I strongly recommend to read this article.
source: https://news.ycombinator.com/news
link: https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/
No comments:
Post a Comment