Code-Reviews


Allgemeiner Hinweis
Die folgende Beschreibung baut auf den ausführlichen Leitfaden zur Planung, Durchführung und Dokumentation von Reviews auf, der von PSE QM herausgegeben wurde. Zur Unterstützung von Reviews gibt es eigene Reviewformulare für Kommentar- und Sitzungstechnik (Winword-Files).

Was ist ein Review?
Hier die gebräuchlichste Definition:
Ein Review ist eine systematische, kritische, dokumentierte Prüfung von Entwicklungsergebnissen am Ende von definierten Arbeitsschritten. Es wird dabei das Ziel verfolgt, Fehler zu finden.

Was heißt Code-Review?
Als Entwicklungsergebnis wird in diesem Fall Source-Code verstanden, wie zum Beispiel:

  • C-Code einer Komponente
  • Assemblercode eines Hardware-Schnittstellenmoduls
  • C++ - Code einer Anwendung
  • ...

Was heißt Ende eines definierten Arbeitsschrittes?
Ein Review ist nur dann sinnvoll, wenn das Code-Stück auch tatsächlich fertig ist, d.h. den nötigen Reifegrad zur Überprüfung aufweisen kann. Das ist im allgemeinen dann der Fall, wenn ein Arbeitsschritt abgeschlossen ist (z.B. Erstellen des Codes für Komponente X). Die nächsten definierten Schritte könnten dann lauten: Review des Codes, Überarbeiten des Codes, Komponententest und Freigabe des Codes.

Wie gehe ich die Prüfung an?
Es empfiehlt sich, systematisch vorzugehen, d.h. sich für eine bewährte Reviewmethode zu entscheiden. Übliche und weithin bewährte Reviewmethoden sind (auch in kombiniertem Einsatz) die

  • Kommentartechnik und die
  • Sitzungstechnik.

Wie läuft ein Review in Kommentartechnik ab?
Die Unterlagen werden zunächst an die Reviewer verteilt:

  • Listings der Code-Stücke mit Statement-Nummern und Cross-Reference-Listings, syntaxfehlerfrei
  • Referenzdokumente (üblicherweise Detailentwürfe)
  • Projekt-Standards und -Vorgaben (falls vorhanden)
  • Protokoll-Templates
  • sonstige nützliche Unterlagen

Diese arbeiten das Code-Stück für sich durch und übergeben ihre Stellungnahmen dem Absender (i.a.: Autor, Veranlasser, Moderator, Einlader, ....). Dieser bewertet (ggf. in Absprache) die Kommentare, und der Autor arbeitet die Änderungen ein (waren die notwendigen Korrekturen sehr umfangreich, empfiehlt sich ein Nachreview in kleinerem Rahmen).

Wie läuft ein Review in Sitzungstechnik ab?
Die Unterlagen werden zunächst an die Reviewer verteilt. Zum festgesetzten Sitzungstermin wird das Code-Stück anhand der Aufzeichnungen der Reviewteilnehmer gemeinsam durchgegangen. Anschließend erstellt der Moderator/Protokollführer das Sitzungsprotokoll und bewertet die Fehler. Nun weiß der Autor über den Umfang der anstehenden Ausbesserungen Bescheid.

Eine stärker formalisierte Form der Sitzungstechnik ist die Intensivinspektion nach M. Fagan (sie ist wesentlich effektiver und effizienter als die traditionelle Sitzungstechnik, benötigt aber unmittelbar relativ viel Zeit). Die Anzahl der Teilnehmer wird auf 3 bis 6 beschränkt, die ein genau definiertes Rollenspiel durchzuführen haben. Unbedingt notwendig sind:

  • Autor
  • Leser
  • Moderator

zusätzlich können noch bis zu 3 weitere Inspektoren beschäftigt werden, die bestimmte Rollen ausführen, wie ein Schnittstellen-Prüfer, ein Anwender, ein Überprüfer von Standards, ein Tester, etc., die das Code-Stück aus ihrem Rollenverständnis heraus prüfen. Die Dauer einer derartigen Sitzung soll 2 Stunden nicht überschreiten. Daraus ergibt sich auch eine Beschränkung des Codeumfangs, der in einer Sitzung durchgearbeitet werden kann und die Notwendigkeit, das Code-Stück ggf. in mehreren Sitzungen zu prüfen.

Welche Methode nehme ich nun für mein Code-Review?
Für besonders „heiklen" Code oder „heikle" Codeteile empfiehlt sich unbedingt die Intensivinspektion. Für weiteren Code soll folgende Entscheidungstabelle dienen:

pro Kommentartechnik:
  • viele Teilnehmer sind möglich
  • keine Terminabsprachen sind notwendig
  • keine „Orts"-Probleme
  • kein Sitzungsaufwand
  • kein Reiseaufwand
contra Kommentartechnik:
  • keine Diskussion in der Runde
  • kein Synergieeffekt durch Sitzung
  • niedrige Fehlerfindungsrate
pro Sitzungstechnik:
  • höhere Fehlerfindungsrate
  • Mißverständnisse lassen sich schnell klären (Formulierungen)
