Codeüberprüfung: Bewährte Verfahren und Techniken

Grundsätzlich wird eine andere Person Ihre Arbeit bewerten und dabei auf Probleme achten, die Ihnen möglicherweise entgangen sind (und eine zweite Meinung zu Ihrer Lösung abgeben). Die Probleme, nach denen die Prüfer bei der Codeüberprüfung suchen, sind in der Regel Fehler, fehlerhafte Logik, Sicherheits- oder Leistungsprobleme usw.

Die Codeüberprüfung findet statt, bevor die vorgeschlagenen Änderungen in den Rest der Codebasis integriert werden. In der Regel bedeutet dies, dass der Entwickler seinen Feature-Zweig mit dem Hauptzweig zusammenführen möchte. Die Codeüberprüfung ist ein „blockierender” Schritt im Entwicklungsprozess, da die Arbeit in dieser Phase verbleibt, bis Sie oder Ihre Teammitglieder alle Anmerkungen der Prüfer berücksichtigt haben.

Es gibt mehrere Hauptgründe, warum Codeüberprüfungen ein wichtiger Teil des Softwareentwicklungsprozesses sind:

• Sicherstellen, dass die Codequalität über einen längeren Zeitraum auf dem gleichen Niveau bleibt. Dazu gehören viele Dinge: die Einhaltung von Codierungsstandards, die Anwendung von Best Practices, die Berücksichtigung von Leistung und Sicherheit bei der Entwicklung einer Lösung usw.
• Frühzeitiges Erkennen (und Beheben!) von Problemen
• Wissensaustausch zwischen den Teammitgliedern und Verbesserung der Zusammenarbeit (da alle gemeinsam daran arbeiten, die vorgeschlagene Lösung zu verbessern)

Mögliche Hindernisse

Allerdings gibt es auch einige Nachteile bei der Codeüberprüfung:

• Eine Codeüberprüfung erfordert Zeit und Mühe. Dadurch wird der Prüfer von seinen eigentlichen Aufgaben abgelenkt. Dies kann dazu führen, dass der Prüfer eine schlechte Codeüberprüfung durchführt, nur um „sie hinter sich zu bringen”.
• Wie bereits erwähnt, blockieren Code-Reviews den Softwareentwicklungsprozess. Das bedeutet, dass es länger dauert, bis Ihre Änderungen in der Produktion implementiert werden. Manchmal kann eine Überprüfung komplex sein oder ein Prüfer kann (aufgrund verschiedener Faktoren) zu einem Engpass werden, was dazu führt, dass die Überprüfung mehr Zeit in Anspruch nimmt. Aus diesem Grund könnte das Team manchmal darüber nachdenken, „die Codeüberprüfung dieses Mal zu überspringen“, um schneller Ergebnisse liefern zu können.

Ich denke, dass diese Nachteile für die Diskussion besonders wichtig sind, da sie das grösste Problem der Verwendung von Code-Reviews als Teil Ihres Softwareentwicklungsprozesses deutlich veranschaulichen – nämlich die Inkonsistenz. Code-Reviews bieten den grössten Nutzen, wenn Sie sie regelmässig und auf die gleiche Weise durchführen.

Die richtige Durchführung von Code-Reviews erfordert Disziplin. Wenn Sie sie nur gelegentlich durchführen (aus welchen Gründen auch immer) oder wenn Sie Ihre Vorgehensweise jedes Mal ändern, machen Sie einfach etwas falsch. Entweder Sie führen sie konsequent durch oder gar nicht. Ja, es gibt Situationen, in denen ein Code-Review möglicherweise nicht notwendig ist, aber das sind Ausnahmen.

Richtlinien für die Codeüberprüfung

Und damit kommen wir zu unserem nächsten Thema – der Festlegung von Richtlinien für die Codeüberprüfung. Woher wissen wir, worauf wir bei der Codeüberprüfung achten müssen? Dies ist besonders wichtig in Teams mit unterschiedlichen Erfahrungsstufen.

