Kommunikationstipps für die Code Review

Code Review und gutes Betriebsklima – das muss kein Widerspruch sein

Thomas Gude

© shutterstock.com/Minerva Studio

Code ist auch nur eine Sorte Text und Texte müssen vor Veröffentlichung korrigiert werden. Was im Journalismus und im Buchgewerbe Gang und Gäbe ist, führt in der IT-Branche hin und wieder zu Problemen. Doch die Code Review muss nicht zwangsläufig zu Zerwürfnissen im Team führen. Die Beachtung einiger Kommunikationsregeln kann hier Wunder bewirken.

Dass Texte nach Fertigstellung nochmals überprüft werden, ist in der Buchbranche fester Bestandteil des Herstellungsprozesses. Kein Buchmanuskript kommt ohne Lektorat und Korrektorat aus. In gewisser Weise ist jeder Programmcode auch nichts anderes als Text, eine Fehlerkontrolle durch eine zweite und möglicherweise dritte Person tut ihm ebenfalls gut. Im Gegensatz zur schon mehrere hundert Jahre alten Tradition des Lektorats steckt die Code Review jedoch noch in den Kinderschuhen, vor allem was ihren Platz in Arbeitsablauf und Teamprozess betrifft.

Nicht dass es in der Buchproduktion keine Spannungen zwischen Autor und Verlag gäbe, aber die mangelnde Tradition im IT-Bereich mag ein Grund dafür sein, dass viele Entwickler Code Reviews als einen der lästigeren Aspekte ihres Berufs begreifen. Viele haben wahrscheinlich ähnlich unangenehme Erfahrungen gemacht, wie die von Umar Mansoor geschilderten: Reviewer, die mit ihren (angeblich) überlegenen Skills prahlen, oder Entwickler, die sich vor Abschluss der Programmierung nicht in die Karten gucken lassen wollen oder andersherum die Kontrolle als Entschuldigung für Nachlässigkeiten benutzen.

All das kann den Reviewprozess uneffektiv und nervenaufreibend für die Beteiligten machen. Im Folgenden sind deshalb einige Punkte aufgeführt, die die Integration der Code Review in den Betriebsalltag flüssiger und zum gegenseitigen Vorteil der Beteiligten gestalten sollen:

Das Betriebsklima

Review-Vorgänge können vor allem dann ein destruktives Potential entfalten, wenn das Klima unter den Beschäftigten bereits zerstört ist. Wer seine Kollegen sowieso hasst, wird die Code-Durchsicht als Instrument ansehen, dem Gegenüber „schön eins reinzudrücken“. Hier hat vor allem das Management die dem Review-Prozess vorgelagerte Verpflichtung, ein positives Verhältnis zwischen den Beschäftigten zu stiften.

Wichtig ist dabei, eine gesunde Mischung zwischen Konkurrenz und Kooperation zu finden. Das gelingt am besten in einem Umfeld, wo hohe Qualität geschätzt wird. Beschäftigte, die sich engagieren wollen, weil sie sich mit dem Unternehmen und seinem Produkt identifizieren, werden eher Kritik üben, die der Sache nützt, also konstruktiv ausfällt. Wenn die Code Review zu einem Instrument wird, sich gegenseitig und die gemeinsame Sache zu pushen, ist viel gewonnen. Thorsten Meier merkt dazu auf JAXenter an:

Code Reviews sollten vor allem nicht zur ungeliebten Pflichtaufgabe werden. Vielmehr sollte man sie als Chance begreifen, voneinander zu lernen und gemeinsam die Codebasis zu verbessern.

Das Gegenteil davon ist eine scharfe Konkurrenzsituation, die die Teammitglieder anstachelt, sich gegenseitig auszubooten. Dies gilt es unter allen Umständen zu vermeiden. Es macht darum Sinn, als Vorgesetzter den Review-Vorgängen fern zu bleiben. Diese sollten unter Gleichgestellten erfolgen. Vom Reviewer Bewertungen über dessen Kollegen einzufordern, ist ebenfalls tabu, wie überhaupt der Rückgriff von Review-Ergebnissen in Leistungsbewertungen.

Lesen Sie auch: “Code Reviews sollten nicht zur ungeliebten Pflichtaufgabe werden”

Wie kommunizieren?

Eine Code Review sollte so sachlich wie möglich gestaltet werden, gerade weil der Prozess mindestens für den Entwickler etwas Persönliches ist, schließlich hat er/sie Zeit und Herzblut in sein Projekt gesteckt. Niemand lässt sich gerne das Produkt seiner Arbeit zerreißen; Vorsicht bei der Formulierung von Kritik ist also angebracht. Generell gilt: auch wenn es um die Sache gehen soll, sitzt der Reviewer doch einem menschlichen Wesen gegenüber, auf dessen Gefühle Rücksicht genommen werden sollte.

