Schlecht eingestellte Prozesse bei der Softwareentwicklung können einem Unternehmen anstelle der erwarteten Vorteile beträchtliche Schäden zufügen. Wenn du unseren vorherigen Artikel „Code Reviews: Nützlich oder Zeitverschwendung?“ gelesen hast, weißt du bereits, dass auch das Code Review dazu gehört – also die Qualitätskontrolle des Codes nach festgelegten Regeln. Ein Code Review findet vor dem Speichern des Quellcodes im Repository statt und wird von einem Entwickler durchgeführt, der nicht an der Programmierung dieses Codes beteiligt war. Es kann ein breites Spektrum an Aktivitäten umfassen, vom einfachen Lesen des Codes zusammen mit dem Autor an einem Computer bis hin zu Teammeetings, bei denen jede Codezeile besprochen wird. Beide Teilnehmer, die am Code Review beteiligt sind, sollten in der Lage sein, zusammenzuarbeiten. Die für die Codekontrolle festgelegten Prozesse und Kriterien sollten im Voraus bekannt sein, andernfalls besteht die Gefahr, dass sich die Prozesse unnötig in die Länge ziehen und Spannungen zwischen den beiden Seiten entstehen. In diesem Artikel konzentrieren wir uns darauf, die Prozesse der Codekontrolle zu optimieren, sowie auf Tipps und Tricks für beide Seiten, den Autor und den Reviewer.

