8 bewährte Best Practices für Code-Reviews für Entwickler

Bei einem Security-Code-Review wird geprüft, wie gut der Code vor externen Bedrohungen schützt. Der Code kann Sicherheitslücken aufweisen, die die Anwendung oder angrenzende Codeblöcke gefährden. Peer-Reviews sind ein manueller Prozess, der automatisierte Testmethoden ergänzt und so für umfassenden Sicherheitsschutz sorgt. Ein sicheres Code-Review kann Sicherheitslücken aufdecken und Fehler in der Codelogik identifizieren, die mit der Funktionsweise einer Anwendung zusammenhängen. Diese Art von Review schützt die Anwendung vor dem Verlust von Daten und geistigem Eigentum, der sich auf Umsatz und Reputation des Unternehmens auswirken könnte.

Eine der besten Möglichkeiten, die Qualität und Sicherheit von Software zu verbessern, ist ein formalisierter Prozess für manuelle Code-Reviews. Da beim Schreiben von Code Fehler auftreten können, lassen sich mit mehreren frischen Blicken und ergänzendem Fachwissen Fehler aufdecken, die der ursprünglichen programmierenden Person möglicherweise entgehen. Außerdem können Expertengruppen trotz menschlicher Fehleranfälligkeit Bugs oder Sicherheitslücken im Code erkennen, die automatisierte Code-Review-Tools möglicherweise übersehen.

Bei allen Vorteilen eines Peer-Code-Reviews kann es manchmal schwierig sein, eine Gruppe von Kolleginnen und Kollegen zusammenzubringen und die anstehende Aufgabe schnell zu erledigen. Klare Code-Review-Praktiken können den Prozess strukturieren und zum gewünschten Ergebnis führen: hochwertigem, sicherem Code. Hier finden Sie acht Richtlinien für Code-Reviews, die Sie in den Softwareentwicklungsprozess Ihres Unternehmens integrieren können.

1. Kommentare beim Schreiben des Quellcodes hinzufügen

Als erste Maßnahme sollten Entwicklerinnen und Entwickler in bestimmten Codeabschnitten nicht ausführbare Kommentare verwenden, um den Reviewenden die Absicht hinter einem Codeblock zu erläutern. Kommentare vermitteln, warum eine bestimmte Entscheidung getroffen oder eine Änderung vorgenommen wurde, sodass das Review-Team nicht raten muss. Bei guter Umsetzung können erfahrene Reviewende anhand der Kommentare Zweck und Methodik der gesamten Codeabfolge nachvollziehen. Ein Styleguide sorgt zudem für Lesbarkeit im gesamten Team, wenn er konsequent eingehalten wird.

2. Nicht davon ausgehen, dass etwas ohne Tests funktioniert

Die Entwicklung von Code erfordert wiederholtes Ausprobieren. Eine Entwicklerin oder ein Entwickler schreibt einige Zeilen, kompiliert den Code – und er funktioniert nicht. Wenn die Funktionalität und Ausgabe neuer Codeabschnitte getestet werden, kann das die spätere Review-Zeit erheblich verkürzen. Außerdem lässt sich ein kleiner Codeabschnitt leichter korrigieren, wenn bekannt ist, dass der restliche Code ordnungsgemäß funktioniert. Beim Test-Driven Development (TDD) werden beispielsweise Unit-Tests geschrieben, bevor der Code implementiert wird. So lassen sich bestimmte Funktionsblöcke vorab prüfen, während sich die Reviewenden darauf konzentrieren können, diese Funktionen in den übrigen Code zu integrieren.

3. Testsuiten für vorgeschlagenen Code ausführen

Eine Möglichkeit, eine bestimmte Gruppe von Abläufen zu validieren, besteht darin, mithilfe automatisierter Testsuiten Unit-Tests für jeden Codeblock zu schreiben. Eine Testsuite umfasst bekannte Funktionen und prüft den Code anhand eines erwarteten positiven Ergebnisses. Als weiteres Tool zur Bewertung bestimmter Aktionen beschleunigen Testsuiten die Validierung von Codeabschnitten, die eine oder mehrere vorgegebene Aufgaben ausführen. Ein fehlgeschlagener Test kann auf einen bestimmten Bereich hinweisen, den die Entwicklerin oder der Entwickler ändern muss.

4. Pull Requests klein halten und auf ein einzelnes Ziel ausrichten

Pull Requests (PRs) sind ein standardisierter Prozess, um Peer-Code-Reviews anzufordern. Sobald die Entwicklerin oder der Entwickler die erste Codeänderung abgeschlossen hat, leitet der PR den Review-Prozess ein. PRs sollten konkrete Anweisungen für die Reviewenden enthalten, um das manuelle Code-Review effizienter und schneller zu gestalten. Je umfangreicher der PR, desto länger kann das Review dauern – dadurch steigt das Risiko, dass das Hauptziel des PRs übersehen wird. Tatsächlich umfasst ein idealer PR weniger als 250 Zeilen, da Reviewende innerhalb einer Stunde 70–90 % der Fehler entdecken können.

5. Immer automatisierte Code-Prüfungen ausführen

