Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Code Review


Published on

Published in: Technology

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 
  9. 9. Code Collaborator
  10. 10. reviewboard
  11. 11. Gerrit <ul><li> </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> </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> </li></ul>
  30. 30. Author preperation <ul><li>Conclusion: Author preparation results in more efficient reviews </li></ul><ul><li> </li></ul>