Code review: Difference between revisions

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
VisualWikitext
imported>OAbot
m Open access bot: url-access updated in citation with #oabot.
 
imported>SchlurcherBot
m Bot: http → https
 
Line 9: Line 9:
Although direct discovery of quality problems is often the main goal,<ref name="baum2017profes">{{cite book |last1=Baum |first1=Tobias |title=Product-Focused Software Process Improvement |last2=Leßmann |first2=Hendrik |last3=Schneider |first3=Kurt |date=2017 |isbn=978-3-319-69925-7 |series=Lecture Notes in Computer Science |volume=10611 |pages=111–127 |chapter=The Choice of Code Review Process: A Survey on the State of the Practice |doi=10.1007/978-3-319-69926-4_9}}</ref> code reviews are usually performed to reach a combination of goals:<ref name="bacchelli2013icse" /><ref name="baum2016fse">{{cite book |last1=Baum |first1=Tobias |title=Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2016 |last2=Liskin |first2=Olga |last3=Niklas |first3=Kai |last4=Schneider |first4=Kurt |date=2016 |isbn=9781450342186 |pages=85–96 |chapter=Factors Influencing Code Review Processes in Industry |doi=10.1145/2950290.2950323 |s2cid=15467294}}</ref>
Although direct discovery of quality problems is often the main goal,<ref name="baum2017profes">{{cite book |last1=Baum |first1=Tobias |title=Product-Focused Software Process Improvement |last2=Leßmann |first2=Hendrik |last3=Schneider |first3=Kurt |date=2017 |isbn=978-3-319-69925-7 |series=Lecture Notes in Computer Science |volume=10611 |pages=111–127 |chapter=The Choice of Code Review Process: A Survey on the State of the Practice |doi=10.1007/978-3-319-69926-4_9}}</ref> code reviews are usually performed to reach a combination of goals:<ref name="bacchelli2013icse" /><ref name="baum2016fse">{{cite book |last1=Baum |first1=Tobias |title=Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2016 |last2=Liskin |first2=Olga |last3=Niklas |first3=Kai |last4=Schneider |first4=Kurt |date=2016 |isbn=9781450342186 |pages=85–96 |chapter=Factors Influencing Code Review Processes in Industry |doi=10.1145/2950290.2950323 |s2cid=15467294}}</ref>


* ''Improving code quality'' {{snd}}Improve internal code quality and [[maintainability]] through better readability, uniformity, and understandability
* ''Improving code quality''{{snd}}Improve internal code quality and [[maintainability]] through better readability, uniformity, and [[software understanding|understandability]]
* ''Detecting [[Software bug|defects]]''{{snd}}Improve quality regarding external aspects, especially correctness, but also find issues such as performance problems, security vulnerabilities, and injected malware
* ''Detecting [[Software bug|defects]]''{{snd}}Improve quality regarding external aspects, especially correctness, but also find issues such as performance problems, security vulnerabilities, and injected malware
* ''Learning/Knowledge transfer''{{snd}}Sharing codebase knowledge, solution approaches, and quality expectations, both to the reviewers and the author
* ''Learning/Knowledge transfer''{{snd}}Sharing codebase knowledge, solution approaches, and quality expectations, both to the reviewers and the author
* ''Increase sense of mutual responsibility''{{snd}}Increase a sense of collective [[code ownership]] and solidarity
* ''Increase sense of mutual responsibility''{{snd}}Increase a sense of collective [[code ownership]] and solidarity
* ''Finding better solutions''{{snd}}Generate ideas for new and better solutions and ideas beyond the specific code at hand
* ''Finding better solutions''{{snd}}Generate ideas for new and better solutions and ideas beyond the specific code at hand
* ''Complying to QA guidelines, ISO/IEC standards''{{snd}}Code reviews are mandatory in some contexts, such as air traffic software and [[Safety-critical system|safety-critical]] software
* ''Complying with QA guidelines, ISO/IEC standards''{{snd}}Code reviews are mandatory in some contexts, such as air traffic software and [[Safety-critical system|safety-critical]] software


== Review types ==
== 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>
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 |doi=10.1109/ieeestd.2008.4601584|isbn=978-0-7381-5768-9 }}</ref>


