Code Review, Checkliste, Tools & Guidelines

Regulatorische Anforderungen an Code-Reviews

Die IEC 62304 fordert keine expliziten Code-Reviews. Sie sieht aber Code-Reviews als eine Möglichkeit, um Software-Einheiten zu prüfen. Dabei müssen allerdings schriftliche Prüfkriterien für die Code-Reviews vorliegen, ebenso ist das Code-Review schriftlich zu dokumentieren.

Forderungen der FDA

Die FDA fordert keine Code-Reviews schreibt aber im Software Validation Guidance Document:

Forderungen der IEC 62304 an Code-Reviews

Auch die IEC 62304 fordert keine Code-Reviews. Das ist nicht überraschend, da Normen nur selten konkrete Anforderungen an die Anwendung bestimmter Methoden stellen.

Was sind eigentlich Reviews

Der Begriff Review wird inzwischen fast inflationär benutzt. Immer wenn irgendwer zu irgendeinem Zweck und irgendeiner Methode auf irgendwas daraufschaut,  spricht man von Review. In Anlehnung an die IEEE-Norm 729 findet sich als Definition des Begriffs Review ein mehr oder weniger formal geplanter und strukturierter Analyse- und Bewertungsprozess, in dem Projektergebnisse einem Team von Gutachtern präsentiert und von diesem kommentiert oder genehmigt werden. Bei Code Reviews ist offensichtlich der Code Gegenstand der Bewertung.

Ein typisches Review umfasst folgende Schritte:

• Planung: Wer macht wann was
• Kick-off: Ziele kommunizieren, Dokumente verschicken
• Vorbereitung: Gutachter prüfen individuell
• Review-Sitzung: Konsolidierung und Bewertung der Ergebnisse
• Überarbeitung: Beheben der Fehler
• Follow-up: Ggf. abschließende Prüfung

Abhängig vom Grad der Formalisierung, der Vollständigkeit der genannten Schritte und der Zusammensetzung des Teams unterscheidet man beispielsweise:

• Walkthrough: Das sind die meist am wenigsten formalisierten Reviews, bei dem der Autor sein Dokument (z.B. seinen Code) einer Gruppe vorstellt, die dann Fehler sucht.
• Inspektion: Bei Inspektionen bekommen die Gutachter den Prüfgegenstand und Kriterien vorab zugeschickt, damit diese die Review-Fähigkeit bewerten und erste Ergebnisse zusammentragen können. In einer moderierten Sitzung, an der auch der Autor teilnimmt, besprechen die Gutachter und der Autor die Ergebnisse.
• Technische Reviews: Hier prüfen Gutachten zuerst einzeln einen Prüfgegenstand und gleichen dann ihre Ergebnisse ab. Zum Schluss schicken sie dem Autor die konsolidierten Ergebnisse. Der Autor ist in den Prozess der Bewertung nicht eingebunden.

Tipps zur praktischen Umsetzung

Wer Software für Medizinprodukte entwickelt, ohne dafür Code Reviews durchzuführen, sollte sich aber fragen, ob er / sie in der Branche und der Software-Entwicklung richtig ist. Auf Code Reviews zu verzichten, steht häufig im Widerspruch zu professioneller Programmierung.

Allgemeine Regeln für Code Reviews

Eins der wichtigsten Mittel, um die Fehlerrate in meinem Team signifikant einbrechen zu lassen, waren Code-Reviews. Und zwar konsequent bei jedem Code. Das klappt aber nur, wenn man das richtig macht und ein paar Regeln einhält:

1. Ein Code-Review sollte nicht länger als 30 Minuten dauern.
2. Ein Code-Review sollte den Code anhand vorher festgelegter und ggf. Programmiersprachen-spezifischen Kriterien prüfen, einschließlich der Einhaltung vorher (automatisch) bestimmter Metriken und Kodierrichtlinien. Nutzen Sie auch Checklisten.
3. Ein Code-Review sollte den Test-Code (einschließlich Code-Coverage) berücksichtigen.
4. Ein Code-Review sollte dokumentiert sein. Dazu gleich mehr.
5. Ein Code-Review kann auch reverse durchgeführt werden. Dazu gleich mehr.

Reverse Code Review

Beim Reverse-Code-Review erklärt nicht der Autor dem Reviewer seinen Code, sondern umgekehrt. Der Reviewer erklärt, was er zu verstehen glaubt. Das hat große Vorteile:

1. Der Reviewer ist konzentriert, denn er muss den Code ja dem Autor erklären.
2. Der Autor ist die angebliche Begriffsstutzigkeit des Reviewers bald leid und schreibt künftig einen Code, den sogar der Reviewer versteht. Das führt zu verständlichem und damit wartbarem Code.
3. Der Chef kann sicher sein, dass es eine zweite Person gibt, die den Code auch versteht. Das reduziert die Abhängigkeit von einem Entwickler.