contra Sitzungstechnik:
  • zu große Runde ist abzulehnen
  • das „Orts"-Problem stellt sich (D, USA, A, ....)
  • Terminabsprachen werden notwendig
  • negative psychologische Komponenten sind möglich (Druck durch Vorgesetzte, Antipathien, ....)
pro Intensivinspektion:
  • Rollenspiel fördert Review-Disziplin
  • vollständige Prüfung des Codes gegen die Vorgabe
  • höchste Effizienz und Effektivität
contra Intensivinspektion:
  • geringe Review-Geschwindigkeit
  • Ausbildung vorhanden ?

Warum dokumentierte Prüfung?
Unabhängig von der gewählten Methode ist jedes Review durch ein Reviewprotokoll zu dokumentieren:

  • Damit der Autor ein von allen Teilnehmern akzeptiertes Fehlerprotokoll für die Fehlerbehebung bei sich hat.
  • Damit alle Teilnehmer und Unterrichtete ein Dokument zur Verfügung haben, in dem sie bei der Planung und Durchführung weiterer Reviews Erfahrungswerte finden können.
  • Um gemäß ISO9001 eine Qualitätsaufzeichnung zum Entwicklungsergebnis ablegen zu können, um im Bedarfsfall eine Prüfung nachweisen zu können.

Ein Reviewprotokoll soll aus dem Deckblatt inkl. Fehlerstatistik, der Fehlerliste und ggf. einem Analyseprotokoll bestehen.

Wen betrifft das Code-Review?

  • Den Autor: Ich will mein Ergebnis durch eine Runde abgesichert wissen und möglichst wenige Fehler nach vorne (in die Testphase) weitergeben.
  • Das Team: Wir wollen uns in der nächsten Phase (Test) auf die Fehler konzentrieren können, die beim Test zu finden sind; der Inline-Kommentar ist lesbar und hilfreich in der Testphase, wir kennen uns aufgrund der Reviews im ganzen Subsystem aus und können erfolgreicher weiterarbeiten, wir haben gelernt, miteinander sachlich zu diskutieren.
  • Den Auftraggeber: Der Code wird sich besser in meine bereits vorhandenen teile integrieren lassen. Die Schnittstellen sind geprüft.
  • Den Auftragnehmer: Ich kann davon ausgehen, mit weniger Fehlern beim Kunden rechnen zu können. Die Wartungskosten werden sich in Grenzen halten. Der Kunde wird zufrieden sein und uns wieder beauftragen.

Was tun bei wenig Zeit und Geld?
Setzen Sie Prioritäten: Wo ist es besonders wichtig, in Code-Reviews Zeit und Geld zu investieren?

  • bei schweren Fehlerfolgen: z.B. sicherheitsrelevante Software, Image des Auftraggebers, zentrale Code-Stücke, zahlreiche und komplexe Schnittstellen
  • bei hoher Fehlerwahrscheinlichkeit: z.B. Autor neu in diesem Umfeld (bezüglich Thema und Tools), Kommunikationsprobleme (Ort und Sprache), komplexer Code („da gab’s immer schon viele Fehler"), late features (Spezifikation per Zuruf), durch viele Hände gegangener Code, ...

Wo kann ich die meisten Fehler erwarten?
Erfahrungsgemäß konzentrieren sich die Fehler im Source-Code auf einige wenige Themen:

  • Falsche oder vergessene Abprüfungen und Abfragen (29%)
  • Inkonsistente Verwendung von Daten und Variablen (20%)
  • Mißverstehen von Entwurfsdokumenten (14%)
  • Probleme mit der Programmiersprache (7%)
  • Fehler in der Verarbeitungslogik (7%)

Zusätzlich zum eigentlichen Review empfiehlt sich eine Analyse des Reviews
Im Anschluß an ein Review soll eine kurze Analyse durchgeführt werden, um aus dem eigenen Verhalten und den Fehlern zu lernen (Hinweise dazu finden sich im Reviewformular). Hinsichtlich des Reviewprozesses bedeutet das:

  • Hat bei der Planung alles gestimmt (Teilnehmer, Termin, Material,...)?
  • Wie lief das Review selbst (Konzentration, Fehlerfindung, Räumlichkeiten,...)?
  • Wie kam die Fehlerbewertung zustande (Konsens, Machtwort des Leiters,...)
  • Es lohnt sich auch, Positives im Analyseprotokoll anzumerken!

Hinsichtlich des Entwicklungsprozesses stellen sich folgende Fragen:

  • Welche Fehler tauchen immer wieder auf?
  • Warum?
  • Was könnte man dagegen tun (Maßnahmen und Verantwortliche)?

Sind diese Quellen gestopft, dann sollte einer Verbesserung des Entwicklungsprozesses nichts mehr im Wege stehen.


Siemens AG Österreich, Programm- und Systementwicklung PSE
Ansprechpartner: stdSEM-Webmaster
Zuletzt aktualisiert am: 07 Juli 1998 12:29
Copyright © Siemens AG Österreich 1997. Alle Rechte vorbehalten.