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