Die Codeüberprüfung (der englischen Codeüberprüfung ) ist eine systematische Prüfung des Quellcodes von Software.
Es kann in einem Beitrag zu dem Prozess stattfindet verglichen werden Ausschüssen , mit dem Ziel, zu finden Fehler oder potenzielle Schwachstellen oder zu korrigieren Designfehler, um die Qualität, Wartbarkeit und Sicherheit der Software zu verbessern.
Eine Codeüberprüfung kann auf der Überprüfung (manuell oder automatisiert) der Einhaltung einer Reihe von Programmierregeln basieren.
Wenn die Codeüberprüfung seit langem als wirksames Mittel zur Verbesserung der Softwarequalität anerkannt ist, sind Unternehmen, die einen systematischen Ansatz implementiert haben, seit langem in der Minderheit. Es wird zunehmend zu einem vollständigen Schritt in jedem Softwareentwicklungsprozess, insbesondere bei agilen Methoden wie extremer Programmierung .
Hewlett-Packard bewertet die Kapitalrendite einer Codeüberprüfung mit 10 zu 1.
Die Überprüfung ist ungefähr zwei- bis viermal schneller als der Test und bietet eine bessere Fehlererkennungsrate: Komponententests 25%, Integrationstests 45%, Entwurfsüberprüfung 55%, Codeüberprüfung 60%.
Bei der Überprüfung werden jedoch nicht dieselben Fehler wie beim Test festgestellt.
Die Codeüberprüfung kann verschiedene Formen annehmen, mehr oder weniger formal. Das am besten geeignete Modell muss auf der Grundlage der Risikotoleranz des geprüften Codes ausgewählt werden.
Michael Fagan, ein leitender Angestellter bei IBM, formulierte 1976 eine Methode zur Überprüfung des Kodex, die auf der Einberufung mehrerer Prüfungssitzungen basiert. Ziemlich schwer, es durchschnittlich neun Mann erfordert Stunden für 200 Zeilen Code, ist es schwierig für die Gesamtheit des Codes zu systematisieren.
Tom Gilb und Dorothy Graham haben ebenfalls eine sehr beliebte Inspektionsmethode entwickelt.
Das Versionsverwaltungssystem kann so konfiguriert werden, dass eine E-Mail gesendet wird, in der alle am Quellbaum vorgenommenen Änderungen beschrieben werden. Die anderen Entwickler im Team haben dann die Möglichkeit, diese Änderungen zu überprüfen.
Diese Methode wirft Probleme bei der Qualitätssicherung auf : Wie kann man feststellen, ob eine Änderung überprüft wurde, ob die Kritik berücksichtigt wurde?
Die Überprüfung über die Schulter ist eine informelle Methode: Der Autor des Codes steuert die Überprüfung, indem er dem Prüfer die Änderungen vorlegt, die er im Quellcode vorgenommen hat.
Es hat den Vorteil, dass es einfach und schnell durchzuführen ist. Einer der Nachteile besteht darin, dass, da der Autor der Pilot der Überprüfung ist, möglicherweise ein Nebeneffekt fehlt, den er oder sie zum Zeitpunkt des Schreibens nicht bemerkt hatte.
Die vergleichende Wirksamkeit der Paarprogrammierung mit anderen Methoden zur Codeüberprüfung bleibt ein etwas kontroverses Thema. Es ist zum Beispiel möglich, dass das Paar keinen ausreichenden Abstand zum Code hat.
Zur Unterstützung der Codeüberprüfung steht Software zur Verfügung:
Einige freie Software:
Bei der statischen Programmanalyse werden Tools wie Lint und seine Nachfolger verwendet, um die Einhaltung einer Reihe von Programmierregeln zu überprüfen . Die statische Analyse ermöglicht die Automatisierung (Systematisierung) bestimmter Steuerelemente (Komplexität des Codes, Einhaltung der Codierungsregeln usw.), ermöglicht jedoch keine Überprüfung bestimmter abstrakterer Punkte (Wiederverwendbarkeit, Effizienz, Einhaltung der Spezifikationen usw.), die erforderlich sind manuelles Korrekturlesen.
Die statische Analyse und das Peer Review ergänzen sich daher und ermöglichen es, das Code Review qualitativ und quantitativ zu erweitern. Das statische Analysetool ermöglicht insbesondere das Auslagern der Überprüfung von Details und fördert eine globalere Vision des Systems, das während der Codeüberprüfung untersucht wurde.
Eine Checkliste ist ein Dokument, in dem die Punkte zusammengefasst sind, die bei der Codeüberprüfung vorrangig geprüft werden sollen.
Eine Checkliste sollte nicht mehr als zehn Elemente enthalten, die Grenze dessen, was sich ein normaler Mensch merken kann. Es ist daher notwendig:
Die Elemente sollten nur Dinge betreffen, die häufig vergessen werden: Zum Beispiel "Überprüfen, ob die Methode die Ressourcen für alle Fälle der Fehlerrückgabe ordnungsgemäß freigibt". Zu diesem Zweck können wir die letzten 100 oder 200 Fehlerkorrekturen analysieren, um die häufigsten Fehlerursachen zu finden, und sie in Checklistenelemente umwandeln.
Es wird dann interessant sein, die neuen Fehler nach Checklistenelementen zu klassifizieren (nicht zu vergessen eine Kategorie "keines dieser Elemente"). Wenn ein Element in der Checkliste kaum noch Fehler enthält (da eine Strategie zur Vermeidung dieses Problems aufgetreten ist), ist es an der Zeit, dieses Element durch die häufigste Fehlerursache in der Kategorie "Keine der oben genannten" zu ersetzen Artikel ".
Selbstlesend oder persönliche Codeüberprüfung besteht für einen Entwickler darin, Codeüberprüfungsmethoden (insbesondere eine Checkliste) in seiner Softwareproduktion zu verwenden, um Fehler zu erkennen und zu korrigieren.
Eine bei Cisco durchgeführte Studie ergab, dass die vom Autor erstellten Überprüfungen (Anmerkung zu den im Quellcode vorgenommenen Änderungen) viel weniger Fehler ergaben. Es wurden zwei Hypothesen aufgestellt:
Diese Studie zeigt, dass die optimistische Hypothese bevorzugt wird.
Durch die kontinuierliche Integration kann ein statischer Analyseschritt und / oder eine Peer-Review für jeden neuen eingebetteten Code systematisiert werden.
Das Team sollte eine Kultur des Teilens des Quellcodes entwickeln und Diskussionen über den Code anregen. Die Leute nehmen sich nur ungern Zeit, um zu verstehen, wie komplexer Code funktioniert. Daher ist das Feedback in diesem Fall sehr allgemein.
Für einen Mitarbeiter ist es schwierig, seinem Chef mitzuteilen, dass einer seiner Kollegen einen schlechten Job gemacht hat. Das Management muss daher ein für die Fehlererkennung günstiges Klima entwickeln: Fehler sind ein normaler Prozess, kein einzelner Fehler. Es ist wichtig, sich nicht schuldig zu fühlen, sondern sich zum Beispiel auf Teamarbeit zu konzentrieren: Entscheidend ist die endgültige Qualität der Software.
Entwickler müssen lernen, ihr Ego zu kontrollieren und zwischen Codekritik und persönlicher Kritik zu unterscheiden. Sie müssen Menschen berücksichtigen, die ihre Arbeit nicht zeigen wollen.
Das Management muss auch davon überzeugt sein, wie wichtig es ist, Ressourcen für das Korrekturlesen bereitzustellen.
Metriken werden verwendet, um die Wirksamkeit der Überprüfung zu messen.
Mögliche Metriken:
Dies ermöglicht es beispielsweise, die Fehlerdichte pro Codezeile, die durchschnittliche Inspektionsgeschwindigkeit einer Codezeile oder die Zeit zum Erkennen eines Fehlers zu berechnen.
Eine groß angelegte Messung bei Cisco ergab Folgendes: