Chapter 8: Design and code review - Coggle Diagram
Chapter 8: Design and code review
What are reviews?
Doing reviews is the most important step you can take to improve your software engineering performance
There are many ways to review software products. The principal ones are inspec tions, walk-throughs, and personal reviews.
An inspection is a structured procedure for the team review of a software product.
A typical inspection process has three phases:
Starts with a kick-off meeting to ensure all partici- pants understand the product to be reviewed, are informed of their roles in the inspection, and know how to perform those roles
Repair and report.
Calls for the repair of any product defects and the preparation and submission of an inspection report.
Involves the reviewers dis- cussing their findings with the program author and with each other
Design inspections and design re- views can similarly identify and fix problems early in the development process. These problems are easier and cheaper to fix during the design phase than they are later.
Why Review Programs?
Reviewing a program is like reviewing a draft paper. While some people feel they can write a perfect first draft, professional writers will tell you that the secret to good writing is rewriting
CODE REVIEWS ARE MORE EFFICIENT THAN TESTING
In reviews, you find the defects directly; in testing, however, you get only symptoms.
The time you spend to get from symptoms to defects is called debugging. Debugging is the process of finding the actual defect in the program that caused it to behave improperly.
The amount of debugging time will often bear little relation to the sophistication of the defect.
When you review a program, you know where you are and the results its logic is supposed to produce.
In debugging,you start with some unexpect ed system behavior.
NEEDLE IN THE HAYSTACK
If there were only one or two defects in a one-KLOC program, you might question the wisdom of studying every line to ensure its correctness.
Engineers carefully review their programs before they first compile or test them. If you want a quality product, you must spend the time to personally engineer it, review it, and rework it until you are satisfied with its quality
Once you see the data on the defect content of your programs, you can work to find and fix these defects in the most effective way. Following are the steps you should take to do this:
Gather data on your reviews, your compilations, and your tests.
Study these data to decide which defect removal methods work best for you.
Adjust your process to use these defect removal methods
Establish defined review goals
Doing design and code review before your first compile you will find many defects
Follow a defined review process
Requires entry criteria a set of tasks and exit criteria
Measure and improve your review process
You measure your reviews in order to improve their quality.
Separate Design and Code Reviews
To get high-quality reviews, you should review your design separately from your code,the reasons for doing this are as follows:
To make designs more understandable
To avoid missing product defects
To spot possible design improvements
To save implementation time
Design Review Principles
There are no hard and fast rules about the proper way to do design reviews. How- ever, I have found the following guidelines helpful:
Produce designs that can be reviewed
Follow an explicit review strategy.
Review the design in stages.
Verify that the logic correctly implements the requirements.
PRODUCE DESIGNS THAT CAN BE REVIEWED
For a design to be reviewable, its purpose and function must be explicitly stated.
In addition, the design description must be complete and precise.
FOLLOW AN EXPLICIT DESIGN REVIEW STRATEGY
You obviously can't review a design before you produce it. You will also want to review each design in conjunction with other related designs.
Doing this will help you to build a review context and to improve your ability to see cou- pling and interdependency issues
REVIEW THE DESIGN IN STAGES
Check to ensure you designed all the required program elements
Verify the overall program structure and flow
Check the program's logical constructs for correctness.
After you are reasonably sure the logic performs properly under normal
Check the function, method, and procedure calls to ensure all the correct parameters
Check all the special variables, parameters, data types, and files.
The four explicit review measures are
The review time in minutes
the size of the program being reviewed
The number of defects found
The number of defects in the program that were later found.
From these basic measures, you can derive several other useful measures. The most important ones are
the defects found per KLOC of design or code reviewed.
The defects found per hour of review time, the LOC reviewed per hour
Defect removal leverage (DRL), or the relative rate of defect removal for any two process phases.
The review yield, that is, the percentage of defects in the program found during the review
Ensure the code covers att the design by reviewing the main routine and each procedure to check that all the required functions are included
Check the main routine and each procedure to ensure the proper includes are entered for each library function.
Again think through the logic of the main routine and each procedure as you check inizialitation
REVIEWING AGAINST CODING STANDARDS
Your principal interest in a code review is to ensure all the details are properly handled. Here is where your coding standard can be a big help.
Reviewing before or after You Compile
One of the more contentious PSP issues is whether to review your code before or after you compile it. Some programmers refuse to consider reviewing their code before they do a first compile.
THE ARGUMENTS PRO AND CON
The reasons for compiting before doing a review are the following:
The compiler is highly effective. It will find about 90 percent of syntax and naming defects
Individual effectiveness varies. In spite of your best efforts, you will likely miss between 20 percent and 50 percent of your syntax defects.
The syntax defects missed by the compiler are generally not difficult to find in test.
The points that favor reviewing before compiling are as follows:
The compiler does miss about 9 percent of the syntax defects.
Finding the defects in the review will both save compile time and make it more predictable.
On average, it takes several times longer to fix syntax errors in test than it does in code review.
Unit testing typically finds about half a program's defects. If you count on the compiter to find all syntax problem
Typically, subsequent test phases have even lower yields than does unit test.