
|
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:
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 gabs
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.
|