Copyright © 2013 by Mark J. Sebern Code & Design Reviews Maybe it is time to revisit the concept of “done” Note that both design and code reviews (or inspections) are included in this sample definition. Table 4.1 in the course textbook, Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth S. Rubin, Addison- Wesley 2013.
Copyright © 2013 by Mark J. Sebern Code Reviews Do you (or your team) review code now? If so, how do you do it? How effective are these reviews? Potential problems Difficulty in maintaining attention/focus Knowing what to look for
Copyright © 2013 by Mark J. Sebern Types of Code Reviews Personal review Code author reviews his/her own work Peer review Review by another team member Inspection Review by whole team (or subset) What are the tradeoffs among these approaches?
Copyright © 2013 by Mark J. Sebern Code Review Checklists What is a checklist? Pre-flight example Why? For code: Based on historical defects Used to guide review
Copyright © 2013 by Mark J. Sebern Checklist Usage
Copyright © 2013 by Mark J. Sebern Review Timing Review code before committing to build? Ensures review is done Delay for peer/team reviewers? Later May tend to lower priority of review
Copyright © 2013 by Mark J. Sebern What About Design? What is your experience with reviewing designs? Have you ever done a design review? What exactly do you review? What do you look for? What kinds of design defect have you found?
Copyright © 2013 by Mark J. Sebern Design Documentation Do you actually have designs that are documented well enough to have real defects? If not, does it make any sense to try to review them?
Copyright © 2013 by Mark J. Sebern UML Design Documentation
Copyright © 2013 by Mark J. Sebern UML Design Documentation ExternalInternal Static Class diagram with embedded descriptions Pre- & post-conditions, behavior descriptions Dynamic Use cases and UC/sequence/activity diagrams State charts/diagrams
Copyright © 2013 by Mark J. Sebern Using Tests as Design Documentation In theory, design documentation should be done using purpose-built tools The problem: developers won’t/don’t read it or keep it up to date (is that true?) Possible solution Embed design specs into unit tests Run in automated build process
Copyright © 2013 by Mark J. Sebern UML Design Documentation ExternalInternal Static Class diagram with embedded descriptions Pre- & post-conditions, behavior descriptions Dynamic Use cases and UC/sequence/activity diagrams State diagrams Sanity check: Can we actually put this documentation into tests (unit, system)? Can some of it be put into the code (e.g., Javadoc)? Other suggestions? “Sometimes the simplest tool is a complex CASE tool. When it comes to requirements I prefer inclusive tools such as paper and whiteboards, but when it comes to design I tend to lean towards sophisticated tools which (re)generate code for me. Like my grandfather always said, you should use the right tool for the job.”inclusive toolsthe job.” Scott AmbleScott Ambler
Copyright © 2013 by Mark J. Sebern Questions?