Wie du mit Code-Reviews deine Entwicklungsqualität aufs nächste Level bringst

Code-Reviews sind wie Fahrrad fahren: Die meisten können es schon, verlernen es nie und alle machen es auf dieselbe Weise.

Leider ist das ein ziemlicher Irrglaube.

Code-Reviews werden von jedem anders angegangen. Von einem kurzen Blick mit einem “Sieht gut aus” zur Analyse jedes einzelnen Buchstabens ist eigentlich alles dabei. Darum ist es essenziell, dass jedes Entwicklungs-Team sich mit den Vorteilen von Code-Reviews auseinandersetzt und festlegt, welche “Spielregeln” für alle gelten.

Wir erklären dir, wie Code-Reviews funktionieren, welche Vorteile sie haben und welche Best Practices du beachten solltest.

Was ist ein Code-Review?

Ein Code-Review ist eine manuelle Testmethode der Arbeitsergebnisse der Softwareentwicklung. Es ist ein wichtiger Bestandteil der Softwareentwicklung und gehört zur Kategorie der analytischen Qualitätssicherungsmaßnahmen.

Aber wie funktioniert das praktisch?
Bei einem Code-Review liest ein Teammitglied den durch eine andere Person geschriebenen Code und versieht diesen mit Anmerkungen und Verbesserungsvorschlägen. Daraufhin wird der Code angepasst und danach erneut vom Reviewer untersucht. Dieser Vorgang wiederholt sich, bis der Code einen akzeptierten Zustand erreicht hat.

Vorteile von Code-Reviews

Kostenersparnis durch Fehlervermeidung

Je später ein Fehler entdeckt wird, desto größer ist der Aufwand und die damit verbundenen Korrektur-Kosten. Das Review ist der erste Prozess nach der Entwicklung des Codes und die früheste und damit günstigste Möglichkeit, eingebaute Fehler zu korrigieren.

Bessere Code-Qualität

Fehler werden meistens beim Testen oder im Betrieb sichtbar – schlechte Code-Qualität jedoch nicht. Durch Code-Reviews lässt sich der Code explizit auf das Einhalten von Coderichtlinien untersuchen und so können langfristige Kosten vermieden werden.

Entwickler*innen lernen voneinander

Beim Code-Review lernt nicht nur der Autor des Codes vom Code-Reviewer dazu, sondern auch umgekehrt. Der Code-Reviewer kann sich beispielsweise durch gute, ihm bisher unbekannte Lösungswege inspirieren lassen und diese bei seinen eigenen Problemstellungen anwenden.

Entwickler*innen kennen ihre Software besser

Egal, ob man ein Experten-Team hat, bei dem jede und jeder auf dem eigenen Spezialgebiet arbeitet, oder ein interoperables Team, bei dem Entwickler*innen in mehreren Gebieten tätig ist – Je besser die Entwickler*innen die gesamte Software kennen, umso besser können sie in der Regel ihre Aufgaben erledigen.

Code-Review-Methoden

Es gibt mehrere Methoden, mithilfe derer ein Code-Review vollzogen werden kann. Im Folgenden stellen wir dir die drei Methoden vor, die wir als am effizientesten empfinden und deshalb praktizieren.

Pair-Programming

Beim Pair-Programming arbeiten zwei Entwickler*innen zusammen an einem Problem nebeneinander an demselben Computer. Eine Person übernimmt die Rolle des Beobachtenden und eine die des Schreibenden. Die beiden wechseln ihre Rollen häufig während der Arbeit. Der Beobachtende reviewt jede einzelne Zeile, die der Schreibende schreibt.

Bei dieser Review-Methode sind die Kommunikationswege besonders kurz und schnell. Das ermöglicht ein sofortiges Eingehen auf mögliche Fehler und unverzügliche Korrekturen, wodurch die Wartungskosten auf das Minimum reduziert werden.

Diese Methode erhöht allerdings auch die Entwicklungskosten, da nun zwei Entwickler*innen zur Erledigung einer Aufgabe benötigt werden. Sie eignet sich darum besonders für Entwicklungen, die sehr komplex sind und bei denen ein hoher Korrekturaufwand bereits erwartet wird.

Über die Schulter schauend

Bei dieser Methode setzen sich der Code-Reviewer und der Schreibende – im Gegensatz zu der Pair-Programming-Methode – ausschließlich zum Vollziehen des Code-Reviews an einen Computer zusammen. Sie gehen gemeinsam den geschriebenen Code durch, allerdings in der Regel nicht so ausführlich, wie Sie es beim Pair-Programming tun würden.

Anhand von Tools

Bei dieser Methode werden spezielle Review-Tools verwendet wie Review Board, GitHub oder Gerrit. Diese Tools bieten viele Funktionen, die ein Code-Review erheblich erleichtern. Die Entwickler*innen müssen sich nicht für jedes Review zusammensetzen und können die einzelnen Code-Stellen asynchron besprechen.

Wir verwenden das in Bitbucket integrierte Review-Tool, das dem GitHub-Review-Tool stark ähnelt. Auf dem Screenshot siehst du, wie das Review einer Code-Zeile bei uns aussehen kann.

Best Practices

Bei allen genannten Vorteilen von Code-Reviews kosten Code-Reviews auch Zeit und damit Geld. Damit du alle genannten Vorteile mitnimmst und sich deine Code-Reviews lohnen, müssen sie korrekt durchgeführt werden. Im Folgenden präsentieren wir sechs Best Practices, die sich bei uns als am wichtigsten erwiesen und die wir in unseren täglichen Review-Prozessen umsetzen.

1. Verstehe, wonach du suchen sollst

