Inspections

Front 1

Reviews

Back 1

management practice of meetings to informally consider state of the project at certain stages, in order to gain confidence in project direction

Front 2

Walkthroughs

Back 2

informal technical review, normally carried out by developers to improve product quality

Front 3

Inspections

Back 3

completely formal process of review - a formal system used to identify and remove defects, and improve the overall quality of the development process

Front 4

Defect Classification: Critical

Back 4

Defects that will cause the system to hang, crash, or produce incorrect results or behaviour, with no known workarounds

Front 5

Defect Classification: Severe

Back 5

Defects that will cause incorrect results or behaviour, but have known workarounds

Front 6

Defect Classification: Moderate

Back 6

Defects that affect limited areas of functionality that can either be
worked around or ignored

Front 7

Defect Classification: Minor

Back 7

Defects that can be overlooked without loss of functionality

Front 8

Checklists

Back 8

Checklists often include questions concerning completeness,
style, adherence to company standards, etc.
• Code inspection checklists often include detailed questions about use of language features (e.g., no gotos), naming of variables,
methods and classes, depth of nesting, etc.

Front 9

References

Back 9

may include Company standards documents, high quality examples of artifacts similar to the one being inspected, etc

Front 10

Code Checklists

Back 10

Give a concrete list of (general and specific, desired and undesired) properties of the code to check for

Inspector should look through the code to check for the presence or absence of each individual property, and check it off the list

Front 11

Code Paraphrasing

Back 11

Consists of reading the lines of code for their meaning (in English) in the problem domain, not in the programming language

Goal is to insure that the code really does implement what we want to have done

Front 12

Structured Code Walkthroughs

Back 12

Guided tour of the program, led by a “tour guide” who describes the points of interest etc.

Can be static or dynamic.

Front 13

Dynamic Code Walkthrough

Back 13

Conducted by the code reviewers in the meeting as a sort of exploration of the codeʼs workings

Front 14

Static Code Walkthrough

Back 14

Annotated version of the source code with the tour guideʼs comments shown alongside the code itself

Front 15

Lightweight inspection practices

Back 15

attempt to gain the advantages
of code inspections without the formal process, as in XP

Front 16

Four eyes principle

Back 16

Programmers work in loose pairs, where each module or class authored by one programmer is informally inspected by the other

(Both are equally responsible for the code).

Front 17

Chief Programmer Teams

Back 17

Involves weekly meetings in which the whole team informally reviews the system design, architecture, interfaces and schedule once each week, continuously updating
each of these as the project proceeds

Front 18

Extreme Programming - Continuous Inspection

Back 18

XPʼs code refactoring is a continuous inspection method descended from CPTʼs weekly design reviews

Front 19

White Box Testing (By Hand)

Back 19

When applied manually, most white box testing methods force the test author to examine the code in detail in order to create the tests - in practice this is how most defects are found

Front 20

Heavyweight inspection practices

Back 20

Formalize code inspection all the way to formal verification

Front 21

Cleanroom Software Development

Back 21

The main components are formal specification, and

Incremental development: software is partitioned into increments which are developed separately using the Cleanroom approach

Structured programming: only a limited number of control and data constructs are allowed to be used in the code

Stepwise refinement: code is developed directly as a refinement of the formal specification

Static verification: developed software components are not tested but statically verified using mathematically based correctness arguments

Front 22

Pair Programming - Code Inspection

Back 22

Continuous immediate inspection
of new code

Increases quality because all code being written is inspected

Increases productivity because it avoids the cognitive overhead of the programmer continually switching between the code level of understanding and higher level of understanding

Front 23

Pair Programming - Different Roles - The Driver

Back 23

Can confidently charge forward in the immediate coding task

Front 24

Pair Programming - Different Roles - The Partner

Back 24

Keeps track of the big picture - where whole thing is going (replaces paraphrasing) and watches for simple clerical and coding errors that may go unnoticed by the driver (replaces code checklists)

Front 25

Code Refactoring

Back 25

Improves the design of code without affecting its behaviour

Front 26

Code Refactoring - Abstracting

Back 26

The creation of a new method for a
repeated code section when the repetition is made

Front 27

Code Refactoring - Simplification

Back 27

Shortening code by joining similar
cases or removing redundancies when new cases are added

Front 28

Code Refactoring - Design Constraints

Back 28

1. The system (code plus tests) must communicate everything you want to communicate

2. The system must contain no duplicate code

3. The system should have the fewest possible classes

4. The system should have the fewest possible methods