Selbst in einem Team aus erfahrenen Ingenieuren können verschiedene Personen sehr unterschiedliche Meinungen darüber haben, was guter Code ist. Aus diesem Grund könnte Ihr Team eine Reihe von Richtlinien für die Durchführung von Codeüberprüfungen festlegen, damit alle die Änderungen auf ähnliche Weise bewerten können. Dadurch wird sichergestellt, dass es keine grossen Unterschiede in der Qualität der Überprüfungen zwischen den Teammitgliedern gibt, und es werden Mindestanforderungen festgelegt, die erfüllt werden müssen. Sie können sogar separate Richtlinien für Autoren und Prüfer festlegen. Dies hilft allen Teammitgliedern, Änderungen auf einheitliche Weise einzureichen und zu überprüfen.

Nachfolgend finden Sie einige Beispiele:

Die Lösung entspricht Ihrem Codierungsstil/Ihren Codierungsstandards

Wenn Ihr Team über Richtlinien verfügt, die Dinge wie Klassen- und Variablennamen, Methodensignaturen, Anwendungsstruktur, Protokollierungspraktiken usw. definieren, stellen Sie sicher, dass der Autor die durch diese Richtlinien auferlegten Regeln befolgt.

Änderungen sind logisch organisiert

Achten Sie beim Einreichen Ihrer Änderungen darauf, dass Sie zusammengehörige Änderungen gruppieren und Ihre Commit-Meldungen entsprechend verfassen. Es ist schlampig, 35 Änderungen aus 10 verschiedenen Klassen zusammenzufassen und sie als „kleine Änderung” zu bezeichnen. Das wird nur die Augen Ihres Reviewers bluten lassen (und Ihre Git-Historie wird schlecht aussehen).

Build/Pipeline darf nicht fehlschlagen

Reichen Sie niemals Code ein, der nicht funktioniert. Wenn es Build-Fehler gibt oder Ihre CI/CD-Pipelines aus irgendeinem Grund fehlschlagen, beheben Sie diese Probleme, bevor Sie einen PR einreichen. Wenn der Prüfer hingegen einen solchen PR erhält, sollte er ihn sofort an den Autor zurücksenden, bis dieser alle Probleme behoben hat.

Eine kurze Beschreibung der Änderung muss angegeben werden

Wenn Sie einen PR öffnen, stellen Sie sicher, dass der Prüfer eine Möglichkeit hat, herauszufinden, welches Problem Sie zu lösen versucht haben. Sie können dies entweder durch eine Beschreibung der Änderung oder durch einen Link zum entsprechenden Ticket (das ausreichend detaillierte Informationen enthalten sollte) tun. Ohne diese Informationen wird die Arbeit des Prüfers erheblich erschwert, da er viel mehr Zeit damit verbringen wird, herauszufinden, was der von ihm geprüfte Code leisten soll.

Code-Analyse-Tools melden keine Fehler

Code-Analyse-Tools wie SonarQube können hilfreich sein, da sie einige übersehene Probleme erkennen und verschiedene Möglichkeiten zur Verbesserung Ihres Codes vorschlagen können. Wenn Sie solche Tools verwenden, könnten Sie verlangen, dass jeder Feature-Zweig analysiert wird, bevor der PR geöffnet wird. Alle Probleme (sofern sie erkannt werden) müssen behoben werden, um die Überprüfung abzuschliessen.

Der Code wird durch Tests abgedeckt

Wenn Sie regelmässig Tests schreiben (oder den grössten Teil Ihres Codes mit Tests abdecken), sollte kein PR ohne Tests eingereicht werden. Sollte dies dennoch vorkommen, muss es dafür einen guten Grund geben. Informieren Sie den Prüfer daher unbedingt darüber, warum Sie keine Tests einreichen.

PR enthält keine irrelevanten Änderungen

Der PR sollte sich nur auf das Problem konzentrieren, das Sie lösen möchten. Das Einfügen von nicht relevanten Änderungen in Ihren PR verwirrt nicht nur den Prüfer, sondern kann auch den QA-Prozess erschweren, da diese nicht offengelegten Änderungen zu neuen Verhaltensweisen führen können. Vermeiden Sie dies, nur weil Sie es für bequem halten und „zwei Fliegen mit einer Klappe schlagen“ möchten. Wenn Sie der Meinung sind, dass Sie eine nicht relevante Änderung in Ihren PR aufnehmen sollten, besprechen Sie dies mit Ihrem Team.

