Английская Википедия:Code review

Содержание

Текст

Текст

Текст

Текст

Текст

Текст

Текст

Текст

Текст

Шаблон:Short description Шаблон:Software development process Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or more people check a program, mainly by viewing and reading parts of its source code, either after implementation or as an interruption of implementation. At least one of the persons must not have authored the code. The persons performing the checking, excluding the author, are called "reviewers".

Although direct discovery of quality problems is often the main goal, code reviews are usually performed to reach a combination of goals:

• Better code qualityШаблон:SndImprove internal code quality and maintainability (such as readability, uniformity, and understandability)
• Finding defectsШаблон:SndImprove quality regarding external aspects, especially correctness, but also find issues such as performance problems, security vulnerabilities, and injected malware
• Learning/Knowledge transferШаблон:SndHelp transfer codebase knowledge, solution approaches, and quality expectations, both to the reviewers and the author
• Increase sense of mutual responsibilityШаблон:SndIncrease a sense of collective code ownership and solidarity
• Finding better solutionsШаблон:SndGenerate ideas for new and better solutions and ideas that transcend the specific code at hand
• Complying to QA guidelines, ISO/IEC standardsШаблон:SndCode reviews are mandatory in some contexts, such as air traffic software and safety-critical software

This definition of code review distinguishes it from related software quality assurance techniques, such as static code analysis, self checks, testing, and pair programming. In static code analysis the main checking is performed by an automated program, in self checks only the author checks the code, in testing the execution of the code is an integral part, and pair programming is performed continuously during implementation and not as a separate step.

Review types

There are many variations of code review processes, some of which are detailed below. Additional review types are part of IEEE 1028.

IEEE 1028-2008 lists the following review types:

• Management reviews
• Technical reviews
• Inspections
• Walk-throughs
• Audits

Inspection (formal)

Historically, the first code review process that was studied and described in detail was called "Inspection" by its inventor, Michael Fagan. This Fagan inspection is a formal process which involves a careful and detailed execution with multiple participants and multiple phases. Formal code reviews are the traditional method of review, in which software developers attend a series of meetings and review code line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects in the code under review.

Regular change-based code review (Walk-throughs)

In recent years,Шаблон:When many industry teams have introduced a more lightweight type of code review in which the scope of each review is based on the changes to the codebase performed in a ticket, user story, commit, or some other unit of work. Furthermore, there are rules or conventions that embed the review task into the development process (e.g., "every ticket must be reviewed"), commonly as part of a pull request, instead of explicitly planning each review. Such a review process is called "regular, change-based code review". There are many variations of this basic process. A survey among 240 development teams from 2017 found that 90% of the teams use a review process that is based on changes (if they use reviews at all), and 60% use regular, change-based code review. Also, most large software corporations such as Microsoft, Google, and Facebook follow a change-based code review process.

Efficiency and effectiveness of reviews

Capers Jones' ongoing analysis of over 12,000 software development projects showed that the latent defect discovery rate of formal inspection is in the 60-65% range. For informal inspection, the figure is less than 50%. The latent defect discovery rate for most forms of testing is about 30%. A code review case study published in the book Best Kept Secrets of Peer Code Review contradicted the Capers Jones study, finding that lightweight reviews can uncover as many bugs as formal reviews, but were faster and more cost-effective.

The types of defects detected in code reviews have also been studied. Empirical studies provide evidence that up to 75% of code review defects affect software evolvability/maintainability rather than functionality, suggesting that code reviews are an excellent tool for software companies with long product or system life cycles. This also means that less than 15% of the issues discussed in code reviews are related to bugs.

Guidelines

The effectiveness of code review was found to depend on the review speed. Code review rates should be between 200 and 400 lines of code per hour. Inspecting and reviewing more than a few hundred lines of code per hour for critical software (such as safety critical embedded software) may be too fast to find errors.

Supporting tools

Static code analysis software lessens the task of reviewing large chunks of code on the developer by systematically checking source code for known vulnerabilities and defect types. A 2012 study by VDC Research reports that 17.6% of the embedded software engineers surveyed currently use automated tools to support peer code review and 23.7% expect to use them within two years.

See also

• Committer
• Software review
• Software quality
• Best coding practices
• List of software development philosophies

External links

• Five Code Review Antipatterns (Java Magazine, Best of 2020)