* Management reviews
* Management reviews
Line 28: Line 28:
=== Inspection (formal) ===
=== 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"/>
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) ===
=== 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.
Software development teams typically adopt a more lightweight review process in which the scope of each review relates to changes to the codebase corresponding to 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"/>
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>
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|author3-link=Margaret-Anne Storey|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>
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.
and Facebook.
Line 40: Line 40:
== Efficiency and effectiveness ==
== Efficiency and effectiveness ==


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">{{cite web | title=Measuring Defect Potentials and Defect Removal Efficiency | first=Capers | last=Jones | publisher=Crosstalk, The Journal of Defense Software Engineering | date=June 2008 | url=http://www.crosstalkonline.org/storage/issue-archives/2008/200806/200806-0-Issue.pdf | access-date=2010-10-05 | archive-url=https://web.archive.org/web/20120806092322/http://www.crosstalkonline.org/storage/issue-archives/2008/200806/200806-0-Issue.pdf | archive-date=2012-08-06 | url-status=dead }}</ref><ref>{{cite journal|title=Embedded Software: Facts, Figures, and Future | journal=Computer | volume=42 | issue=4 | pages=42–52 | first1=Capers | last1=Jones | first2=Christof | last2=Ebert | date=April 2009 | doi=10.1109/MC.2009.118 | s2cid=14008049 }}</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>{{cite book | author = Jason Cohen | title = Best Kept Secrets of Peer Code Review (Modern Approach. Practical Advice.) | publisher = Smart Bear Inc. | year = 2006 | isbn = 978-1-59916-067-2 | url-access = registration | url = https://archive.org/details/bestkeptsecretso00jaso }}</ref>
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">{{cite web | title=Measuring Defect Potentials and Defect Removal Efficiency | first=Capers | last=Jones | publisher=Crosstalk, The Journal of Defense Software Engineering | date=June 2008 | url=http://www.crosstalkonline.org/storage/issue-archives/2008/200806/200806-0-Issue.pdf | access-date=2010-10-05 | archive-url=https://web.archive.org/web/20120806092322/http://www.crosstalkonline.org/storage/issue-archives/2008/200806/200806-0-Issue.pdf | archive-date=2012-08-06 | url-status=dead }}</ref><ref>{{cite journal|title=Embedded Software: Facts, Figures, and Future | journal=Computer | volume=42 | issue=4 | pages=42–52 | first1=Capers | last1=Jones | first2=Christof | last2=Ebert | date=April 2009 | doi=10.1109/MC.2009.118 | bibcode=2009Compr..42d..42E | s2cid=14008049 }}</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 faster and less costly.<ref>{{cite book | author = Jason Cohen | title = Best Kept Secrets of Peer Code Review (Modern Approach. Practical Advice.) | publisher = Smart Bear Inc. | year = 2006 | isbn = 978-1-59916-067-2 | url-access = registration | url = https://archive.org/details/bestkeptsecretso00jaso }}</ref>