Um sicherzustellen, dass du nach dem Richtigen bei einem Code-Review suchst, kannst du einfach die folgenden Fragen für dich beantworten:

  • Ergibt das gegebene Konzept Sinn? Ist es gerechtfertigt, dass bestimmte Codeteile mit anderen interagieren?
  • Wird der geschriebene Code funktionieren?
  • Ist der Code komplexer, als er es sein muss, um das gegebene Problem zu lösen?
  • Sind entsprechend korrekte Tests geschrieben worden?
  • Ist eine korrekte Namensgebung vorhanden?
  • Gibt es genügend Kommentare und sind diese korrekt und verständlich in der richtigen Sprache geschrieben worden?
  • Sind alle Programmierstil-Richtlinien beachtet worden?

2. Reviewe nicht zu viel am Stück

Laut einer Studie zu Code-Reviews, die von einem Programmier-Team des Unternehmens „Cisco Systems” durchgeführt worden ist, sollten Reviewer nicht mehr als 200–400 Code-Zeilen untersuchen. In dem folgenden Diagramm kannst du sehen, wie die Fähigkeit, Fehler im Code zu finden, bei einem Review ab 400 Code-Zeilen (lines of code, kurz LOC) am Stück signifikant abnimmt.

Quelle: https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

3. Nimm dir Zeit

Schneller heißt nicht immer besser. Wie bei so vielen Dingen im Leben gilt es auch bei den Code-Reviews die richtige Balance zwischen Qualität und Quantität zu finden. Die Studie von Cisco Systems zeigt, dass Code-Reviews, durchgeführt mit einer Geschwindigkeit von bis zu 500 LOC pro Stunde am effizientesten sind. Bei mehr LOCs pro Stunde nimmt die Effizienz stark ab.

Quelle: https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

4. Mach Pausen

Dieses Phänomen ist dir sicher aus verschiedenen Situationen bekannt: Konzentrierst du dich zu lange am Stück auf eine Aufgabe, lässt deine Konzentration nach – und damit auch die Effizienz. Die Zeitmarke für effiziente Code-Reviews ist laut mehrerer Studien nach etwa einer Stunde erreicht.

5. Nutz Checklisten

Du hast bereits gelernt, nach welchen Punkten du bei Reviews suchen solltest. Um sie bei jedem Review präsent zu haben, solltest du dieses Wissen in einer Checkliste festhalten und die einzelnen Punkte bei jedem Review abarbeiten.

Vielleicht fallen dir auch weitere Fehler ein, die besonders oft von Mitgliedern deines Teams eingebaut werden. So kannst du deine Checkliste schrittweise erweitern und auf dein Team abstimmen. Checklisten gelten als eine der effektivsten Methoden, um sich häufig wiederholende Fehler zu eliminieren.

6. Führe eine positive Review-Kultur

Wo Code gereviewt wird, wird immer auch Kritik ausgeübt und – sind wir ehrlich – wirklich gerne, lässt sich niemand kritisieren.

Es ist essenziell, dass du deine Kritik begründest und sie objektiv ist. Sie sollte sich nie gegen die Person richten. Es ist einfach, aber überhaupt nicht hilfreich, Fehler nur als Problem zu sehen. Stattdessen sollte jeder Fehler als Chance genutzt werden, um dazuzulernen. Bring deinem Team eine positive Review-Kultur bei und lebe Sie vor.

Denn wie cool wäre es, Fehler, die üblicherweise Verlust für das Unternehmen bedeuten, in Profit umzuwandeln? Sehr cool.

Fazit

Code-Reviews sind also ein wichtiger Bestandteil der Softwareentwicklung. Sie ermöglichen ein frühes Abfangen von Fehlern, sorgen für eine bessere Code-Qualität und helfen deinem Team, sich weiterzuentwickeln.

Du solltest Code-Reviews in deinem Entwicklungs-Team einsetzen. Achte dabei auf die genannten Best Practices, denn falsch angewendet können auch Code-Reviews zu einer Zeit- und Kostenfalle werden.

Du hast noch mehr Fragen zu Code-Reviews und wie wir sie einsetzen? Dann schreib uns einfach eine E-Mail.

Artikel teilen

Mehr aus unserem Blog

5 Jahre Lean Ocean – Das Interview

Vor 5 Jahren ist Lean Ocean in einem WG-Zimmer gestartet. Und heute hat das Unternehmen nichts von seinem Startup Flair verloren – nur die Büros sind schicker geworden.
Im Video-Interview werfen unsere Geschäftsführer Oliver und Stephan zusammen einen Blick auf die Entwicklung von Lean Ocean, gemeinsame Meilensteine und was die Arbeit bei Lean Ocean prägt.

Ein Tag als Softwareentwickler bei Lean Ocean

Was macht eigentlich ein Softwareentwickler bei Lean Ocean und wie sieht ein üblicher Arbeitstag aus? Das erzählt dir Norbert im folgenden Blogartikel! Wir haben Norbert, einen unserer Developer, einen Tag lang begleitet und über die Schulter geschaut. Vom ersten Kaffee zum wohlverdienten Feierabend– hier erhältst du spannende Einblicke in einen abwechslungsreichen Arbeitstag.

Von der Idee zum Feature

Wie sieht es eigentlich bei Lean Ocean hinter dem Code aus? Wie läuft so ein Projekt ab und wie wird aus einer Idee dann ein richtiges Feature? In diesem Artikel beantworten dir Oliver und Tom die wichtigsten Fragen zu unserem brandneuen Format #behindthecode. Als erstes geht Oliver als CTO von Lean Ocean auf den Entwicklungsprozess von Features ein und dann gibt uns unser Projektmanager Tom noch ein paar Antworten.

Oliver Holz

Oliver Holz

holz@lean-ocean.com