Allgemeine bewährte Praktiken
- Wenn ein Softwareunternehmen die Codeüberprüfung als Teil der Definition of Done (d.h. der Bedingungen, die erfüllt sein müssen, damit eine Aufgabe als erledigt gilt) definiert, muss es unbedingt die nötige Zeit im Planungsprozess vorsehen. Es gibt nichts Schlimmeres, als wenn eine Überprüfung unter dem Zeitdruck einer bevorstehenden Frist für die Entwicklung der aktuellen Version nicht gründlich durchgeführt wird.
- Die Effektivität der Codeüberprüfung liegt in der Minimierung der Interaktionen zwischen den beiden Parteien sowie in der Reduzierung der für die Überprüfung benötigten Zeit. Wenn ein Autor etwas überarbeitet bekommt, ist es ideal, wenn er oder sie dann alle notwendigen Informationen darüber hat, was geändert werden muss, damit die nächste Überprüfung ein Erfolg wird.
- Die Kommunikation zwischen dem Prüfer und dem Autor sollte von Verständnis und Einfühlungsvermögen geprägt sein. Das Ziel ist es, zusammenzuarbeiten und gemeinsam Schwachstellen im Code zu identifizieren. Es geht nicht darum, darüber zu streiten, wessen Lösung besser ist, oder Assoziationen wie „Er hat gesagt, dass mein Code schlecht ist, also sagt er eigentlich, dass ich schlecht bin“ aufzustellen.
- Bei der Codeüberprüfung wird nicht geprüft, ob der Code funktioniert. Nur getesteter Code wird geprüft.
- Der Code-Check sollte nicht länger als eine Stunde dauern. Wenn wir eine Tätigkeit ausüben, bei der wir uns über einen längeren Zeitraum konzentrieren müssen, wird unsere Leistung nachlassen.
Autor des Codes – Best Practices
- Indem du jemanden bittest, sich deinen Code anzusehen, belästigst du niemanden.
- Es ist ratsam, dein Lösung vor der Codeüberprüfung durchzugehen und Stellen anzupassen, die der Reviewer bemängeln könnte. Nach mehreren qualitativen Code Reviews bekommst du ein Gefühl dafür und wirst wissen, worauf du deine Aufmerksamkeit richten solltest.
- Nimm Feedback niemals persönlich, es wird der Code bewertet, nicht deine Persönlichkeit.
- Der Autor sollte umfangreiche Pull Requests vermeiden. Es ist ratsam, kleinere, separat funktionierende Einheiten zur Überprüfung zu schicken. Das beschleunigt nicht nur den Überprüfungsprozess, sondern macht es auch einfacher, den Code anschließend zu korrigieren.
- Wenn dem Reviewer einige Teile des Codes nicht gefallen, versuche statt hartem Argumentieren (oder im schlimmsten Fall Streiten), mehr Informationen von ihm zu bekommen. Mit einer Frage wie „Wie würdest du diesen Teil programmieren?“ kannst du erfahren, wie du den betreffenden Codeabschnitt verbessern kannst.
- Als Autor des Codes solltest du dir detaillierte Notizen machen – erwarte nicht, dass du diese vom Reviewer erhältst.
Reviewer – Best Practices
- Er sollte die Codeüberprüfung nicht aufschieben, da jemand darauf wartet, dass er sich den Code ansieht. Daher ist es ratsam, der Codeüberprüfung Priorität einzuräumen. Das beschleunigt den Prozess und nimmt die Frustration des Wartens.
- Zu Beginn einer Codeüberprüfung ist es eine gute Idee sicherzustellen, dass der Autor versteht, dass es kein persönlicher Angriff ist, wenn er etwas überarbeitet, denn es gibt gute Gründe, dies zu tun. Zum Beispiel. Das Zusammenfassen von zwei Schleifen in eine zur Optimierung.
- Der Rezensent gibt ein Feedback und sollte es in einem optionalen Stil formulieren, d.h. dass es gut wäre, wenn der Autor dies oder jenes überarbeitet hätte. Nicht in dem Stil, dass der Autor dies noch korrigieren muss.
- Der Prüfer sollte sich mehr auf die Struktur des Codes als auf einzelne Zeilen konzentrieren. Codezeilen, auch wenn sie in einem eigentümlichen Stil geschrieben sind, sind relativ in Ordnung, solange sie funktionieren, schlimmer ist es bei umständlichem und fehleranfälligem Code. Wir empfehlen daher, deine Energie auf die wichtigen Teile des Codes zu konzentrieren.
- Es ist besser, den zu überprüfenden Code zuerst allein anzusehen, sich eine Meinung zu bilden und gegebenenfalls Fragen an den Autor vorzubereiten. Wenn wir den Code zum ersten Mal in einem gemeinsamen Meeting mit dem Autor sehen, besteht die Gefahr, uns von seiner Verteidigung beeinflussen zu lassen.
- Beschuldige den Autor niemals, etwas falsch gemacht zu haben. Du kannst fragen, ob es einen bestimmten Grund gibt, warum er sich für diese Variante entschieden hat. Wenn wir etwas sehen, das uns nicht gefällt, ist es hilfreich, es so zu formulieren: „Wenn ich das gemacht hätte, dann …“ und dies mit einem konkreten Beispiel zu untermauern.
- Der Reviewer sollte sich nicht damit brüsten, dass er den Code in weniger Zeilen und schneller geschrieben hätte.
- Es muss konkret sein. Ein Feedback wie „Das könnte man besser machen“ ist nicht konstruktiv und der Autor wird nicht wissen, wie er es in besseren Code umsetzen soll. Es ist besser, wenn der Autor Notizen mitnimmt, wie er die Dinge konkret verbessern kann.
- Wenn ein größerer Teil des Codes geändert werden muss, ist es ratsam, ausreichend Zeit einzuplanen, um dies persönlich mit dem Autor durchzugehen und alle gestellten Fragen zu beantworten.
- Er sollte auch alles loben, was nicht negativ ist, beziehungsweise was so programmiert ist, wie wir es erwarten.
Wenn du ein Java Programmierer bist und nach Arbeit suchst, schau dir unsere Mitareiterbenefits an und reagiere auf die neuesten Stellenangebote.
Über den Autor
Jozef Wagner
Java Developer Senior
Viac ako 10 rokov programujem v Jave, momentálne pracujem v msg life Slovakia ako Java programátor senior a pomáham zákazníkom implementovať ich požiadavky do poistného softvéru Life Factory. Vo voľnom čase si rád oddýchnem v lese, prípadne si zahrám nejakú dobrú počítačovú hru.