Formulierungen mit Bedacht wählen
Persönliche Angriffe verbieten sich, das ist klar. Aber häufig erscheinen Aussagen trotz gegenteiliger Intention als Angriffe, weil sie ungeschickt formuliert wurden und ungewollt konfrontativ wirken. Präzise Wortwahl muss ebenso erlernt werden, wie die Kunst, Kritik wertschätzend und konstruktiv artikulieren zu können. Es sollte auf jeden Fall vermieden werden, Kritiken als Ansagen, Forderungen oder Zurechtweisungen zu äußern. Code Reviews werden so nur als unangenehme Pflichtübung wahrgenommen, statt als Gelegenheit zur Verbesserung und Teambildung.

Gespräche statt Einbahnstraße
Kritiken in Frageform zu formulieren, lässt sie bspw. weniger als Standpauke erscheinen. Stattdessen bekommt die Review den Charakter eines Gesprächs unter Gleichen. Es sollte aber drauf geachtet werden, die Entwickler nicht unter Rechtfertigungsdruck zu setzen. Statt „Warum hast Du das so gemacht?“ ist eine Formulierung à la „Was hältst Du davon, es so zum machen?“ sinnvoller. Jetzt kann der Code-Autor seine Entscheidung erklären oder abwägen, ohne von einer defensiven Position aus argumentieren zu müssen.

Konflikte vermeiden
Manche Konfliktquellen lassen sich bereits von vornherein umschiffen, indem gemeinsame (Coding-)Standards festgelegt werden. Der Verweis aufs Regelwerk macht die Kritik objektiver, d.h. lässt sie nicht als subjektives Gutdünken des Reviewers erscheinen. Natürlich ist der Entwicklungsprozess nicht bürokratisch durchplanbar, häufig gibt es mehrere Wege ans Ziel zu kommen. Reviewer sollten versuchen, die Entscheidungen des Entwicklers zu verstehen und dann abzuwägen, ob ein anderer Weg vielleicht besser wäre. Von Grundsatzdebatten sollte nach Möglichkeit abgesehen werden.

Bescheidenheit auf beiden Seiten
Die Code Review ist keine Arena, um die eigenen Skills vorzuzeigen. Gegenüber dem Autor mit eigenen Kenntnissen aufzutrumpfen, verbietet sich selbstverständlich. Daher steht Reviewern ein gewisses Maß an Bescheidenheit gut zu Gesicht. So sollten sie vom Code des Entwicklers nicht auf dessen Fähigkeiten schließen, sondern Respekt vor seinen Entscheidungen und Meinungen zeigen, auch wenn sie nicht damit einverstanden sind. Auch bei harter Kritik darf darüber hinaus die Erwähnung des Positiven nicht vergessen werden.

Die Programmierer selbst sollten sich darüber im Klaren sein, dass sie nicht als Person in der Kritik stehen, sondern ihr Produkt. Dessen Fehler werden gesucht, nicht die des Entwicklers, der sich daran erinnern sollte, dass er wahrscheinlich emotional an seinem Werk hängt und nicht vollkommen objektiv ist. Etwas distanzierter an die Sacher heranzugehen, erleichtert die Annahme von Kritik. Ein gesundes Selbstbewusstsein ist dennoch angebracht, wenn man seine Ideen erklärt und verteidigt. Schlussendlich sollte man dem Reviewer für seinen Arbeitsaufwand und sein Feedback danken.

Lesen Sie auch: Codereviews: Tipps, Tools und Techniken

Fazit

Die Code Review ist nicht allein ein technischer Prozess, sondern ein zwischenmenschlicher, der noch dazu ein gewisses Konfliktpotential birgt. Umsichtige, behutsame Kommunikation ist darum von allerhöchster Wichtigkeit, um Review-Vorgang und Teamprozess in Bahnen zu lenken, die produktiv für das Projekt als Ganzes sind.

Aufmacherbild: Businessman scolding a colleague von Shutterstock.com / Urheberrecht: Minerva Studio

Geschrieben von
Thomas Gude
Thomas Gude
Thomas Gude studiert Buch- und Medienpraxis an der Goethe Universität Frankfurt am Main und arbeitet seit August 2015 als Werkstudent bei Software & Support Media. Vorher hat er Politikwissenschaft und Politische Theorie in Hannover und Frankfurt am Main studiert.
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "Code Review und gutes Betriebsklima – das muss kein Widerspruch sein"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Christian
Gast

So mancher Reviewer hätte sich an der Formulierung „die Review“ gestört… 😉

Christian
Gast

Eine ganz gute Einstellung ist, zu versuchen, so neutral wie ein Compiler zu sein. Ein Compiler würde nie einen vorwurfsvollen Ton anschlagen, sondern einfach nur sachlich darauf hinweisen, was falsch oder ungünstig ist.

Hilfreich ist auch, wenn in einem Team jeder begutachtet und begutachtet wird. Es ist ungünstig, wenn es einen Oberinspektor gibt, dessen Code nie von anderen begutachtet wird.