Code review

Template:Short description Template:Software development process

Software Engineers (Template:Aka programmers) reviewing a program

Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or more people examine the source code of a computer program, either after implementation or during the development process. The persons performing the checking, excluding the author, are called "reviewers". At least one reviewer must not be the code's author.<ref name="baum2016qrs">Template:Cite book</ref><ref name="best_practices">Template:Cite book</ref>

Code review differs from related software quality assurance techniques like static code analysis, self-checks, testing, and pair programming. Static analysis relies primarily on automated tools, self-checks involve only the author, testing requires code execution, and pair programming is performed continuously during development rather than as a separate step.<ref name="baum2016qrs"/>

GoalEdit

Although direct discovery of quality problems is often the main goal,<ref name="baum2017profes">Template:Cite book</ref> code reviews are usually performed to reach a combination of goals:<ref name="bacchelli2013icse" /><ref name="baum2016fse">Template:Cite book</ref>

Improving code quality Template:SndImprove internal code quality and maintainability through better readability, uniformity, and understandability
Detecting defectsTemplate:SndImprove quality regarding external aspects, especially correctness, but also find issues such as performance problems, security vulnerabilities, and injected malware
Learning/Knowledge transferTemplate:SndSharing codebase knowledge, solution approaches, and quality expectations, both to the reviewers and the author
Increase sense of mutual responsibilityTemplate:SndIncrease a sense of collective code ownership and solidarity
Finding better solutionsTemplate:SndGenerate ideas for new and better solutions and ideas beyond the specific code at hand
Complying to QA guidelines, ISO/IEC standardsTemplate:SndCode reviews are mandatory in some contexts, such as air traffic software and safety-critical software

Review typesEdit

Several variations of code review processes exist, with additional types specified in IEEE 1028.<ref>Template:Cite book</ref>

Management reviews
Technical reviews
Inspections
Walk-throughs
Audits

Inspection (formal)Edit

Historically, the first code review process that was studied and described in detail was called "Inspection" by its inventor, Michael Fagan.<ref name="fagan1976">Template:Cite journal</ref> Fagan inspection is a formal process that involves a careful and detailed execution with multiple participants and phases. In formal code reviews, software developers attend a series of meetings to examine code line by line, often using printed copies. Research has shown formal inspections to be extremely thorough and highly effective at identifying defects.<ref name="fagan1976"/>

Regular change-based code review (Walk-throughs)Edit

Software development teams typically adopt a more lightweight review process in which the scope of each review is on the changes to the codebase performed in a ticket, user story, commit, or some other unit of work.<ref name="rigby2013fse">Template:Cite book</ref><ref name="baum2017profes" /> Furthermore, there are rules or conventions that integrate the review task into the development workflow through conventions like mandatory review of all tickets, commonly as part of a pull request, instead of explicitly planning each review. Such a process is called "regular, change-based code review".<ref name="baum2016qrs"/> There are many variations of this basic process.

A 2017 survey of 240 development teams found that 90% of teams using code review followed a change-based process, with 60% specifically using regular change-based review.<ref name="baum2017profes"/> Major software corporations known to use changed-based code review include Microsoft,<ref name="macleod2017ieee">Template:Cite journal</ref> Google,<ref name="sadowskiicse18">Template:Cite book</ref> and Facebook.

Efficiency and effectivenessEdit

Ongoing research by Capers Jones analyzing over 12,000 software development projects found formal inspections had a latent defect discovery rate of 60-65%, while informal inspections detected fewer than 50% of defects. The latent defect discovery rate for most forms of testing is about 30%.<ref name="jones08">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>Template:Cite journal</ref> A code review case study published in the book Best Kept Secrets of Peer Code Review contradicted the Capers Jones study,<ref name="jones08" /> finding that lightweight reviews can uncover as many bugs as formal reviews while being more efficient in terms of cost and money<ref>Template:Cite book</ref>

Studies indicate that up to 75% of code review comments affect software evolvability and maintainability rather than functionality,<ref name="czerwonka2015 ">Template:Cite book</ref><ref>Template:Cite journal</ref><ref name="bacchelli2013icse">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> suggesting that code reviews are an excellent tool for software companies with long product or system life cycles.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> Therefore, less than 15% of issues discussed in code reviews relate directly to bugs.<ref name="bosu2015msr">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

GuidelinesEdit

Research indicates review effectiveness correlates with review speed. Optimal code review rates range from 200 to 400 lines of code per hour.<ref name="Kemerer 2009">Template:Cite journal</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref name="Bisant 1989">Template:Cite journal</ref> 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.<ref name="Kemerer 2009" /><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

Supporting toolsEdit

Static code analysis software assist reviewers by automatically checking source code for known vulnerabilities and defect patterns, particularly for large chunks of code.<ref>Template:Cite book</ref> 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% plan to use them within two years.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

External linksEdit

ReferencesEdit

Template:Reflist