2. What is code review?
●
Systematic examination of source code
●
Goals
–
–
Better code quality
–
●
Identification of defects
Sharing of knowledge
Also known as code inspection
3. How does it fit in our process
●
After implementation, before testing
●
Dedicated task state in issue tracker
●
Author assigns it to different person
–
We do not have any hierarchy, CR should be
evenly shared among all team members
4. How should I do it?
●
Notification from issue tracker
●
Check related svn commits
–
(linked via refs #1234)
●
See changes context in IDE
●
Change reviewed code
●
Add @TODO CR
●
Add comments in issue tracker
●
Assign it back to the author
5. Why we do it?
Software testing alone has limited
effectiveness - the average defect detection
rate is only 25 percent for unit testing, 35
percent for function testing, and 45 percent for
integration testing. In contrast, the average
effectiveness of design and code inspections
are 55 and 60 percent.
(S. McConnell: Code Complete)
6. I believe that peer code reviews are the single
biggest thing you can do to improve your code.
(J. Atwood: http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html)
11. Formal Code Review
●
●
●
●
M. E. Fagan (IBM)
Code preparation → code review acceptance
criteria → committee with moderator → individual
preparation for CR → review meeting → report
with list of defects
Group review finds only about 4% more defects
than individual reviews [Cohen 2006]
See http://en.wikipedia.org/wiki/Fagan_inspection
19. Tip 1: Find the right person
http://www.jasonawesome.com/2010/06/01/executing-a-php-code-review/
20. Tip 2: Right amount of code
●
max 200 lines of code, 60-90 minutes
http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf p.50
21. Tip 2: Right amount of code (cont.)
●
Tradeoff
–
Smaller fragments hide systemic failures
–
Very hard to detect defective details in larger
pieces
22. Tip 3: Build your checklist
●
●
Know your weak spots
23. Tip 4: Be positive
●
Review is about code
●
It is not about people who wrote it
●
Goal is overall improvement
●
No blame
25. Tip 5: Accepting Code Review
●
Do not worry, everyone makes mistakes
●
Do not take it personally, it is only about code
●
Say Thank you :)
–
maybe it saved you some unpleasant fixing of
production code
26. More tips:
●
●
●
●
●
If you don't understand the code, ask the
author (and then write a comment/rename)
Finding things that are missing is the hardest
part (e.g. race condition)
The sooner CR is done the better
Explain why something is bad (provide
reference)
Use FindBugs, Sonar
27. References
●
Jason Cohen (2006). Best Kept Secrets of
Peer Code Review (Modern Approach.
Practical Advice.).
Available at Smartbearsoftware.com