Code-Review: 7 häufige Fehler
Code-Reviews können die Qualität deines Codes stärker verändern als du denkst. Es gibt aber eine Bedingung: Es gehört richtig gemacht, um auch wirklich das volle Potenzial auszuschöpfen. Hier sind die häufigsten Fehler, welche beim Code-Review passieren können.
1. Zu viel Fokus auf Style und Syntax
Solche „Reviews“ sieht man oft: es geht eigentlich nur um die oberflächliche Schreibweise. Sauberkeit ist zwar wichtig, aber wenn es möglicherweise dringendere Probleme gibt. Dieser Fehler wird so oft gemacht, weil diese Schreibfehler wirklich leicht zu finden sind. Das Auge eines jeden Entwicklers ist es gewohnt, zusätzliche Leerzeichen, unnötige Codezeilen usw. zu korrigieren. Wir tun dies automatisch.
So geht es:
Wenn man etwas automatisch macht, wird eine Maschine es noch besser automatisch machen. Am besten, man legt einen Styleguide fest und verwendet bestimmte Tools, um den Code automatisch zu verbessern. Alle Entwickler im Unternehmen sollten es verwenden, unabhängig davon, ob sie mit Emacs, VIM, Visual Studio oder IntelliJ arbeiten. Tools für die statische Code-Analyse können viele Unregelmäßigkeiten erkennen und sind besser als jeder Mensch. Die Definition des Styleguides und der Code-Analyse sollte die Voraussetzung für einen guten Review sein.
Ein Review sollte sich eher mit Syntaxvereinfachungen beschäftigen, die von automatischen Tools nicht erkannt werden können. Es ist einfach, sich in Kleinigkeiten und Tippfehler zu verlieren. Das Hauptziel ist aber das größere Gesamtbild zu verstehen und zu verbessern.
2. Übersprungene Tests
Man sieht viele Tests in Reviews, aber man wirft bloß einen kurzen Blick darauf und geht gleich weiter zur Implementierung. Tests im Review sind langweilig. Immer wieder setup, assert, teardown – und wiederholen. Bei so vielen Wiederholungen ist man meist nicht mehr so aufmerksam: „Wird schon passen.“
Leider wird es nicht immer „passen“. Infolgedessen kommen einige Tests erfolgreich durch das Review, obwohl sie eigentlich nicht sollten; so wie etwa Tests, welche von anderen Tests abhängig sind, oder Tests für triviale Dinge, etc.
So geht es:
Tests sind schlussendlich auch Code und verdienen auch ein ordnungsgemäßes Review. Das ist auch eine hervorragende Gelegenheit, um zu überprüfen, ob dein Code überhaupt ordnungsgemäß getestet wird. Solche Dinge erfordern viel Konzentration und Verständnis für jede Änderung - deshalb ist es nicht einfach. Alle Beteiligten sollte auf das auch achten, denn wenn nicht jeder auf dem gleichen Stand ist, wird das ein Kampf gegen Windmühlen. Es gehört klar definiert, was getestet werden soll, wie es vonstatten geht, was für den Betrieb der App entscheidend ist, usw. Idealerweise gehen dann alle auch noch einen Pakt ein für die Einhaltung der Regeln ;-)
3. Nur die neuen Sachen durchschauen
Meist schenkt man ja diesen neuen, grünen Codezeilen mehr Aufmerksamkeit als den gelöschten, roten? Ja, meistens ist das Hinzufügen von Code wichtiger, aber eine alte Zeile, die versehentlich gelöscht wurde, kann zu einem echten Unruhestifter werden, wenn man kein gut getestetes System hat.
So geht es:
Während aller Änderungen werden die vorherigen, gelöschten Zeilen angezeigt. Auf diese Weise kann man alte und neue Zeilen vergleichen und feststellen, welche Unterschiede es gibt, sofern diese nicht bereits offensichtlich sind. Aber man kann auch einen Schritt tiefer gehen: Beispielsweise, wenn etwa eine Method entfernt wurde, ist der Code Review die richtige Zeit um festzustellen, ob auch entsprechend alle Calls gelöscht wurden. Auf der anderen Seite lohnt es sich zu prüfen, ob ein gelöschter Call die letzte Verwendung einer bestimmten Method im Code war. Vielleicht kann man ja entsprechend auch dann die unnötige Method auch gleich mit löschen.
4. Schlechtes Timing
Eine halbe Stunde vor der Demo ist kein besonders geeigneter Zeitpunkt für einen Code Review. Oft sieht es so aus: Zusammen mit einer Anfrage zum Review erhält man eine Nachricht: „Du musst nur schnell sicherstellen, dass alles okay ist. Wir deployen in 15 Minuten eine Demo.“ Alles klar.
Eine ordnungsgemäßes Review erfordert Zeit, mit viel Stress kann man schlussendlich auch nicht die Qualität des Codes gewährleisten. Solche Situationen entstehen oft durch schlechtes Management, sodass sich Programmierer dann nicht verantwortlich fühlen. Ganz unabhängig davon wer schuldig ist, vor lauter Schnell Schnell hat sich wo ein falscher Code eingeschlichen und wird vielleicht sogar unbemerkt dort bleiben.