Vier Augen sehen mehr als zwei. Machen auch Sie Code-Reviews. Am besten reverse!

Dokumentation von Code Reviews

Dokumentieren Sie alle Code Reviews, machen Sie das aber sehr leichtgewichtig! Entweder nutzen Sie ein Tool wie TFS oder MedPack oder Sie haben ein Formblatt (ein Blatt mit Vor- und Rückseite), das bei jedem Entwickler auf dem Schreibtisch oder in einer Schublade liegt. Während des Reviews füllt der Reviewer das Formblatt aus. Einmal pro Woche wirft der Entwickler die ausgefüllten Formblätter beim Qualitätsmanager ins Fach. Fertig. Der Overhead für die Formalien sollte im Sekundenbereich liegen!

Checklisten für Code Reviews

Allgemeines

Bei einer  Checkliste gibt es das Risiko, dass ein Review in den falschen Händen zu einem „formalen Akt des Abhakens von Trivialitäten“ verkommt und der Leser das wahre Ziel aus den Augen verliert: die Fehler zu finden.

Unterscheiden Sie daher zwei Typen von Checklisten:

1. Checkliste: Zur Prüfung der Eingangskriterien

In einer Checkliste zur Prüfung der Eingangskriterien für ein Review können  formale Aspekte stehen, die geprüft werden (results from automated analysis, general coding guidelines, process compliance). Die kann auch gerne der Autor selber ausfüllen.

2. Checkliste: Zur Fehlerfindung durch die Peers

Auf einer Checkliste für die Fehlerfindung sollten bevorzugt die Elemente stehen, die die „Peers“ dazu anregen „major defects“ zu finden. (z.B. typische Fehler, warum ein Code nicht funktional korrekt ist. Qualitäten, die ein Nutzer des Dokuments erwartet.).

Diese Checkliste zur Fehlerfindung ist genau 1 Seite lang, damit man sie beim Lesen neben sich haben kann. Hierzu noch zwei Gedanken:

1. Der Lackmus-Test, um zu entscheiden, auf welche Liste ein Eintrag kommt: „Ist es wert, wenn ALLE Gutachter ihre teure Intelligenz aufwenden und gleichzeitig diese eine Frage prüfen und erwarte ich major defects damit?“
2. Wenn man auf der Fehlerfindungs-Checkliste Coding Guidelines prüfen möchte (und dafür Platz auf der 1 Seite spendieren möchte) sollte man genau 1 Frage stellen: „An welcher Stelle sind die Coding Guidelines nicht eingehalten?“

Code Review Checklisten vom Johner Institut

Auditleitfaden

Wir haben für benannte Stellen den Auditleitfaden (nicht verwechseln mit dem Auditgarant) entwickelt, der umfangreiche Checklisten für alle Phasen der Software-Entwicklung enthält – einschließlich welcher für die Code Reviews.

Klicken Sie hier, um mehr über den Auditleitfaden zu erfahren

Auditgarant

Den Premium-Mitgliedern im Auditgarant steht eine bewährte Code-Review-Checkliste zum Download bereit. Alle Auditgarant-Mitgliedern können sich das zugehörige Videotraining ansehen.

Videotraining im Auditgarant ansehen

Formales

Code Reviews: Verlangt die FDA eine Unterschrift? Durch wen?

„Wer muss ein Code-Review laut FDA unterschreiben? Nur eine Person, beispielsweise der Reviewer oder der Moderator, oder alle Beteiligten, also der Entwickler, Reviewer und Moderator?

Um diese Frage zu beantworten, müssen wir kurz den Begriff des Code-Reviews beleuchten: Es gibt nicht „das“ Code Review, sondern ganz viele verschiedene Verfahren der statischen Prüfung von Quellcode. Beispielsweise

• den Walk-through,
• das technische Review,
• das informelle Review und
• die Inspektion.

Die FDA erwähnt diese Verfahren teilweise im Software Validation Guide, ohne eines davon explizit zu fordern. Die Verfahren unterscheiden sich auch durch die Personen, die zu involvieren sind. Einen Moderator gibt es beispielsweise bei einem informellen Review  gar nicht.

Die gesetzliche Forderung nach Reviews findet sich im 21 CFR part 820. Und auch hier ist kein spezifisches Verfahren genannt.

Damit ergibt sich nun die Antwort: Sie als Hersteller beschreiben in Ihrem 820-konformen QM-System, welche Form der Reviews Sie machen. Und abhängig davon müssen Sie dokumentieren, welche Personen involviert waren – durch Unterschrift.

Mit herzlichem Dank für wertvollen Input an Dr. Freimut