Vor dem Peer-Review kann die Entwicklerin oder der Entwickler Code-Review-Tools wie Scanner, automatisierte Code-Prüfungen oder statische Code-Analysetools einsetzen, um die Qualität einer Codebasis nach Änderungen zu bewerten. Diese Tools erkennen offensichtliche Formatierungsfehler wie Fehler in Funktionsnamen oder Probleme mit Abständen. Scanner und Linter arbeiten mit festgelegten Regeln und prüfen Code ähnlich wie eine Rechtschreibprüfung auf Fehler. So entfällt diese Arbeit beim manuellen Peer-Review und das Code-Review-Team kann sich auf stilistische oder interpretative Fehler konzentrieren.

Beispielsweise können Java-Code-Review-Tools Bugs und Sicherheitsprobleme in Java-Code finden und konkrete Empfehlungen geben, mit denen Entwicklerinnen und Entwickler sie schnell beheben können. Snyk Code liefert direkt in Ihrer IDE Empfehlungen zur Codequalität und sorgt so für ein nahtloses Entwicklungserlebnis.

6. Den gesamten Code und alle PRs überprüfen

Da Code sequenziell aufgebaut ist, müssen Reviewende den gesamten Code und alle PRs auf Kohärenz prüfen. Eine Änderung an einem Abschnitt kann sich stark auf nachgelagerte Subroutinen auswirken. Deshalb muss das Peer-Code-Review-Team bei der Bewertung den gesamten Code und alle PRs berücksichtigen. Größere und umfangreichere PRs erhalten naturgemäß mehr Aufmerksamkeit. Ein Fehler in einem kleinen PR kann jedoch noch gravierendere Auswirkungen haben als mehrere Fehler in einem umfangreichen PR.

7. Zeit- und Zeilenlimits für Reviews festlegen

Code-Reviews sind zeitaufwendig und mühsam, aber entscheidend. Deshalb ist es wichtig, die Zeit zu begrenzen, die einzelne Reviewende oder Teams mit den Details jeder Codezeile verbringen. Zu den Best Practices in diesem Bereich gehört beispielsweise, dass Teammitglieder nicht länger als eine Stunde mit einem Code-Review verbringen oder das Team innerhalb eines bestimmten Zeitraums nicht mehr als einige Hundert Zeilen überprüft. So werden klare Erwartungen für das Code-Review-Team geschaffen und sichergestellt, dass der für den PR relevante Codeabschnitt sorgfältig geprüft wird. Wenn Code-Reviews für das gesamte Team effizient organisiert sind, erhalten Entwicklerinnen und Entwickler wertvolles Feedback und können die Qualität ihres Codes schnell verbessern.

8. Ein Security-Code-Review durchführen

Eine weitere Best Practice für Code-Reviews ist ein sicheres Code-Review. Automatisierte Tools prüfen den Code auf Abstands- oder Benennungsfehler und vergleichen ihn mit bekannten Standardfunktionen. Manuelle Reviews bewerten Stil, Absicht und Funktionalität des Codes. Bei der dritten Art der Prüfung, dem Security-Code-Review, wird der Code auf seine Sicherheitsrobustheit hin untersucht.

Der Code kann inhärente Sicherheitslücken aufweisen, die die Anwendung oder angrenzende Codeblöcke gefährden. Ein sicheres Code-Review kann diese Sicherheitslücken aufdecken und außerdem dabei helfen, Logikfehler zu erkennen, die mit der Funktionsweise einer Anwendung zusammenhängen. Entwicklerinnen und Entwickler müssen Code in einer Umgebung schreiben können, die ihn vor externen Angriffen schützt. Diese können von Diebstahl geistigen Eigentums bis hin zu Umsatz- oder Datenverlust reichen.

Die gute Nachricht: Es gibt bereits Tools für Static Application Security Testing (SAST) – wie Snyk Code –, die Sicherheitslücken erkennen können, bevor sie in ein Code-Review gelangen oder während des Code-Scannings. Außerdem gibt es Best Practices für sicheres Programmieren, die den Quellcode schützen und ein effizientes Security-Code-Review ermöglichen. Beispiele hierfür sind die Zugriffsbeschränkung auf den Code, starke Verschlüsselung und Secret Management zum Schutz von Passwörtern und fest codierten Werten vor einer breiten Offenlegung.

Fazit: So führen Sie ein Code-Review durch

Entwicklerinnen und Entwickler können ihren Code unbegrenzt weiter verfeinern und optimieren, doch trotzdem entgeht ihnen möglicherweise ein Fehler oder eine Sicherheitslücke. Mit einem Peer-Code-Review-Prozess können Entwicklungsteams sicherstellen, dass ihre Software vor der Bereitstellung in der Produktion ordnungsgemäß getestet wird. Am effizientesten lässt sich hochwertiger, sicherer Code schnell bereitstellen, wenn automatisierte Code-Reviews, manuelle Peer-Reviews und sichere Code-Review-Praktiken kombiniert werden.

Auf unserer Seite Security Resources erfahren Sie mehr über die Angebote und Tools von Snyk, mit denen Entwicklerinnen und Entwickler präzisen, sicheren Code erstellen können.