1. Code review

2. informal formal ad hoc reviewpair programmingwalk throughinspection/review

3. CharacteristicWalkthroughReview Leaderauthormoderator Granularityat author’s discretionsmall chunks Recordermaybeyes Documented procedure maybeyes Specific participant roles noyes Defect checklistnoyes Data analyzednoyes Appraisal madenoyes

4. Effectiveness Studies: –formal review found 16-20 defects per KLOC vs. 3 per KLOG for walkthrough –formal review found 50% defects than walkthrough

5. Preparation prepare work products examine work products prepare review package ready for review? read package study work products prepare comments schedule review send out packages AuthorModerator Reviewers Y N

6. Work products Materials to be reviewed –use cases –class and sequence diagrams –code –test results –complexity risk analysis A proposed structure for the review –table of contents of work products –what will be reviewed and the order –what types of issues will be covered roadmap to code

7. Preparation prepare work products examine work products prepare review package ready for review? read package study work products prepare comments schedule review send out packages AuthorModerator Reviewers Y N

8. Preparation prepare work products examine work products prepare review package ready for review? read package study work products prepare comments schedule review send out packages AuthorModerator Reviewers Y N

9. Review package Intro Agenda Criteria

10. Review package - Intro Background –What project are we discussing –What do reviewers need to know about it history, key problems, important decisions, etc. –Where can reviewers find more info requirements, designs, analysis Goals for review –specific work products to be reviewed –scope (what is in/out of bounds) –what approval means

11. Review package - agenda The order materials will be reviewed.

12. Review - criteria These need to be determined by the author and moderator depending on the situation. For a code review you might consider: Does the UML realize the use cases? Does the code realize the UML? Does the code reflect good and consistent style? Is the code easy to understand? Is it simple but not “clever”? Is it documented as needed? Is the code efficient? Is error handling adequate? Are the underlying algorithm correct and correctly implemented? Do common errors occur? missing cases, off-by-one, etc.

13. Style Code appearance: indentation, alignment, whitespace, tabs Naming: appropriate choice of names Consistency: same style throughout

14. Preparation prepare work products examine work products prepare review package ready for review? read package study work products prepare comments schedule review send out packages AuthorModerator Reviewers Y N

15. Reviewer responsibility Each reviewer should have specific responsibility Review materials relevant to those responsibility Test executable

16. Review process Moderator –keeps review moving –ensures all voices are heard and key points covered –ensures decisions are made: accepted, major/minor revisions, further review Recorder –takes notes, records all issues raised and decisions reached, all questions, suggestions, and action items –publishes a report of the review

17. Review process cont. Reviewers –Each member leads on their portion of the code –When not leading, follow along, raise questions, concerns, point out problems Author –Answers questions but is otherwise silent

18. Review cont. Stick to specified level Avoid re-specifying/designing system Avoid getting sidetracked