Code Review

4,265
-1

Published on

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

No Downloads
Views
Total Views
4,265
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
88
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

Code Review

  1. 1. Code Review Tools and Process @rantav
  2. 2. Formal Code Review Meetings <ul><ul><li>A sit down meeting  </li></ul></ul><ul><ul><li>Everyone looks at the code </li></ul></ul><ul><ul><li>Need to get prepared in advance </li></ul></ul><ul><ul><li>People bring up issues that need to be fixed before you can go ahead with commit </li></ul></ul>
  3. 3. Formal Code Review - The Pain <ul><ul><li>Needs preparation </li></ul></ul><ul><ul><li>Time consuming </li></ul></ul><ul><ul><li>Hard to concentrate </li></ul></ul><ul><ul><li>No time to dig in and be thorough </li></ul></ul><ul><ul><li>Difficult to schedule the right ppl, especially at decentralized companies or projects </li></ul></ul><ul><ul><li>Synergy - Yes </li></ul></ul><ul><ul><li>Cost effective - No </li></ul></ul><ul><ul><li>Fun - well... </li></ul></ul>
  4. 4. Code Review in Apache <ul><ul><li>Every change has a jira issue </li></ul></ul><ul><ul><li>A patch is uploaded </li></ul></ul><ul><ul><li>A committer reviews and writes comments per the patch </li></ul></ul><ul><ul><li>When LGTM, the committer commits </li></ul></ul>
  5. 5. Email Code Review
  6. 6. Offline Code Review Tools <ul><ul><li>Jupiter - Eclipse prehistorical plugin </li></ul></ul><ul><ul><li>Mondrian - Google </li></ul></ul><ul><ul><li>Rietveld - Free and very limited Mondrian </li></ul></ul><ul><ul><li>ReviewBoard - The leading open source </li></ul></ul><ul><ul><li>Crubicle - from Atlassian ($$) </li></ul></ul><ul><ul><li>Code Collaborator - the leading $$ from SmartBear </li></ul></ul><ul><ul><li>Gerrit - git goodness </li></ul></ul>
  7. 7. Mondrian <ul><li>  </li></ul>
  8. 8. Rietveld http://code.google.com/p/rietveld/ 
  9. 9. Code Collaborator http://smartbear.com/codecollab.php
  10. 10. reviewboard   http://www.reviewboard.org/
  11. 11. Gerrit <ul><li>http://code.google.com/p/gerrit/ </li></ul>
  12. 12. Motivation <ul><ul><li>Teach </li></ul></ul><ul><ul><li>Learn </li></ul></ul><ul><ul><li>Maintain coding conventions   </li></ul></ul><ul><ul><li>Find defects early </li></ul></ul><ul><ul><li>Get more ppl familiar with the code (no job security) </li></ul></ul>
  13. 13. Motivation - by the numbers <ul><li>Average defect detection rate: </li></ul><ul><li>25% for unit testing </li></ul><ul><li>35% for functional testing </li></ul><ul><li>45% for integration testing </li></ul><ul><li>Design and code reviews  </li></ul><ul><li>55% at design review </li></ul><ul><li>60% at code review </li></ul>
  14. 14. Motivation - by the numbers <ul><li>Average defect detection rate: </li></ul><ul><li>25% for unit testing </li></ul><ul><li>35% for functional testing </li></ul><ul><li>45% for integration testing </li></ul><ul><li>Design and code reviews  </li></ul><ul><li>55% at design review </li></ul><ul><li>60% at code review </li></ul>
  15. 15. When? <ul><ul><li>Before commit? </li></ul></ul><ul><ul><li>After commit? </li></ul></ul><ul><ul><li>During commit (?) </li></ul></ul>
  16. 16. Who? <ul><ul><li>Manager </li></ul></ul><ul><ul><li>Tech lead </li></ul></ul><ul><ul><li>Architect </li></ul></ul><ul><ul><li>Peers </li></ul></ul><ul><ul><ul><li>Any peer from the team </li></ul></ul></ul><ul><ul><ul><li>The one most likely to have valuable input </li></ul></ul></ul>
  17. 17. Checklist (?)  <ul><ul><li>Does the code build correctly? </li></ul></ul><ul><ul><li>Does the code execute as expected? </li></ul></ul><ul><ul><li>Is all new code tested? Altered code tests up to date? </li></ul></ul><ul><ul><li>Is the code readable? </li></ul></ul><ul><ul><li>Do you understand the code you are reviewing? </li></ul></ul><ul><ul><li>Has the developer tested the code? </li></ul></ul><ul><ul><li>coding conventions? </li></ul></ul><ul><ul><li>Are all functions, methods and classes documented? </li></ul></ul><ul><ul><li>Are complex algorithms and code optimizations adequately commented? </li></ul></ul><ul><ul><li>Error Handling </li></ul></ul><ul><ul><li>Resource Leaks </li></ul></ul><ul><ul><li>Thread Safeness </li></ul></ul><ul><ul><li>Is the code free of unintended infinite loops? </li></ul></ul><ul><ul><li>Are function parameters explicitly verified in the code? </li></ul></ul><ul><ul><li>Pending/TODO </li></ul></ul><ul><ul><li>assertions </li></ul></ul><ul><ul><li>abnormal terminations </li></ul></ul><ul><ul><li>Database Transactions </li></ul></ul><ul><ul><li>Correct synchronization </li></ul></ul><ul><ul><li>no deadlocks/livelocks </li></ul></ul><ul><ul><li>Bug Fix Side Effects </li></ul></ul><ul><ul><li>All the occurrences of the bug are fixed </li></ul></ul>
  18. 18. Different Techniques - recap <ul><ul><li>email </li></ul></ul><ul><ul><li>jira patch process a la apache </li></ul></ul><ul><ul><li>over the shoulder </li></ul></ul><ul><ul><li>formal review at a meeting room </li></ul></ul><ul><ul><li>pasetbin </li></ul></ul><ul><ul><li>web tools - reviewboard and such </li></ul></ul><ul><ul><li>GitHub - fork-review-pull process </li></ul></ul>
  19. 19. Tips for Effective Code Review <ul><ul><li>Psychology  - Let's face it, there's a lot of psychology in it, so play nice.  </li></ul></ul><ul><ul><li>Be professional, nothing is personal </li></ul></ul><ul><ul><li>Strive to understand , not criticize. </li></ul></ul><ul><ul><li>Get prepared   </li></ul></ul><ul><ul><ul><li>understand the technology in use </li></ul></ul></ul><ul><ul><ul><li>know the coding conventions </li></ul></ul></ul><ul><ul><ul><li>read related code (classes/method being used) </li></ul></ul></ul><ul><ul><li>Read Slow </li></ul></ul><ul><ul><li>Short </li></ul></ul>
  20. 20. What's Short? <ul><ul><li>No more than 60 minutes </li></ul></ul><ul><ul><li>No more than 200 LOC (C code) </li></ul></ul>
  21. 21. Challenges ( למה לא ) <ul><ul><li>Ego </li></ul></ul><ul><ul><li>The Hassle </li></ul></ul>
  22. 22. The Book
  23. 23. Related <ul><ul><li>Pair Programming </li></ul></ul><ul><ul><li>Code Reading (Doug Crockford) </li></ul></ul><ul><ul><li>Static Analysis tools </li></ul></ul>
  24. 24. Extra slides
  25. 25. Eye tracking <ul><li>01 void main(void){  </li></ul><ul><li>02  int i, num, isPrime = 0;  </li></ul><ul><li>03    </li></ul><ul><li>04  printf(&quot;Input Number:&quot;);  </li></ul><ul><li>05  scanf(&quot;%d&quot;, &num);  </li></ul><ul><li>06    </li></ul><ul><li>07  i = 2;  </li></ul><ul><li>08  while(i < num){  </li></ul><ul><li>09    if(num%i == 0)  </li></ul><ul><li>10      isPrime = 1;  </li></ul><ul><li>11    i = i + 1;  </li></ul><ul><li>12  }  </li></ul><ul><li>13    </li></ul><ul><li>14  if(isPrime == 1)  </li></ul><ul><li>15    printf(&quot;%d is prime number.¥n&quot;, num);  </li></ul><ul><li>16  else  </li></ul><ul><li>17    printf(&quot;%d is NOT prime number.¥n&quot;, num);  </li></ul><ul><li>18 }  </li></ul>
  26. 26. Eye tracking (2)
  27. 27. Eye tracking (3) <ul><li>=> Now there's a physiological reason to write short method . </li></ul><ul><li>=> People who spend more time on the first scan find more issues and find them faster </li></ul>
  28. 28. Defect density vs LOC <ul><li>http://smartbear.com/white-paper.php?content=docs/articles/Case-Study.html </li></ul>Conclusion: Don't review too much code at once (<200-400 LOC)
  29. 29. Defect density vs LOC/hour <ul><li>Conclusion: Take your time (<500 LOC/hour) </li></ul><ul><li>http://smartbear.com/white-paper.php?content=docs/articles/Case-Study.html </li></ul>
  30. 30. Author preperation <ul><li>Conclusion: Author preparation results in more efficient reviews </li></ul><ul><li>http://smartbear.com/white-paper.php?content=docs/articles/Case-Study.html </li></ul>

×