Code-Review oder kein Code-Review? Das ist hier die Frage. Um Software-Qualität sicherzustellen, gibt es verschiedene Ansatzpunkte. Statische Codeanalyse, automatisierte Unittests, Integrationstests, Smoke Tests und viele viele mehr. Die aufgezählten Punkte sind in der heutigen Software-Entwicklung Stand der Technik und nicht aus der täglichen Arbeit wegzudenken. Beim Code-Review ist die Medizintechnik-Szene jedoch gespalten. Kaum eine andere Testmethode ist so umstritten. Dabei wird der Methode Code-Review oft unrecht getan.
“Talk is cheap, show me the code.”
Linus Torvalds
Was sagt die IEC62304 dazu?
Die IEC62304 (Medizingeräte-Software – Software-Lebenszyklus-Prozesse) fordert kein Code-Review. Vielmehr muss für die Software eine Sicherheitsklassifizierung erfolgen. Auf Basis der Sicherheitsklassifizierung kann man dann festlegen, welche Testmethoden angewendet werden sollen. Dabei ist es zulässig, durch Architektur-Entscheidungen Software-Komponenten zu segregieren und damit sicherheitskritische von nicht sicherheitskritischen Teilen zu trennen. Das führt zur Reduktion von Aufwand und ist durchaus berechtigt. Es führt häufig dazu, dass man Code-Review als absolute „Topmethode“ auf Software der Sicherheitsklasse C beschränkt und andere Module der Klassen A und B unberücksichtigt lässt. Schließlich muss man ja bei A und B weniger machen als bei C. Hier ist die Frage, ob diese Entscheidung sinnvoll ist. Denn auch wenn Software nicht imstande ist jemanden zu töten oder zu verletzen, so kann ein Fehlverhalten trotzdem unangenehme Folgen haben.
Was bringen Code-Reviews?
- Fehler werden frühzeitig in der Entwicklung gefunden (in der Programmierphase).
- Nicht verstandene Anforderungen an das Produkt werden erkannt.
- Entwickler räumen Code auf, der zum Review soll.
- Externe Experten sehen Dinge, die der Entwickler nicht mehr sieht.
- Fehler im Systemtest führen zu einem sehr hohen Aufwand. Fehler finden, Fehler lokalisieren, Änderung durchführen, erneute Tests durch Änderung (z.B. Systemtests müssen wiederholt werden).
- Systemtests sind nicht vollständig. Es ist nicht möglich alle Fälle zu testen. Daher ist es besser, die Fehlerfälle durch ein Code-Review zu finden.
- Ein dokumentiertes Code-Review gibt dem Entwickler ein gutes Gefühl und sorgt dafür, dass Fortschritt sichtbar ist (Spezifikation, Implementierung, Review, Test, Fertig, nächstes Modul)
- Das Wissen im Unternehmen wird größer. Die Entwickler werden besser und lernen voneinander.
- Die Wartbarkeit von Code ist besser, wenn mehr als eine Person den Code verstanden hat. Es ist auch leichter möglich für andere sich einzuarbeiten.
- Es entsteht ein firmenweiter Standard auf hohem Niveau.
Was spricht gegen ein Review?
- Es gibt keine Zeit mehr im Projekt. Reviews werden zu spät im Projekt eingeplant. Die Software soll eigentlich schon fertig sein und jetzt soll es noch Reviews mit 100-200 Stunden Aufwand geben. Das will keiner mehr ausgeben.
- Manche Module oder Komponenten (z.B. Linux) sind viel zu groß und es wäre unwirtschaftlich diese zu reviewen. Das ist in der Tat ein gutes Argument gegen das Review. Im Gegenzug muss klar sein, dass sich dadurch Aufwand an anderer Stelle ergibt. Es müssen also Tests durchgeführt werden. Bei SOUP/OTS (source of unknown provenance / off the shelf software) ist auch das Risikomanagement gefragt.
- Es handelt sich nur um Klasse A oder B Software. Von diesem Argument rate ich dringend ab! Es ist sehr schwierig auszuschließen, dass Klasse A Software nicht ebenfalls zu einem Fehlverhalten führen kann. Und es geht ja nicht nur darum niemanden zu verletzen. Das Ziel ist es, effizient ein gutes Produkt entwickeln.
Was sind meine Erfahrungen?
- Bei mehr als 30 % der Code-Reviews werden kritische Fehler erkannt, die zu einem Fehlverhalten im Feld führen können.
- Richtig geplant und eingesetzt entsteht ein Aufwand von ca. 5-8 % der Software-Entwicklung (Erfahrungswerte aus meinen Projekten) für ein vollständiges Code-Review einer Klasse C Software.
- Gerade junge Entwickler profitieren enorm durch Reviews.
- Es entsteht eine sehr große Dynamik und damit Spaß an der Arbeit mit Kollegen Arbeitsergebnisse zu diskutieren und zu zeigen, was man drauf hat.
- Viele sehr gute und erfahrene Entwickler sprechen sich für Reviews aus.
- Durch Weglassen des Reviews wird kein Aufwand vermieden, sondern nur an anderer Stelle bezahlt. Unter Umständen zu einem höheren Preis.
Was ist sonst noch wichtig?
Entwickler, die noch nicht durch das Fieber Review angesteckt sind, lehnen diese eher ab. Sie sehen es als Prüfungssituation, wodurch Stress produziert wird. „Das soll sich lieber keiner anschauen, ich mache das schon…“ Diese Einstellung ist nicht sinnvoll. Es geht nicht darum jemanden schlecht zu machen oder seine Kompetenzen abzusprechen. Es geht darum ein gutes Produkt zu entwickeln und technologisch sehr gute Arbeit zu leisten. Sobald das klar ist, entsteht ein Flow, der zum Anspruch führt Software auf hohem Niveau zu entwickeln.
|
|
| Dipl.-Ing. Goran Madzar, Gesellschafter, Senior Systems Engineer E-Mail: madzar@medtech-ingenieur.de Tel.: +49 9131 691 240 |
|
Benötigen Sie Unterstützung bei der Entwicklung Ihres Medizingeräts? Wir helfen gerne! Die MEDtech Ingenieur GmbH bietet Hardware-Entwicklung, Software-Entwicklung, Systems Engineering, Mechanik-Entwicklung und Beratung aus einer Hand. Nehmen Sie Kontakt mit uns auf. |
|
Templates für Reviews müssen leicht handhabbar sein. Es ist natürlich nicht klug ein Template zu verwenden, das nicht schlank und einfach zu benutzen ist. Wir wollen nicht Word Experten sein, sondern super Software entwickeln. Am besten verwendet man Tools, um Code Reviews durchzuführen (z.B. Remine, reviewboard). Hiermit können die Reviews in der Versionsverwaltung der Software integriert werden.
Es muss die Freiheit geben, das Vorgehen beim Review anzupassen. Manche brauchen den Source Code vor dem Review als Ausdruck, um sich Notizen zu machen. Andere brauchen unbedingt ihren Editor, weil dieser Begriffe über das ganze Dokument markieren kann. Manche brauchen ihre Ruhe zum Denken. Andere wollen darüber sprechen. Es ist daher nicht sinnvoll eine Vorgehensweise für alle Fälle vorzuschreiben.
Was ist das absolute Minimalziel?
Code-Reviews sollten in den folgenden Fällen auf jeden Fall durchgeführt werden:
- Klasse C Module
- Komplexe Module
- Code von unerfahrenen Entwicklern (<3Jahre Berufserfahrung oder an weniger als 20 Code Reviews teilgenommen) als eine Art Mentoring
- Code von externen Mitarbeitern
- Code bei dem die Entwickler ein schlechtes Gefühl haben
Überlegen Sie sich welche Module wie getestet werden. Eventuell sind Module durch Unit-Tests besser testbar als durch Review. Die Teststrategie und die Verifikationsplanung muss frühzeitig festgelegt werden. Die Methoden müssen zielführend sein!
Planung der Code-Reviews
Ich plane die Code-Reviews auf Basis der Software Architektur und der Liste der Software Module. In Tabellenform werden die Software-Module mit Risikoklassifizierung aufgelistet und die Testmethode festgelegt. Die Festlegung wird dabei mit dem Software-Entwickler diskutiert. Die Tabelle unten zeigt den prinzipiellen Aufbau.
| Module | Risk Class | Test Method | ||
| Code Review | Unit Test | Software System Test |
||
| FreeRTOS | B | — | yes | yes |
| HAL: CMSIS | B | — | yes | yes |
| Audio Manager | A | — | no | yes |
| Error Manager | B | yes | yes | yes |
| Language Manager | A | yes | no | yes |
| Menu Control | B | yes | yes | yes |
| Parameter Base | B | — | yes | yes |
| Module xyz | B | yes | yes | yes |
Um die Aufwände für die Code-Reviews abzuschätzen, werden zwei Ansätze verwendet. Zum einen schätzt der Entwickler den Aufwand für jedes Modul in der Liste. Bei einem jungen oder unerfahrenen Kollegen sollten erfahrene Kollegen unterstützen. Das ergibt die Bottom-Up Schätzung. Um die Plausibilität und Richtigkeit überprüfen zu können, werden Aufwände eines ähnlichen Projektes gegenübergestellt. Das ist die Top-Down Schätzung. Mit diesen beiden Werten hat man eine gute Basis für eine fundierte Aufwandsabschätzung.
Vorgehensweise bei Code-Reviews
Der Source Code muss vorher aufgeräumt werden, sodass Offensichtliches beseitigt ist. Es ist nicht das Ziel sich auf Kommentare (z.B. Doxygen) oder auf Rechtschreibfehler zu konzentrieren, sondern auf den Code. Es ist auch empfehlenswert die statische Codeanalyse vorher durchzuführen und den Code daraufhin zu prüfen, dass es den Programmierrichtlinien ihrer Organisation entspricht.
Das Ablaufdiagramm zeigt eine mögliche Vorgehensweise.
Fazit
Die Codereviews sind eine gut planbare und frühzeitig mögliche Methode, um Fehler und damit verbundene Aufwände in einer späten Projektphase zu vermeiden. Es wird empfohlen, bei der Abschätzung sowohl Top-Down als auch Bottom-Up vorzugehen. Es ist daher sinnvoll, Aufwände von vergangenen Projekten zur Abschätzung zu benutzen. Es ist auch sinnvoll, die geeignete Testmethode für die Qualifizierung festzulegen. Manchmal ist ein Code-Review günstiger als eine andere Methode, weil man einfach nur lesen muss.
Das Vorgehen funktioniert und bringt eine bessere Codequalität. Nicht nur für die Module, die man sich anschaut, sondern auch in den anderen, weil ein Lerneffekt eintritt und die Fehler nicht in anderen Modulen wiederholt werden. Die Qualität verbessert sich sogar über das Projekt hinaus. Die Code-Reviews sorgen für einheitlichen Code.
Ich freue mich über Feedback und wenn Sie mit mir in Kontakt treten. Sie können gerne auch einen Kommentar zu dem Artikel abgeben. Falls Sie jemanden kennen, für den der Blog ebenfalls interessant sein könnte, freue ich mich auch sehr über eine Weiterempfehlung.
Viele Grüße
Goran Madzar