Editing Code review (section)

== Review types ==

Several variations of code review processes exist, with additional types specified in [[IEEE 1028]].<ref>{{Cite book|title=IEEE Standard for Software Reviews and Audits|publisher=IEEE STD 1028-2008 |date=August 2008 |pages=1–53 |url=https://ieeexplore.ieee.org/document/4601584|doi=10.1109/ieeestd.2008.4601584|isbn=978-0-7381-5768-9 }}</ref>

* 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 (software designer)|Michael Fagan]].<ref name="fagan1976">{{cite journal |last1=Fagan |first1=Michael |title=Design and code inspections to reduce errors in program development |journal=IBM Systems Journal |date=1976 |volume=15 |issue=3 |pages=182–211|doi=10.1147/sj.153.0182 }}</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) ===
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">{{cite book |last1=Rigby |first1=Peter |title=Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering |last2=Bird |first2=Christian |date=2013 |isbn=9781450322379 |pages=202–212 |chapter=Convergent contemporary software peer review practices |citeseerx=10.1.1.641.1046 |doi=10.1145/2491411.2491444 |s2cid=11163811}}</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">{{cite journal |last1=MacLeod |first1=Laura |last2=Greiler |first2=Michaela |last3=Storey |first3=Margaret-Anne|last4=Bird |first4=Christian|last5=Czerwonka |first5=Jacek|title=Code Reviewing in the Trenches: Challenges and Best Practices |journal= IEEE Software |volume=35 |issue=4 |pages=34 |date=2017 |doi=10.1109/MS.2017.265100500 |s2cid=49651487 | url=https://www.michaelagreiler.com/wp-content/uploads/2019/03/Code-Reviewing-in-the-Trenches-Understanding-Challenges-Best-Practices-and-Tool-Needs.pdf | access-date=2020-11-28 }}</ref>
Google,<ref name="sadowskiicse18">{{cite book |last1=Sadowski|first1=Caitlin |last2=Söderberg|first2=Emma|last3=Church|first3=Luke|last4=Sipko|first4=Michal|last5=Baachelli|first5=Alberto|title=Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice |chapter=Modern code review: A case study at google |pages=181–190 |date=2018 |doi=10.1145/3183519.3183525|isbn=9781450356596 |s2cid=49217999 |doi-access=free}}</ref>
and Facebook.