Download Untitled

Many developers are eager to learn and improve their coding style, either on their own or with the help of a mentor
or peer group. It is common to reach a plateau at which a developer becomes comfortable with a particular design pattern
or toolset; after that point, the developer is less likely to explore alternate styles. Peer interaction is a great
motivational tool, and peer reviews are an excellent method of learning and improving development skills, including
style. Moreover, peer reviews are an essential technique for enforcing a style convention within an organization.
Rule 10.8
Perform at least one peer review per project
Rule 10.9
Involve the following people in a peer review: project manager, lead developer, experienced peer, and an
inexperienced peer
Rule 10.10
Bring the requirements specification and style rules checklist to the peer review
The optimum number and frequency of peer reviews vary widely. Some factors to consider include the experience level
of the developer or team, application size and complexity, and primary objectives of the peer review. If you are part
of a multideveloper organization, always perform at least one peer review for each project. Involve the project manager,
the lead developer, and experienced as well as inexperienced developers. Each brings different perspectives, and each
contributes and benefits differently. The project manager understands the requirements from a functional perspective
and can monitor how those requirements are being implemented. This can help identify any functional limitations of a
specific software design. The lead developer is the software's primary architect and the direct beneficiary of the review.
An experienced peer who is familiar with the organization's style convention provides constructive feedback. An
inexperienced peer might contribute some new ideas and question existing methods, all while learning good style.
Additionally, consider inviting a domain expert to critique any subsystems of your application that are highly specialized.
For example, if a colleague is an expert in GUI design, ask her to participate in the review of your GUI. The same holds
true for network communications, data acquisition, image analysis, real-time control, and more. Be sure to keep the
requirements specification and style rules checklist on hand. These are important materials that are referenced throughout
the meeting.
Begin with a review of the critical requirements, including priorities. Next, discuss the top-level architecture and
justify the reason for it. This might include a presentation of a state diagram or other design method, followed by
a top-level source code walk-through. Then discuss each of the application's subsystems, such as high-level software
components and low-level device drivers. Every subsystem should be covered, including a discussion of the source code.
Discuss the data structures and messaging or communication protocols used to connect each high-level component or
subsystem. Also be sure to discuss the error handling strategy. Look for common mistakes, such as incomplete error trapping,
missing VI descriptions, and unnecessary operations within loops.
Rule 10.11
333