copyright © 2013 by mark j. sebern code & design reviews maybe it is time to revisit the...

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.


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


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?


Code Review Checklists

•What is a checklist?

• Pre-flight example

•Why?

• For code:

• Based on historical defects

•Used to guide review


Checklist Usage


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


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?


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?


UML Design Documentation



External Internal

StaticClass diagram with

embedded descriptions

Pre- & post-conditions, behavior

descriptions

DynamicUse cases and

UC/sequence/activity diagrams

State charts/diagrams


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



External Internal

StaticClass diagram with

embedded descriptions

Pre- & post-conditions, behavior

descriptions

DynamicUse 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.” Scott Ambler www.agilemodeling.com/essays/agileDesign.htm


Questions?

copyright © 2013 by mark j. sebern code & design reviews maybe it is time to revisit the...

Documents