Es gibt jedoch einige Dinge, die Sie bei der Durchführung von Code-Reviews vermeiden sollten. Sehen wir uns einige davon an:

Überprüfung ohne den richtigen Kontext

Wenn Sie nicht vollständig verstehen, was Sie überprüfen müssen, können Sie nicht entscheiden, ob die eingereichte Lösung gut ist oder nicht. Wenn Sie mit der Aufgabe, die Sie überprüfen sollen, nicht vertraut sind, müssen Sie einige Nachforschungen anstellen und sich an den Autor wenden, um die Lösung und die Motivation dahinter besser zu verstehen. Andernfalls könnten Sie sich auf die falschen Aspekte des Problems konzentrieren oder einige Dinge übersehen, die Ihnen zwar in Ordnung erscheinen, aber im jeweiligen Kontext nicht funktionieren.

Ein-Mann-Show

Versuchen Sie, Situationen zu vermeiden, in denen eine einzige Person alle Code-Reviews durchführt. Manchmal kann dies bei sehr kleinen Teams oder Teams mit geringem Senioritätsgrad der Fall sein – aber selbst dann sollte dies nicht lange so bleiben. Code-Reviews sollten, wie bereits erwähnt, eine Aktivität sein, an der das gesamte Team teilnimmt. Es ist nicht gut, wenn nur eine Person als Reviewer fungiert: Erstens könnte der Prüfer seinen persönlichen Stil als „einzig und allein“ durchsetzen und zweitens überfordert werden – was ihn zu einem Engpass für das Team macht.

Vorschlagen grosser oder nicht relevanter Änderungen während des Code-Review-Prozesses

Wenn so etwas passiert, müssen Sie einen guten Grund dafür haben. Im Allgemeinen kann eine umfangreiche Neugestaltung mitten in der Codeüberprüfung bedeuten, dass der Autor den Kontext nicht richtig verstanden hat oder während der Überprüfung eine bessere Lösung entdeckt wurde. Solche Dinge können vorkommen – aber nur selten. Wenn dies häufig vorkommt, sollten Sie die Ursache untersuchen. Vermeiden Sie es, Verbesserungen an dem zu überprüfenden Code vorzunehmen, „nur weil“ es eine gute Gelegenheit ist, auch ein anderes Problem anzugehen. Diese Änderungen verdienen eine separate Aufgabe und eine eigene Codeüberprüfung, um nachvollziehbar zu bleiben.

Codeüberprüfung als Waffe

Dies ist eine Situation, in der der Prüfer absichtlich nach Problemen sucht und die Arbeit des Autors kritisiert, weil er persönliche Probleme mit dem Autor hat. Dies ist ein äusserst toxisches Verhalten, das nicht nur den Autor, sondern das gesamte Team schwer beeinträchtigen kann. Probleme mit anderen Teammitgliedern sollten an anderer Stelle gelöst werden – der Fokus der Codeüberprüfung sollte nur auf dem Code liegen, nicht auf der Person, die ihn eingereicht hat.

Fazit

Wie Sie sehen, ist die ordnungsgemässe Durchführung einer Codeüberprüfung nicht einfach. Es handelt sich um eine komplexe Tätigkeit, die Zeit erfordert und die Sie konsequent durchführen müssen (Sie können sie sogar in Ihren Produktentwicklungslebenszyklus integrieren). Sie kann jedoch einen enormen Einfluss auf die Gesamtqualität des Produkts, die Zusammenarbeit im Team und den Wissensaustausch haben. Aus diesem Grund lohnt es sich, Zeit und Mühe in die Einrichtung eines guten Code-Review-Prozesses zu investieren. Die Vorteile, die Sie daraus ziehen können, sind weitaus grösser als die potenziellen Nachteile.