Code Review

Lukas Rypl
Twitter: @LukasRypl
01/2014
What is code review?
●

Systematic examination of source code

●

Goals
–
–

Better code quality

–

●

Identification of ...
How does it fit in our process
●

After implementation, before testing

●

Dedicated task state in issue tracker

●

Autho...
How should I do it?
●

Notification from issue tracker

●

Check related svn commits
–

(linked via refs #1234)

●

See ch...
Why we do it?
Software testing alone has limited
effectiveness - the average defect detection
rate is only 25 percent for ...
I believe that peer code reviews are the single
biggest thing you can do to improve your code.
(J. Atwood: http://www.codi...
Quality
Less Bugs

http://eugenedvorkin.com/engineering-culture-and-why-it-is-matter-for-business/
Better “Bus Factor”
●

More people know the code

http://www.amazon.com/Tomorrow-Heres-Replace-Toilet-Paper/dp/1607552647
Code Review Types
●

Formal

●

Tool-assisted

●

Email/VCS

●

Informal

●

Pair programming
Formal Code Review
●

●

●

●

M. E. Fagan (IBM)
Code preparation → code review acceptance
criteria → committee with moder...
Tool-assisted review
●

●

Github pull requests, Gerrit, Crucible, Review
Board, SmartBear Code Collaborator …
Comments at...
Email / VCS
●

Please review the attached patch ….

●

Better than nothing :)
Over-the-shoulder review
●

Informal method

●

Suitable for small snippets
Pair programming
●

Is it 100% code review?

●

Both are authors (inside the box)

●

Third pair of eyes should do CR
Any drawbacks?
Watch out! Feeling too safe?

http://www.bonkersworld.net/code-reviews/
Tips
Tip 1: Find the right person

http://www.jasonawesome.com/2010/06/01/executing-a-php-code-review/
Tip 2: Right amount of code
●

max 200 lines of code, 60-90 minutes

http://smartbear.com/SmartBear/media/pdfs/best-kept-s...
Tip 2: Right amount of code (cont.)
●

Tradeoff
–

Smaller fragments hide systemic failures

–

Very hard to detect defect...
Tip 3: Build your checklist
●
●

Know your weak spots
Tip 4: Be positive
●

Review is about code

●

It is not about people who wrote it

●

Goal is overall improvement

●

No ...
http://vunvulearadu.blogspot.cz/2013/06/code-review-and-under-stress.html
Tip 5: Accepting Code Review
●

Do not worry, everyone makes mistakes

●

Do not take it personally, it is only about code...
More tips:
●

●

●
●

●

If you don't understand the code, ask the
author (and then write a comment/rename)
Finding things...
References
●

Jason Cohen (2006). Best Kept Secrets of
Peer Code Review (Modern Approach.
Practical Advice.).
Available at...
Upcoming SlideShare
Loading in …5
×

Code Review

594 views

Published on

A small how-to about code review / code inspection.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
594
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Code Review

  1. 1. Code Review Lukas Rypl Twitter: @LukasRypl 01/2014
  2. 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. 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. 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. 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. 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)
  7. 7. Quality
  8. 8. Less Bugs http://eugenedvorkin.com/engineering-culture-and-why-it-is-matter-for-business/
  9. 9. Better “Bus Factor” ● More people know the code http://www.amazon.com/Tomorrow-Heres-Replace-Toilet-Paper/dp/1607552647
  10. 10. Code Review Types ● Formal ● Tool-assisted ● Email/VCS ● Informal ● Pair programming
  11. 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
  12. 12. Tool-assisted review ● ● Github pull requests, Gerrit, Crucible, Review Board, SmartBear Code Collaborator … Comments attached to code, history
  13. 13. Email / VCS ● Please review the attached patch …. ● Better than nothing :)
  14. 14. Over-the-shoulder review ● Informal method ● Suitable for small snippets
  15. 15. Pair programming ● Is it 100% code review? ● Both are authors (inside the box) ● Third pair of eyes should do CR
  16. 16. Any drawbacks?
  17. 17. Watch out! Feeling too safe? http://www.bonkersworld.net/code-reviews/
  18. 18. Tips
  19. 19. Tip 1: Find the right person http://www.jasonawesome.com/2010/06/01/executing-a-php-code-review/
  20. 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. 21. Tip 2: Right amount of code (cont.) ● Tradeoff – Smaller fragments hide systemic failures – Very hard to detect defective details in larger pieces
  22. 22. Tip 3: Build your checklist ● ● Know your weak spots
  23. 23. Tip 4: Be positive ● Review is about code ● It is not about people who wrote it ● Goal is overall improvement ● No blame
  24. 24. http://vunvulearadu.blogspot.cz/2013/06/code-review-and-under-stress.html
  25. 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. 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. 27. References ● Jason Cohen (2006). Best Kept Secrets of Peer Code Review (Modern Approach. Practical Advice.). Available at Smartbearsoftware.com

×