Studies indicate that up to 75% of code review comments affect software evolvability and maintainability rather than functionality,<ref name="czerwonka2015 ">{{cite book | doi=10.1109/ICSE.2015.131 | url=https://www.michaelagreiler.com/wp-content/uploads/2019/02/Code-Reviews-Do-Not-Find-Bugs.-How-the-Current-Code-Review-Best-Practice-Slows-Us-Down.pdf | access-date=2020-11-28 | volume=2 | pages=27–28 | year=2015 | last1=Czerwonka | first1=Jacek  | last2=Greiler | first2=Michaela | last3=Tilford | first3=Jack | title=2015 IEEE/ACM 37th IEEE International Conference on Software Engineering | chapter=Code Reviews do Not Find Bugs. How the Current Code Review Best Practice Slows Us Down | isbn=978-1-4799-1934-5 | s2cid=29074469 }}</ref><ref>{{cite journal |doi=10.1109/TSE.2008.71 | citeseerx=10.1.1.188.5757 | url=http://lib.tkk.fi/Diss/2009/isbn9789512298570/article5.pdf | access-date=2012-03-21| title=What Types of Defects Are Really Discovered in Code Reviews? | journal=IEEE Transactions on Software Engineering | volume=35 | issue=3 | pages=430–448 | year=2009 | last1=Mantyla | first1=M.V. | last2=Lassenius | first2=C. | s2cid=17570489 }}</ref><ref name="bacchelli2013icse">{{cite web|title=Expectations, outcomes, and challenges of modern code review | first1=A| last1=Bacchelli| first2=C| last2=Bird|  publisher= Proceedings of the 35th IEEE/ACM International Conference On Software Engineering (ICSE 2013)| date=May 2013| url=http://sback.it/publications/icse2013.pdf | access-date=2015-09-02}}</ref><ref>{{cite web|title=Modern code reviews in open-source projects: which problems do they fix? | first1=M| last1=Beller| first2=A| last2=Bacchelli| first3=A| last3=Zaidman| first4=E| last4=Juergens|  publisher= Proceedings of the 11th Working Conference on Mining Software Repositories (MSR 2014)| date=May 2014| url=http://sback.it/publications/msr2014.pdf | access-date=2015-09-02}}</ref> suggesting that code reviews are an excellent tool for software companies with long product or system life cycles.<ref>{{cite web | title=Does the Modern Code Inspection Have Value? | first1=Harvey | last1=Siy | first2=Lawrence | last2=Votta | url=http://csalpha.ist.unomaha.edu/~hsiy/research/sm.pdf | date=2004-12-01 | access-date=2015-02-17 | website=unomaha.edu | url-status=dead | archive-url=https://web.archive.org/web/20150428192217/http://csalpha.ist.unomaha.edu/~hsiy/research/sm.pdf | archive-date=2015-04-28 }}</ref> Therefore, less than 15% of issues discussed in code reviews relate directly to bugs.<ref name="bosu2015msr">{{cite web |title=Characteristics of Useful Code Reviews: An Empirical Study at Microsoft | first1=Amiangshu| last1=Bosu | first2=Michaela | last2=Greiler | first3=Chris | last3=Bird |  publisher= 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories | date=May 2015| url=https://www.michaelagreiler.com/wp-content/uploads/2019/02/Characteristics-Of-Useful-Comments.pdf | access-date=2020-11-28}}</ref>
Studies indicate that up to 75% of code review comments affect software evolvability and maintainability rather than functionality,<ref name="czerwonka2015 ">{{cite book | doi=10.1109/ICSE.2015.131 | url=https://www.michaelagreiler.com/wp-content/uploads/2019/02/Code-Reviews-Do-Not-Find-Bugs.-How-the-Current-Code-Review-Best-Practice-Slows-Us-Down.pdf | access-date=2020-11-28 | volume=2 | pages=27–28 | year=2015 | last1=Czerwonka | first1=Jacek  | last2=Greiler | first2=Michaela | last3=Tilford | first3=Jack | title=2015 IEEE/ACM 37th IEEE International Conference on Software Engineering | chapter=Code Reviews do Not Find Bugs. How the Current Code Review Best Practice Slows Us Down | isbn=978-1-4799-1934-5 | s2cid=29074469 }}</ref><ref>{{cite journal |doi=10.1109/TSE.2008.71 | citeseerx=10.1.1.188.5757 | url=http://lib.tkk.fi/Diss/2009/isbn9789512298570/article5.pdf | access-date=2012-03-21| title=What Types of Defects Are Really Discovered in Code Reviews? | journal=IEEE Transactions on Software Engineering | volume=35 | issue=3 | pages=430–448 | year=2009 | last1=Mantyla | first1=M.V. | last2=Lassenius | first2=C. | bibcode=2009ITSEn..35..430M | s2cid=17570489 }}</ref><ref name="bacchelli2013icse">{{cite web|title=Expectations, outcomes, and challenges of modern code review | first1=A| last1=Bacchelli| first2=C| last2=Bird|  publisher= Proceedings of the 35th IEEE/ACM International Conference On Software Engineering (ICSE 2013)| date=May 2013| url=https://sback.it/publications/icse2013.pdf | access-date=2015-09-02}}</ref><ref>{{cite web|title=Modern code reviews in open-source projects: which problems do they fix? | first1=M| last1=Beller| first2=A| last2=Bacchelli| first3=A| last3=Zaidman| first4=E| last4=Juergens|  publisher= Proceedings of the 11th Working Conference on Mining Software Repositories (MSR 2014)| date=May 2014| url=https://sback.it/publications/msr2014.pdf | access-date=2015-09-02}}</ref> suggesting that code reviews are an excellent tool for software companies with long product or system life cycles.<ref>{{cite web | title=Does the Modern Code Inspection Have Value? | first1=Harvey | last1=Siy | first2=Lawrence | last2=Votta | url=http://csalpha.ist.unomaha.edu/~hsiy/research/sm.pdf | date=2004-12-01 | access-date=2015-02-17 | website=unomaha.edu | url-status=dead | archive-url=https://web.archive.org/web/20150428192217/http://csalpha.ist.unomaha.edu/~hsiy/research/sm.pdf | archive-date=2015-04-28 }}</ref> Therefore, less than 15% of issues discussed in code reviews relate directly to bugs.<ref name="bosu2015msr">{{cite web |title=Characteristics of Useful Code Reviews: An Empirical Study at Microsoft | first1=Amiangshu| last1=Bosu | first2=Michaela | last2=Greiler | first3=Chris | last3=Bird |  publisher= 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories | date=May 2015| url=https://www.michaelagreiler.com/wp-content/uploads/2019/02/Characteristics-Of-Useful-Comments.pdf | access-date=2020-11-28}}</ref>


=== Guidelines ===
=== Guidelines ===


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">{{cite journal|last1=Kemerer|first1=C.F.|last2=Paulk|first2=M.C.|title=The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data|journal=IEEE Transactions on Software Engineering|date=2009-04-17|volume=35|issue=4|pages=534–550|doi=10.1109/TSE.2009.27|hdl=11059/14085 |s2cid=14432409|hdl-access=free}}</ref><ref>{{cite web|title=Code Review Metrics|url=https://www.owasp.org/index.php/Code_Review_Metrics#Inspection_Rate|website=Open Web Application Security Project|access-date=9 October 2015|archive-url=https://web.archive.org/web/20151009202719/https://www.owasp.org/index.php/Code_Review_Metrics|archive-date=2015-10-09}}</ref><ref>{{cite web|title=Best Practices for Peer Code Review|url=http://smartbear.com/all-resources/articles/best-practices-for-peer-code-review/|website=Smart Bear|publisher=Smart Bear Software|access-date=9 October 2015|archive-url=https://web.archive.org/web/20151009202810/http://smartbear.com/all-resources/articles/best-practices-for-peer-code-review/|archive-date=2015-10-09}}</ref><ref name="Bisant 1989">{{cite journal|last1=Bisant|first1=David B.|title=A Two-Person Inspection Method to Improve Programming Productivity|journal=IEEE Transactions on Software Engineering|date=October 1989|volume=15|issue=10|pages=1294–1304|doi=10.1109/TSE.1989.559782|s2cid=14921429|url=http://dl.acm.org/citation.cfm?id=77604|access-date=9 October 2015|url-access=subscription}}</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>{{cite web|title=A Guide to Code Inspections | first=Jack | last=Ganssle | publisher= The Ganssle Group | date=February 2010 | url=http://www.ganssle.com/inspections.pdf | access-date=2010-10-05}}</ref>
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">{{cite journal|last1=Kemerer|first1=C.F.|last2=Paulk|first2=M.C.|title=The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data|journal=IEEE Transactions on Software Engineering|date=2009-04-17|volume=35|issue=4|pages=534–550|doi=10.1109/TSE.2009.27|bibcode=2009ITSEn..35..534K |hdl=11059/14085 |s2cid=14432409|hdl-access=free}}</ref><ref>{{cite web|title=Code Review Metrics|url=https://www.owasp.org/index.php/Code_Review_Metrics#Inspection_Rate|website=Open Web Application Security Project|access-date=9 October 2015|archive-url=https://web.archive.org/web/20151009202719/https://www.owasp.org/index.php/Code_Review_Metrics|archive-date=2015-10-09}}</ref><ref>{{cite web|title=Best Practices for Peer Code Review|url=http://smartbear.com/all-resources/articles/best-practices-for-peer-code-review/|website=Smart Bear|publisher=Smart Bear Software|access-date=9 October 2015|archive-url=https://web.archive.org/web/20151009202810/http://smartbear.com/all-resources/articles/best-practices-for-peer-code-review/|archive-date=2015-10-09}}</ref><ref name="Bisant 1989">{{cite journal|last1=Bisant|first1=David B.|title=A Two-Person Inspection Method to Improve Programming Productivity|journal=IEEE Transactions on Software Engineering|date=October 1989|volume=15|issue=10|pages=1294–1304|doi=10.1109/TSE.1989.559782|s2cid=14921429|url=http://dl.acm.org/citation.cfm?id=77604|access-date=9 October 2015|url-access=subscription}}</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>{{cite web|title=A Guide to Code Inspections | first=Jack | last=Ganssle | publisher= The Ganssle Group | date=February 2010 | url=https://www.ganssle.com/inspections.pdf | access-date=2010-10-05}}</ref>


=== Supporting tools ===
=== Supporting tools ===


[[Static code analysis]] software assist reviewers by automatically checking source code for known vulnerabilities and defect patterns, particularly for large chunks of code.<ref>{{Cite book | doi=10.1109/ICSE.2013.6606642 | isbn=978-1-4673-3076-3 | chapter=Reducing human effort and improving quality in peer code reviews using automatic static analysis and reviewer recommendation | title=2013 35th International Conference on Software Engineering (ICSE) | pages=931–940 | year=2013 | last1=Balachandran | first1=Vipin | s2cid=15823436 }}</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>{{cite web|title=Automated Defect Prevention for Embedded Software Quality | last=VDC Research| publisher = VDC Research| date=2012-02-01 | url=http://alm.parasoft.com/embedded-software-vdc-report/ | access-date=2012-04-10}}</ref>
[[Static code analysis]] tools assist reviewers by automatically checking source code for known vulnerabilities and defect patterns, particularly for large chunks of code.<ref>{{Cite book | doi=10.1109/ICSE.2013.6606642 | isbn=978-1-4673-3076-3 | chapter=Reducing human effort and improving quality in peer code reviews using automatic static analysis and reviewer recommendation | title=2013 35th International Conference on Software Engineering (ICSE) | pages=931–940 | year=2013 | last1=Balachandran | first1=Vipin | s2cid=15823436 }}</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>{{cite web|title=Automated Defect Prevention for Embedded Software Quality | last=VDC Research| publisher = VDC Research| date=2012-02-01 | url=http://alm.parasoft.com/embedded-software-vdc-report/ | access-date=2012-04-10}}</ref>


== See also ==
== See also ==

Latest revision as of 21:44, 28 November 2025

Template:Short description Template:Sidebar with collapsible lists

File:Pair Programming 3.jpg
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.[1][2]

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.[1]

Goal

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

  • Improving code qualityTemplate: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 with QA guidelines, ISO/IEC standardsTemplate:SndCode reviews are mandatory in some contexts, such as air traffic software and safety-critical software

Review types

Several variations of code review processes exist, with additional types specified in IEEE 1028.[6]

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

Inspection (formal)

The first code review process that was studied and described in detail was called "Inspection" by its inventor, Michael Fagan.[7] 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.[7]

Regular change-based code review (Walk-throughs)

Software development teams typically adopt a more lightweight review process in which the scope of each review relates to changes to the codebase corresponding to a ticket, user story, commit, or some other unit of work.[8][3] 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".[1] 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.[3] Major software corporations known to use changed-based code review include Microsoft,[9] Google,[10] and Facebook.

Efficiency and effectiveness

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%.[11][12] A code review case study published in the book Best Kept Secrets of Peer Code Review contradicted the Capers Jones study,[11] finding that lightweight reviews can uncover as many bugs as formal reviews while being faster and less costly.[13]

Studies indicate that up to 75% of code review comments affect software evolvability and maintainability rather than functionality,[14][15][4][16] suggesting that code reviews are an excellent tool for software companies with long product or system life cycles.[17] Therefore, less than 15% of issues discussed in code reviews relate directly to bugs.[18]

Guidelines

Research indicates review effectiveness correlates with review speed. Optimal code review rates range from 200 to 400 lines of code per hour.[19][20][21][22] 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.[19][23]

Supporting tools

Static code analysis tools assist reviewers by automatically checking source code for known vulnerabilities and defect patterns, particularly for large chunks of code.[24] 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.[25]

See also

External links

References

<templatestyles src="Reflist/styles.css" />

  1. ↑ a b c Script error: No such module "citation/CS1".
  2. ↑ Script error: No such module "citation/CS1".
  3. ↑ a b c Script error: No such module "citation/CS1".
  4. ↑ a b Script error: No such module "citation/CS1".
  5. ↑ Script error: No such module "citation/CS1".
  6. ↑ Script error: No such module "citation/CS1".
  7. ↑ a b Script error: No such module "Citation/CS1".
  8. ↑ Script error: No such module "citation/CS1".
  9. ↑ Script error: No such module "Citation/CS1".
  10. ↑ Script error: No such module "citation/CS1".
  11. ↑ a b Script error: No such module "citation/CS1".
  12. ↑ Script error: No such module "Citation/CS1".
  13. ↑ Script error: No such module "citation/CS1".
  14. ↑ Script error: No such module "citation/CS1".
  15. ↑ Script error: No such module "Citation/CS1".
  16. ↑ Script error: No such module "citation/CS1".
  17. ↑ Script error: No such module "citation/CS1".
  18. ↑ Script error: No such module "citation/CS1".
  19. ↑ a b Script error: No such module "Citation/CS1".
  20. ↑ Script error: No such module "citation/CS1".
  21. ↑ Script error: No such module "citation/CS1".
  22. ↑ Script error: No such module "Citation/CS1".
  23. ↑ Script error: No such module "citation/CS1".
  24. ↑ Script error: No such module "citation/CS1".
  25. ↑ Script error: No such module "citation/CS1".

Script error: No such module "Check for unknown parameters".

Retrieved from "http://debianws.lexgopc.com/wiki143/index.php?title=Code_review&oldid=4992386"