Code review

2,150 views

Published on

code review guild line

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Code review

  1. 1. Code Review
  2. 2. Agenda <ul><li>Introduction </li></ul><ul><li>Review Type </li></ul><ul><ul><li>Formal, over-the-shoulder, email pass-around, pair programming, and tool-assisted reviews </li></ul></ul><ul><li>Example </li></ul><ul><ul><li>Open Source Code Review </li></ul></ul><ul><ul><li>Google Code Review Process </li></ul></ul><ul><li>Review Board </li></ul><ul><li>Our Code Review Rules </li></ul>
  3. 3. What’s code review? <ul><li>When one developer writes code, another developer ore more are asked to review that code </li></ul><ul><li>A careful line-by-line critique </li></ul><ul><li>Happens in a non-threatening context </li></ul><ul><li>Goal is cooperation, not fault-finding </li></ul><ul><li>Often an integral part of coding process </li></ul><ul><li>Involuntary code review happens when debugging someone else's broken code </li></ul><ul><ul><li>Not so good; emotions may flare </li></ul></ul>
  4. 4. Introduction Where do r eview fit in? <ul><li>One of many quality assurance tools </li></ul><ul><ul><li>Design stage </li></ul></ul><ul><ul><li>Unit Test </li></ul></ul><ul><ul><li>Code Review </li></ul></ul><ul><ul><li>User Testing </li></ul></ul><ul><ul><li>Bug Tracking </li></ul></ul>
  5. 5. Introduction Code Review Benefits <ul><li>P airs of eyes catch more defects/ bugs </li></ul><ul><ul><li>Subtle error of design </li></ul></ul><ul><ul><li>Code intension </li></ul></ul><ul><ul><li>Better ideas </li></ul></ul><ul><li>Enforce coding standards, style guides </li></ul><ul><ul><li>Keep overall readability & code quality high </li></ul></ul><ul><li>Accelerate learning </li></ul><ul><ul><li>Learn from mistakes without breaking stuff </li></ul></ul><ul><li>Reduce repetition of errors across the organization </li></ul>
  6. 6. Introduction Code Review in Big Comp. <ul><li>All big companies, such as Google, Adobe, Cisco and VMware, adopt code review in software development process </li></ul><ul><li>Rules </li></ul><ul><ul><li>Code must be reviewed before submission </li></ul></ul><ul><ul><li>Code review process is logged for auditors </li></ul></ul>
  7. 7. Model Formal Code Review <ul><li>From Michael Fagan’s seminal 1976 study at IBM regarding the efficacy of peer reviews </li></ul><ul><li>A sit down meeting to review code </li></ul><ul><li>Steps: planning, introductory meeting, inspection meeting, rework, verification meeting, complete. Follow-Up meeting to improve inspection process </li></ul>
  8. 8. Model Over the shoulder Review <ul><li>Developer finds available reviewer </li></ul><ul><li>Developer walks reviewer through the code </li></ul><ul><li>Reviewer interrupts with questions </li></ul><ul><li>Developer writes down defects </li></ul><ul><li>Developer fixes defects in code </li></ul><ul><li>When developer deems himself finished, he checks in code </li></ul>
  9. 9. Model Email Pass-around Review <ul><li>Developer emails the code diff to reviewers </li></ul><ul><li>Reviewers examine the code diff on their own, and send the comments </li></ul><ul><li>Developer rework until reviewers say OK </li></ul><ul><li>Developer/Reviewer check in the code change </li></ul>
  10. 10. Model Pair-Programming <ul><li>Two developers write code at a single workstation with only one developer typing at a time </li></ul><ul><li>It has continuous free-form discussion and review </li></ul>
  11. 11. Model Tool-assisted Review <ul><li>Automated file gathering </li></ul><ul><li>Combined display: differences, comments, defects </li></ul><ul><li>Automated metrics collection </li></ul><ul><li>Review enforcement (log and audit) </li></ul>
  12. 12. Example Open Source Code Review <ul><li>Author & reviewer s on separate computers </li></ul><ul><li>Author invokes &quot;diff -u&quot; to create patch file </li></ul><ul><li>Author mails patch file to reviewer s </li></ul><ul><ul><li>or uploads to e.g. SourceForge patch manager </li></ul></ul><ul><li>Reviewer s uses &quot;patch&quot; to recreate the files </li></ul><ul><li>They email back-and-forth a few times </li></ul><ul><li>Finally, final reviewer submits into svn/cvs/etc </li></ul><ul><ul><li>patch author often has no privileges (yet) </li></ul></ul><ul><ul><li>logs have “signed-off-by reviewers” info </li></ul></ul>
  13. 13. Example Google Code Review Proc. <ul><li>All command-line and email based: </li></ul><ul><ul><li>1. Author edits changes in workspace, tests etc. </li></ul></ul><ul><ul><li>2. Author send email to reviewer (a tool helps) </li></ul></ul><ul><ul><li>3. Reviewer views the diff (another tool helps) </li></ul></ul><ul><ul><li>4. Reviewer sends mail back (regular mail reply) </li></ul></ul><ul><ul><li>5. Rinse and repeat (using regular mail replies) </li></ul></ul><ul><ul><li>6. When reviewer replies &quot;lgtm&quot;, author submits </li></ul></ul><ul><ul><ul><li>lgtm = looks good to me </li></ul></ul></ul>
  14. 14. Example Google Code Review Proc. <ul><li>All command-line and email based: </li></ul><ul><ul><li>1. Author edits changes in workspace, tests etc. </li></ul></ul><ul><ul><li>2. Author send email to reviewer (a tool helps) </li></ul></ul><ul><ul><li>3. Reviewer views the diff (another tool helps) </li></ul></ul><ul><ul><li>4. Reviewer sends mail back (regular mail reply) </li></ul></ul><ul><ul><li>5. Rinse and repeat (using regular mail replies) </li></ul></ul><ul><ul><li>6. When reviewer replies &quot;lgtm&quot;, author submits </li></ul></ul><ul><ul><ul><li>lgtm = looks good to me </li></ul></ul></ul>
  15. 15. Review Board <ul><li>An awesome web-based code review tool for companies and open source projects. </li></ul><ul><li>Developed by Christian Hammond and David Trowbridge at VMware in order to improve the code review process. </li></ul><ul><li>Makes code reviews and patch contributions much easier for maintainers and contributors. </li></ul><ul><li>See more at the authors’ presentation about Review Board </li></ul>
  16. 16. Our Code Review Rules <ul><li>“ Finish code” isn’t enough </li></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><li>Maintainability </li></ul></ul><ul><ul><li>Consistency </li></ul></ul><ul><ul><li>Readability </li></ul></ul><ul><li>Use our http://rb.eng.teltel.com/ system to review all code change </li></ul><ul><li>Each project has its owner, who needs to review all the code change </li></ul>
  17. 17. Our Code Review Rules <ul><li>Keep each change atomic and as small as possible </li></ul><ul><ul><li>LOC to review should be under 200, not to exceed 400 </li></ul></ul><ul><li>Developer needs to write the description and reason of the change before publishing a review request </li></ul><ul><li>Commit log should include the URL of this code review at the Review Board system </li></ul>
  18. 18. Rules During the Review <ul><li>To developer </li></ul><ul><ul><li>Read all the comments from reviewers carefully </li></ul></ul><ul><ul><li>Deliver defense in terms of the problem you were trying to solve </li></ul></ul><ul><ul><li>Your code is on trial, not you </li></ul></ul><ul><li>To reviewer </li></ul><ul><ul><li>Criticize the code, not the developer </li></ul></ul><ul><ul><li>Before declaring a bit of code wrong, ask why it was done the way it was </li></ul></ul>
  19. 19. Resources <ul><li>Code Review Presentation http://www.numtopia.com/terry/files/codereviews.pdf </li></ul><ul><li>Review Board Presentation http://www.review-board.org/presentations/lugradio_usa_2008_reviewboard.pdf </li></ul><ul><li>rietveld: Code Review for Subversion, hosted on Google App Engine http:// code.google.com/p/rietveld / </li></ul>

×