Using peer code review can improve code quality and makes the most of developers' time. Lightweight peer code reviews have been proven to be effective by scientific study and by extensive field experience.
Code reviews have two purposes.
1). To make sure that the code that is being produced has sufficient quality to be released.
2). As a teaching tool to help developers learn when and how to apply techniques to improve code quality, consistency, and maintainability.
It is common sense that peer code review – in which software developers review each other’s code before releasing software to QA – uncovers bugs, encourages collaboration, and keeps code more maintainable. This reduces rework for both development and test resources.
But it’s also clear that some code review techniques are inefficient and ineffective. The meetings often mandated by the review process take time and kill excitement. Strict process can stifle productivity, but lax process means no one knows whether reviews are effective or even happening.
2. Category
A quality-driven organization will practice a variety of peer review methods, spanning a spectrum of formality, rigor, effectiveness, and cost. Let’s look at descriptions of some common review approaches.
1). An inspection is the most systematic and rigorous type of peer review. Inspection follows a well-defined multistage process with specific roles assigned to individual participants. Inspections are more effective at finding defects than are informal reviews.
2). Team reviews are a type of "inspection-lite," being planned and structured but less formal and less rigorous than inspections. Typically, the overview and follow-up inspection stages are simplified or omitted, and some participant roles may be combined (e.g., moderator and reader).
3). A walkthrough is an informal review in which the work product’s author describes it to some colleagues and solicits comments. Walkthroughs differ significantly from inspections because the author takes the dominant role; other specific review roles are usually not defined. 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.
3. Roles and responsibility:
A. Reviewees
a) Explains application
b) Shares the content
c) Discusses solved problems.
B. Reviewers
a) Criticizes code against organization standards and goals
b) Tries to make suggestions on how to fix
C. Moderator - a reviewer who controls the meeting, not the content
4. Detailed process
1). Preparation-meeting-rework-followup
2). Use tools in all aspects of the review process:
Automated File-Gathering
Combined Display: Differences, Comments, Defects
Automated Metrics Collection
Some control over the workflow
There also are a few simple things that you can do to change the approach for the better:
1. Ask questions rather than make statements. "You didn't follow the standard here" is an attack—whether intentional or not. The question, "What was the reasoning behind the approached you used?" is seeking more information.
2. Avoid the "Why" questions. For example, "Why didn't you follow the standards here..." versus "What was the reasoning behind the deviation from the standards here..."
3. Remember to praise.
4. Make sure you have good coding standards to reference.
5. Make sure the discussion stays focused on the code and not the coder.
6. Remember that there is often more than one way to approach a solution. The goal is quality, maintainable code. If it meets those goals and follows the coding standards, that's all you can ask for.
7. Exploit code coverage and code analysis tools
8. Capture code issues in the backlog
9. The learning from a design issue or programmatic style problem is shared
10. Review fewer than 200-400 lines of code at a time.
11. Keep Review checklists (if used) short. Checklists substantially improve results for both authors and reviewers. Contain no items that are obvious or can be detected via automation, and should focus on things that are easy to forget (e.g. “Are all errors handled correctly everywhere?”).
As a developer:
Remember that the code isn't you. You need to strive to not get defensive.
Create a checklist for yourself of the things that the code reviews tend to focus on.
Help to maintain the coding standards.
Advantage of Coding Standards comes mostly from Consistent Use
评论