Vrlo zanimljiva knjiga koja može poslužiti kao smjernica za uvođenje peer review programa u proces razvoja softvera. Kako navodi autor, dalje sve ovisi o specifičnim potrebama organizacije koja uvodi novi proces.
Kao i kod drugih vrsta promjena stvara se otpor, a ova knjiga na praktičan način donosi potencijalna rješenja kako taj otpor savladati. Niti od najboljeg procesa neće biti koristi ako ljudi koji bi to trebali provoditi nisu spremni na promjenu ili joj se aktivno protive.
Code review je definitivno dobra praksa i svi iz toga mogu samo naučiti.
Ovo je samo jedna od knjiga koju sam pročitao tijekom 2022. godine.
[1] The Quality Challenge
Often you are too close to your own work to spot errors you’ve made.
You need a fresh perspective -a pair of eyes that hasn’t seen the code before and a brain that thinks in a different way.
Looking Over the Shoulder
The term ‘peer review’ is sometimes misinterpreted to mean that people are evaluating a coworker’s performance. Not so – the point of any peer review is to critique a work product, not the individual who created it.
Quality Isn’t Quite Free
Reviews don’t slow the project – defects do.
Reviews are waste of time only if your work products do not contain defects the reviews could find.
The defects are there whether you look for them or not; it’s just a question of how much it will cost to fix them when they finally raise their ugly heads.
It is cheaper to prevent defects than to remove them after you have completed implementation or shipped the product.
If the cost of establishing and sustaining a review program, training your team, and holding reviews (the investment) is less than what you save through reduced rework and enhanced customer satisfaction (the return), you come out ahead.
A common perception is that peer reviews are a luxury that schedule-driven projects cannot afford. Yes, reviews take time, but whether they take too much time is a business issue.
‘Good enough’ quality means the product must be good enough for the customer to willingly use it more than once.
[2] A Little Help from Your Friends
If you’re going to hold successful peer reviews, you have to overcome this natural resistance to outside critique of your work.
Scratch Each Other’s Back
Egoless programming addresses the fact that people tie much of their perception of self-worth to their work. You can interpret a fault someone finds in an item you created as a shortcoming in yourself as a software developer – and perhaps even as a human being.
Reviews and Team Culture
Reviews can result in two undesirable attitudes… Some people become lax in their work because they’re relying on someone else to find their mistakes, just as some programmers expect testers to catch their errors. The other extreme to avoid is the temptation to perfect the product before you allow another pair of eyes to see it.
Reviewers should thoughtfully select the words they use to raise an issue, focusing on what they observed about the product.
To accelerate this culture change, managers should encourage and reward those who initially participate in reviews, regardless of the review outcome.
The attitude and behavior that managers exhibit towards reviews affect how well the reviews will work in an organization.
If reviews aren’t planned, they won’t happen.
Without visible and sustained commitment to peer reviews from managers, only those practitioners who believe reviews are important will perform them.
A dangerous situation arises when a manager wishes to use data collected from peer reviews to assess the performance of the authors.
Software metrics must never be used to reward or penalize individuals.
Factors that contribute to the underuse of reviews include lack of knowledge about reviews, cultural issues, and simple resistance to change, often masquerading as excuses.
People who don’t want to do reviews will expend considerable energy trying to explain why reviews don’t fit their culture, needs, or time constraints.
Four cultural paradigms found in software organizations: closed, open, synchronous, and random.
Guiding Principles for Reviews
All peer reviews should follow several basic principles:
– check your egos at the door
– keep the review team small
– find problems during reviews, but don’t try to solve them
– limit review meetings to about two hours
– require advance preparation
[3] Peer Review Formality Spectrum
Several kinds of peer reviews that span a range of formality and rigor.
The Formality Spectrum
I recommend that you begin performing inspections at the outset to gain experience so you can judge when a less formal review approach is appropriate and when it is not.
An inspection is the most systematic and rigorous type of review.
Inspection has been identified as a software industry best practice.
An important aspect of an inspection is that participants other than the work product’s author lead the meeting.
Inspections are especially important for high-risk products that must be as free of defects as possible.
Team reviews are a type of ‘inspection-lite’, being planned and structured but less formal and less rigorous than inspection. … The author might lead a team review, whereas in an inspection the author is not permitted to serve as the moderator.
A walkthrough is an informal review in which the author of a work product describes the product to a group of peers and solicits comments.
Walkthroughs are informal because they typically do not follow a defined procedure, do not specify exit criteria, require no management reporting, and generate no metrics.
Authors can use walkthroughs to test their ideas, brainstorm alternative solutions, and stimulate the creative aspects of the development process.
In pair programming, two developers work on the same program simultaneously at a single workstation.
Pair programming is not specifically a review technique. Instead, it is a software development strategy that relies on the synergy of two focused minds to create products superior in design, execution, and quality.
Peer desk check – infrequent compilations to find errors in the hope of ensuring a clean execution.
A desk check is a kind of self-review, not a peer review.
In a peer desk check (also known as a buddy check and pair reviewing), only one person besides the author examines the work product.
A peer desk check depends entirely on the single reviewer’s knowledge, skill, and self-discipline, so expect wide variability in results.
The peer desk check is the cheapest review approach.
A passaround or distribution is a multiple, concurrent peer desk check. Instead of asking just one colleague for input, the author delivers a copy of the product to several people and collates their feedback.
Ad hoc reviews are the most informal type of review, having little impact beyond solving the immediate problem.
One way to select the most appropriate review method for a given situation is to consider risk: the likelihood that a work product contains defects and the potential for damage if it does.
[4] The Inspection Process
Inspector Roles
The most obvious role is that of the author, also called the producer or owner. The author usually created the work product being inspected, although he might be maintaining a product that someone else created.
The moderator works with the author to plan the inspection, keeps the meetings on track, and leads the inspection team to a successful outcome.
The reader (also known as the presenter) describes to the other participants the material being inspected during the inspection meeting. Logging the defects, issues, and comments raised during the meeting is the job of the recorder or scribe.
A fundamental characteristic of inspection is that the author is not permitted to serve as the moderator, reader, or recorder.
Although the author knows more about the product than anyone else does, he is too close to it to be objective. It’s hard for the author to remain egoless if he is controlling the inspection meeting or presenting the material to the other participants.
The reader typically paraphrases the work product, stating his interpretation in his own words.
The reader’s interpretation often reveals ambiguities, hidden assumptions, inadequate documentation, style problems that hamper communication, or outright errors.
Reading also gives at least one other inspector – the reader – a good understanding of the author’s work.
Rotate the reader role among your team members from one inspection to the next to share the burden of preparing for this challenging function.
Inspection Team Size
Keep your inspection teams small, between three and seven participants in most situations.
If the team is too large, distracting side discussions are likely to erupt.
The more people involved, the harder it is to schedule a meeting.
Inspection Process Stages
The author initiates planning by announcing that a deliverable will be soon ready for inspection.
The moderator is responsible for inviting the other participants.
The overview is typically conducted through an informal meeting in which the author describes the important features, assumptions, background, and context of the work product.
Defect detection begins during the individual preparation stage.
During the meeting, the reader describes the work product to the rest of the inspection team, one small portion at a time.
Issue log is the primary deliverable from the inspection meeting.
The next step is for the author to address each item on the issue log. The moderator might assign certain issues that arise during the meeting to people other than the author for resolution.
Typically, the moderator or another designed individual (the verifier) meets with the author to ensure that all issues and defects were resolved appropriately.
As with the other inspection activities, casual analysis is intended to explore shortcomings in the software development processes the team is using, not in the performance of individual team members.
Variations on the Inspection Theme
Measurement is a critical element of their inspection technique because it aids in determining and maximizing the return on investment from inspection.
Defect prevention is the ultimate reward from an inspection program.
Properly practiced, any inspection technique will give your team substantial improvements in quality, productivity, and knowledge exchange.
[5] Planning the Inspection
The first issue is to decide whether you really need an inspection.
When to Hold Inspections
Plan to inspect a work product when it reaches a completion milestone and is ready to be passed on to the next development step.
One company that began inspecting requirements specifications found that many inspection issues were questions of scope: does a specific requirement even belong in the product? If you resolve scope issues early in the project, people won’t waste time implementing unnecessary requirements.
The inspection Moderator
All of your team members should become comfortable with performing the roles of inspector, author, recorder, and reader. The moderator role, however, is more specialized.
The moderator plays a vital role in an effective inspection.
Avoid using nontechnical meeting facilitators to moderate inspections.
Also, do not allow anyone in the author’s management chain to moderate an inspection.
Selecting the Material
During the planning stage, the author and moderator decide whether to examine the entire deliverable or just selected portions.
Guidelines for choosing the artifacts to inspect:
– Fundamental and early-stage documents, such as requirements specifications and prototypes
– Documents on which critical decisions are based, such as architectural models that define the interfaces between major system components
– The parts you aren’t sure how to do, such as modules that implement unfamiliar or complex algorithms or enforce complicated business rules and other areas in which the developers lack experience or knowledge
– Components that will be used repeatedly
Inspection Entry Criteria
Entry criteria state the conditions that must be satisfied before you can execute a process with confidence of success.
One general entry criterion is that all participants have been trained in the inspection process.
For a reinspection, all issues from the previous inspection must have been resolved.
Assembling the Cast
Because inspections encompass both technical and social aspects, the success of an inspection depends heavily on who participates.
If you’re going to establish a successful inspection program in your organization, every team member must participate.
Consider whether interpersonal issues might inhibit the ability of certain individuals to inspect a particular author’s work.
The conventional wisdom is that managers may not inspect deliverables created by people who report to them. The rationale behind this restriction is that managers will be tempted to evaluate authors, even subconsciously, based on defects identified during the inspection.
Limit the presence of observers who do not actively contribute to the inspection. Observers increase the inspection’s cost while adding no value to the product.
The Inspection Package
The author should freeze the work product so it doesn’t change prior to the inspection meeting.
Inspection Rates
The more material the team covered in an hour, the fewer defects were discovered per page.
A single inspection meeting should not last more than about two hours.
Schedulig Inspection Events
Rather than using a fixed inspection schedule, allocate a portion of each week’s planned effort for inspections on an average basis, recognizing that some weeks will be busier than others.
[6] Examining the Work Product
The Overview Stage
The overview stage brings all inspection participants up to speed on the scope, purpose, context, history, and rationale of the initial deliverable.
The overview often is conducted as a meeting of 30 to 60 minutes in duration, which the author leads.
The primary goal of the overview is education.
The Preparation Stage
During preparation, all inspectors first read through the deliverable to make sure they understand it.
Preparation is especially critical for the reader and the recorder.
Preparation Approaches
The moderator can assign certain preparation objectives to specific inspectors to exploit their specialized technical knowledge or to ensure that all checklist items are addressed.
You don’t want everyone to look closely at the first one-third of a large work product, a few to get to the middle third, and just one stalwart inspector to flip through the final portion.
One disadvantage of having inspectors prepare in different ways is that you must rely on all of them to prepare effectively because there is no redundancy on which to fall back.
Checklists that identify typical defects found in various software work products are an important part of an organization’s inspection infrastructure.
Checklists are usually written in the form of questions for the inspector to ask about the deliverable he is examining, grouped into logical categories.
Rule sets provide an objective way for an inspector to judge whether a work product is correct and complete. Rule violations are defects.
Selecting appropriate analysis techniques from a palette of options is more powerful than always using checklist or just reading through the work product.
Evaluating requirements for testability reveals incomplete, ambiguous, and inconsistent requirements.
Perspective-based reading (PBR) defines steps that inspectors can follow when reading a specific type of document to improve their understanding of it and look for problems.
Scenarios are procedures that help inspectors find specific types of defects, such as missing requirements, inconsistencies, ambiguities, or incorrect functionality.
Missing requirements are among the most difficult requirement problems to detect.
An inspection that identifies unnecessary requirements pays for itself by reducing the project’s development effort.
Inspections can be applied to screenshots, prototypes, paper prototypes, and user interface architecture dedigns such as dialog maps.
Rather than reading sequentially through the code listing, inspectors traverse the hierarchical structure of the code, following function calls down the call tree as they are encountered.
[7] Putting Your Heads Together
The Moderator’s Role
The moderator leads the inspection meeting and plays a major part in a successful inspection.
Launching the Meeting
If the moderator judges that some participants are not properly prepared, he has the authority – and the responsibility – to reschedule the meeting.
The moderator should follow up with inspectors who did not submit any defects. If those inspectors didn’t prepare, either they do not attend the inspection meeting or the moderator reschedules the meeting for a later date.
Conducting the Meeting
Inspection meetings are draining and stressful, even when performed professionally by experienced participants.
During preparation, the reader chooses the most effective sequence and technique for presenting the material being inspected.
The moderator should watch the participant’s body language. A furrowed brow suggests that an inspector is confused or is contemplating making a comment.
Check the body language to see if the inspectors seem to be tuning out, tapping their feet in irritation, or displaying that „come on, let’s move along!“ facial expression.
Most commonly, the reader pauses briefly after presenting each section of material to permit inspectors to offer comments.
An alternative is to use a round-robin approach, asking each inspector in turn for his observation after the reader has presented each section.
[8] Bringing Closure
The Rework Stage
The author must address every issue on the inspection issue log and typo lists received from the inspectors.
The Follow-Up Stage
One purpose of follow-up is to verify that the author resolved all open issues from the inspection meeting appropriately.
Tracking inspection issues to closure is a characteristic of a mature inspection process.
A second objective of follow-up is to determine that the changes made in the initial deliverable were made correctly, without introducing secondary defects.
Inspection Exit Criteria
When you reach this point of stability in your inspections and your development processes, you can predict approximately how much material you can inspect per hour and how many defects you are likely to find.
[9] Analyzing Inspection Data
Why Collect Data?
Data answers important questions, provides quantifiable insights and historical perspective, and lets you base decisions on facts instead of perceptions or memories.
Don’t make your measurement process so elaborate that it inhibits the inspections themselves. Establishing a peer review culture and finding bugs is more important than meticulously recording masses of data.
Some Measurement Caveats
The first time a practitioner is punished for some data he reported is the last time the manager will get accurate data. Word of such misuse of the data spreads quickly among the other team members.
Beware the phenomenon known as measurement dysfunction. Measurement dysfunction arises when the measurement process or the ways in which managers use the data lead to counterproductive behaviors by the people providing the data.
Measuring the Impact of Inspections
A general heuristic is that each major defect that is not found by inspection requires an average of about nine to ten hours to correct later on.
[10] Installing a Peer Review Program
Simply knowing the mechanics of inspections and other types of peer review doesn’t guarantee that everyone will perform them routinely or effectively.
The Peer Review Process Owner
Look for a manager who strongly believes in reviews and is willing to devote energy to making the program succeed.
If no one has responsibility for adjusting the process, improvements won’t be made when the early adopters encounter problems.
Prepairing the Organization
Expect to hear, „We’re already too busy; we don’t have time for reviews,“ both as a genuine concern and as a sign of resistance.
Don’t waste a lot of energy trying to convert people who aren’t going to be willing review participants no matter what you say or do. The train is coming through; they can get on board or get out of the way.
Establishing and sustaining a new process in a software organization. First, you need a documented process.
If you’re serious about incorporating reviews into routine use, issue a written review policy.
A policy without accountability is merely a suggestion.
A meaningful policy demands management commitment at all levels. If your project manager isn’t interested in reviews despite the organizational policy, you’ll conduct reviews only if they are personally important to you.
The bottom line from any process improvement effort is that the team members apply the new practices routinely, not just when it is convenient or when someone reminds them.
Process Assets
Don’t expect your team members to perform peer reviews effectively unless they have a written process description and supporting work aids, collectively termed process assets.
At a minimum, start with one review procedure and the basic review forms.
Rather than trying to devise the ultimate review process right out of the gate, start with a non-intimidating process that provides a solid foundation on which your review program can grow.
The Peer Review Coordinator
Organizations should identify an individual to coordinate the program on a day-to-day basis.
The ideal peer review coordinator is an experienced inspector and moderator who thoroughly understands the technical and social aspects of reviews.
Moderators give him the size, time, effort, and defect data from their inspections, and he generates summary reports and analyzes the metrics. Based on this data analyzis, the coordinator offers process improvement suggestions.
Peer Review Training
It’s demoralizing for developers to walk out of a seminar motivated to use new software practices, only to face resistance from a manager who doesn’t understand or value the new techniques.
Piloting the Review Process
New processes that look good on paper often require adjustment in practice.
[11] Making Peer Reviews Work for You
Weaving peer reviews into the cultural fabric of an organization takes time.
Critical Success Factors
The people involved and their attitude toward quality are the greatest contributions to a review program’s success.
Even motivated team members will struggle to perform reviews if you don’t obtain management commitment.
Critical elements:
– Train reviewers and review leaders
– Allocate time in the project plan for reviews and rework
– Set goals for the review program
– Identify a review champion
– Review early and often, formally and informally
– Analyze your early reviews
Review Traps to Avoid
Participants don’t understand the review process.
The review process isn’t followed.
The right people do not participate.
Review meetings drift into problem-solving.
Reviewers focus on style, not substance.
Troubleshooting Review Problems
People who strongly oppose the review program can damage it, but don’t be held captive by the most recalcitrant members of your organization. If managers and opinion leaders instill pride of craftsmanship and an appreciation of software engineering best practices in the organization, most team members will give reviews a try.
[12] Special Review Challenges
Large Work Products
To get the greatest return from your review investment, use risk analysis to identify the components in which undetected errors could cause the greatest future problems.
Sampling portions of a large work product provides an indication of its overall quality and helps you judge whether it’s worth looking carefully at more than just a few pages.
Generated and Nonprocedural Code
There is little point in manually reviewing code generated by graphical user interface builders, visual development tools, and the like.
Too Many Participants
Sometimes people invite themselves to inspections for political or managerial, not technical reasons.
