10 Gründe für Code Reviews

Code Reviews helfen Entwicklern die Software in Projekten und sich selber stark zu verbessern. Diese Arbeitsbedingungen sind auch eine wichtige Voraussetzung und aktueller Anspruch an einen guten Arbeitgeber für gute Entwickler. Und gute Web-Developer wechseln zur Zeit immer häufiger aus genau diesen Gründen den Job und suchen gute und motivierte Teams. Das darf man sich gerade in diesen und kommenden Zeiten nicht entgehen lassen. Damit die Einführung von Code Reviews gut klappt gibt es hier 10 Gründe und Tipps für einen erfolgreichen Start und die Durchführung regelmäßiger Code Reviews für eine effizientere und nachhaltigere Softwareproduktion. Dabei richtet sich der Artikel vor allem an das Management, Lead Developer und Entwickler, die ihre Art zu arbeiten verbessern wollen. Jeder, der ein Entwicklerteam leitet möchte, dass sich die Web-Developer mit dem Projekt identifizieren und die Produkte sowie Ergebnisse mit Leidenschaft als auch Sorgfalt verbessern. Das bedeutet die Qualität zu steigern und gemeinsam voneinander zu lernen und diese Innovationen in zukünftige Arbeiten einfließen zu lassen. Das bedeutet allerdings auch seine bisherige Arbeitsweise komplett zu ändern. Denn ab jetzt sind es mehr Ziele, als einfach nur fertig zu werden. Es geht auch um Lesbarkeit, Wartbarkeit, Sicherheit, Performance und Best Practice. So viele Ziele können nur in einem gut eingespielten Team erreicht werden. Code Reviews – die so einfach und beiläufig wie ein Schulterblick gestaltet werden können – sind eine tolle Möglichkeit genau diese Ziele zu erreichen. Das gelingt allerdings nur, wenn das Team dieses Mittel zum Zweck auch einsieht und sich der Vorteile auch bewusst wird. Genau das ist der Punkt an dem Vorgesetzte und Lead Developer gefragt sind. Hier geht es konkret um die Einführung eines messbaren Qualitätsstandards, der Gründung einer Teamkultur und einen Workflow umzusetzen, in dem die eigenen Mitarbeiter ihr bestes geben wollen und können.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”

Martin Golding

Kostenloses Training und Know How Transfer für Entwickler

Mit dem Ziel Bugs zu vermeiden und schnell zu finden sehen Web-Developer in Code Reviews eine echte Chance voneinander zu lernen und sich mit gegenseitigem Know-How-Transfer weiterzubringen. Das bringt das Team natürlich auch enger zusammen und steigert auch die Verbundenheit und Identifikation mit dem Projekt. Dadurch entsteht eine gewisse Leidenschaft, die bessere Ergebnisse und ein viel besseres Teamklima bringt. Einfach gesagt ist ein Code Review auch ein Ausdruck der Einstellung der Firma gegenüber Softwarequalität und des respektvollen Umgangs miteinander. Es ist ein wichtiger Bestandteil eines nachhaltigen und agilen Workflows. Inhaltlich geht es hier auf verschiedenen Leveln von der Performance-Verbesserung, über Clean Code und Lesbarkeit bis hin zu infrastrukturellen Verbesserungen. Am Ende haben immer alle Beteiligten, das Projekt und der Kunde etwas davon. In Developer-Teams in denen mit Code Reviews gearbeitet wird, versteht jeder die Code-Basis und die Verarbeitung der Daten. Viel wichtiger ist allerdings auch, dass jeder versteht warum Entscheidungen getroffen werden und was dahinter steckt. Das ist viel wichtiger, als einfach nur den Programmablauf zu kennen. Wenn es beispielsweise darum geht eine Applikation möglichst schnell zu machen, dann kann das immer bei Entscheidungen berücksichtigt werden. Das macht es dann insgesamt einfacher gemeinsam neue Wege in einem Projekt zu gehen, da sich jeder über das große Ziel im klaren ist. Code Reviews machen allen Entwicklern die Code-Basis zugänglich und nicht nur den Teil, an dem sie konkret arbeiten. Dadurch bekommen sie ein sehr gutes Gesamtbild und sind in der Lage, Aufgaben oder auch Bugs an anderen Stellen zu beheben ohne sich lange in den Code einlesen und einarbeiten zu müssen. Die Zeit, die hier gespart wird, kann man mit der Anzahl der Entwickler multiplizieren. Das macht die Arbeit dann wirklich effizient und effektiv. Alles in allem verbessert es auch die Kommunikation untereinander und macht diese auch erst möglich. Denn man kann nur über Dinge qualifiziert sprechen, wenn man weiß um was es geht. Das zeichnet Teamwork am Ende aus. Der Workflow von Code Reviews ist leider oft falsch organisiert. Code wird von einem Entwickler lange und alleine fertig gestellt und dann von einem anderen Entwickler zu einem anderen Zeitpunkt und auch ohne direkten Austausch beurteilt. Wenn die automatisierten Tests und auch statische Code-Analysen erfolgreich waren, muß hier also nur die konkrete Umsetzung beurteilt werden. Ohne konkret miteinander zu reden und sich den Code in diesem Moment gemeinsam anzuschauen, ist es aber sehr schwer hier in einen innovativen Zustand zu kommen. Hier kann nur noch die Lesbarkeit, Performance und Sicherheit beurteilt und verbessert werden. Wenn man allerdings hier noch einmal gemeinsam miteinander darüber spricht und den Code Review als Pair Programming gemeinsam durchführt, dann kommt der Know-How-Transfer, die Leidenschaft und daraus resultierend die Innovation. Voraussetzung für jede Teamarbeit bei Entwicklern bleibt natürlich die Tatsache, dass jeder den Code und, nach Möglichkeit, die gesamte Applikation versteht. Wenn nur ein Entwickler einen bestimmten Teil einer Anwendung versteht, dann ist das ein sehr hohes Risiko für den Entwickler, das Team und für das Unternehmen. An dieser Stelle entsteht unnötiger Druck, da die Verantwortung nicht geteilt werden kann. Code Reviews schaffen hier Abhilfe und verteilen die Verantwortung und das Wissen. Das entlastet alle und ist nachhaltig für die Ressourcen im Projekt. Richtig eingesetzte Code Reviews geben Entwicklern die Möglichkeit zu erklären, warum sie etwas so umgesetzt haben und was sie hier verbessern konnten und an welcher Stelle es Barrieren oder Schwierigkeiten gab. Allein das kann Softwarequalität schon steigern, da dieses Erklären auch eine weitere Know-How-Verinnerlichung ist und das Wissen vertieft. Das schafft auch ein weiteres Bewusstsein dafür, ob es die richtige Lösung für das Problem war und ob hier weitere Innovationen möglich sind. Das Feedback von weiteren Entwicklern in einem Code Review ist unter diesen Umständen keine Kritik mehr, sondern eine Chance seinen eigenen Code weiter zu verbessern und durch Teamwork das große Ganze zu verbessern.

„What one programmer can do in one month, two programmers can do in two months.“ – Fred Brooks

— Programming Wisdom (@CodeWisdom) 2. März 2017

Code Reviews sparen Zeit und Geld

An dieser Stelle müssen wir nicht mehr erklären, warum Bugs, je später sie gefunden werden, immer teurer werden. Wichtig ist nur zu wissen, dass viel Zeit, Nerven und vor allem Geld gespart wird, wenn sie früh gefunden werden. Aktuelle Entwicklungen werden in diesem Moment natürlich auch immer unterbrochen und leiden nicht nur in zeitlichen Verlusten, sondern auch die mentale Belastung der Entwickler ist in diesem Moment sehr hoch. Hier entsteht neben zeitlichen Druck auch extrem gesundheitsschädlicher Stress. Das ist natürlich kritisch und erfordert auch Handlungen auf Management-Ebene. Das zahlt übrigens auch kein Kunde. Entwickler wünschen sich hier gerade von BWL- und Kennzahlen-getriebenen Management den nötigen Weitblick. Code Reviews und Pair Programming ist nichts was Ressourcen verbraucht, sondern genau diese schafft. Sie rentieren sich, konsequent angewendet, tatsächlich sehr schnell. Allerdings müssen sie sich auch erst entwickeln und etablieren wenn es hier keine Erfahrungen gibt. An dieser Stelle lohnt es sich auch auf Coaches zurückgreifen. Moderierte Team-Pair-Programming-Sessions gibt es auch bei Never Code Alone und der Entwicklungshilfe NRW. Es kostet Zeit Code Reviews einzuführen und durchzuführen. In der Zeit wird die eigene Arbeit unterbrochen, man muss sich mental auf den Code Review einstellen und dann wieder zurück an die eigene Arbeit gehen. Code Reviews müssen natürlich zeitnah durchgeführt werden. Sonst blockieren sie den gesamten Entwicklungsprozess. Aber am Ende des Tages werden hier Bugs schneller gefunden und auch präventiv vermieden. Allerdings geht es nicht nur um Bugs, aber die sind hier eine echte messbare Größe und können gut erfasst werden. Code Reviews verzögern ein Rollout auch nicht um Tage, sondern höchstens um wenige Stunden. Im Grunde rentieren sie sich bereits mit einem Bug, der hier gefunden wird.

Gute Developer suchen gute Arbeitsbedingungen

Wir suchen händeringend neue und gute Entwickler. Das beruht auf Gegenseitigkeit. Entwickler suchen auch bessere Arbeitsbedingungen und akzeptieren nicht mehr die billige Kesselflickerei und das ewige Warten auf die Einlösung von Zusagen, dass sich endlich etwas ändert. Es gibt Arbeitgeber, die diesen Trend erkannt haben und zu denen kommen gute Entwickler von ganz alleine. Gute Entwickler sind durch die vielen Community-Aktivitäten und Konferenzen sehr gut untereinander vernetzt. Gute Arbeit und glückliche Entwickler sind also die beste Employer-Branding-Maßnahme. Code Reviews sind guten Entwicklern sehr wichtig, da sie wissen, dass es praktisch keine bessere persönliche Weiterbildung gibt. Und sich selber weiterzuentwickeln ist ihnen ein ganz wichtiges Ziel im Leben. Nicht auf der Stelle zu treten und den Anschluss zu verpassen, davon sind sie fast schon besessen. Aber auch in einem Team mit gleichgesinnten Entwicklern zu sein und gemeinsam Software zu produzieren und zu verbessern – als Team. Sie wollen keine Einzelkämpfer mehr sein, die jeden Tag unter viel Druck ihre Gesundheit riskieren. Das Thema wird Entwicklern immer wichtiger, da die Krankheitsbilder wirklich hart sind und die Heilung sehr lange dauert und das einfach nicht der Sinn im Leben ist.

Das Ziel ist es projektübergreifende Innovationen zu erzielen

Was ist die Definition eines Code Reviews? In einem Code Review beurteilen Entwickler den erstellten Code eines anderen Entwicklers. Ein Code Review in einer größeren Gruppe macht übrigens keinen Sinn, da sich hier gerne in einer Code Philosophie verloren wird. Solche Gruppen Meetings bieten sich allerdings sehr gut für ein erweitertes Pair Programming an. Hier können neue Features sehr schnell und gut gestartet werden. In einem Code Review geht es aber um den eigentlichen “Review”, also die Beurteilung und Feedback zu einer konkreten Umsetzung. Eine typischer Situation ist die Hilfestellung eines Senior Developers bei einem Junior Developer, der Tipps und Feedback im Bezug auf Lesbarkeit, Sicherheit oder Performance gibt. Das kann durch einen einfachen regelmäßigen Schulterblick passieren. Aber auch die kurze Einforderung von Feedback auf technischer Augenhöhe entspricht schon einem Code Review. Klassisch ist ein Code Review auch ein Merge bzw. Pull Request in einer Versionsverwaltung, wie GitLab. Hier gibt es grafische Oberflächen auf denen Änderungen genau dargestellt werden und akzeptiert oder mit Feedback abgelehnt werden können. Fakt ist: nicht jeder Code der läuft, ist gleichzeitig auch gut. Code Reviews sollten aber nicht erst am Ende eines Entwicklungsprozesses stehen. Ganz im Gegenteil, bereits der kurze fachliche Austausch sorgt für einen kreativen Impuls und motiviert alle Beteiligten in dem Projekt ein besseres Ergebnis zu erzielen.

Das Team entwickelt sich gemeinsam weiter

Kreative Arbeit ist ohne Spaß nicht zu bewältigen. Judith Andresen hatte dieses Zitat aus dem Top Talk auf den code:talks zum Thema Arbeitsbedingungen in der IT von mir aufgegriffen. In jeder Code-Review-Session lernt mindestens eine Person etwas Neues. Da Weiterbildung im Tagesgeschäft praktisch nicht existiert, bietet ein Code Review eine gute Chance eine kontinuierliche und wohl-dosierte Form des Know-How-Transfers auf einzelne Entwickler zu bringen. Hier steht vor allem das begehrte “Best Practice” Experten-Know-How automatisch im Fokus. Wissen, dass man sich vielleicht gar nicht zugänglich machen kann, weil es auch ein harter und langer Weg ist. Da ist auch jeder froh, wenn er sich so einen Weg sparen kann. Sich gemeinsam über den Code eines aktuellen Projekts auszutauschen, ändert die Einstellung und Denkweise von Entwicklern im Bezug auf logische Operationen, Lesbarkeit und Wartbarkeit. Viel wichtiger ist allerdings, dass in diesem Moment auch der Blick über den Tellerrand in Richtung User Story und Anforderungen an die Applikation geht. Zeiten ändern sich. Jüngere Entwickler kennen sich häufig besser mit neuen Technologien im globalen Software-Trend aus. Diese Entwickler haben auch auf ihren eigenen Rechnern viel aktuellere Setups eingerichtet und bringen sehr wichtiges Know-How in Teams, mit dem man erst in der Lage ist diese neuen Möglichkeiten zu bewerten und auch in den aktuellen technologischen Stack zu integrieren.

#codetalkshh „Kreative Arbeit ist ohne Spaß nicht zu bewältigen.“ @nevercodealone

— Judith Andresen (@janosch007) 18. Oktober 2018

Hier lernen also auch Senior-Entwickler direkt von Junior-Entwicklern. Im gegenseitigen Austausch geht es daher nicht nur um Technologien und Algorithmen, sondern auch darum interne Standards einzuführen. Das hilft alle gemeinsam an einem Strang ziehen zu lassen und in eine Richtung zu gehen zu lassen. Solche Standards heben auch die Stimmung im Team, da Dinge einfach auch mal entschieden wurden und nicht immer für neuen Diskussionsstoff sorgen. Das macht auch das Onboarding für neue Entwickler wesentlich einfacher und effizienter. Aber natürlich werden damit Entwickler nicht automatisch zu Teamplayern. Kritiker von Code Reviews führen immer wieder zwei Gründe gegen Code Reviews auf. Einmal habe der Entwickler vor dem Review nicht verstanden, wo das konkrete Problem gelegen habe. Das kann man recht einfach durch ein gemeinsames Review lösen oder vielleicht auch mit Pair Programming weiterbringen. Als zweiter Grund wird auch immer die Zeit als Argument, oder vielleicht auch als Ausrede aufgeführt. Es müsse halt fertig und nicht schön werden. Das ist eine grundsätzlich falsche Einstellung. Zitat: Es dauert nicht länger sauberen Code zu schreiben, aber viel länger mit schlechtem zu Leben Wichtig ist es Code Reviews früh und regelmäßig durchzuführen. Wenn es zu spät ist, dann will das keiner mehr. Hier werden Code Reviews auch extrem unwirtschaftlich. Das kann den gesamten Aufwand dann schnell verdoppeln und auf die Stimmung drücken. Frühe und regelmäßige Reviews bringen Teams und Code allerdings sehr gut nach vorne. Dann sprechen Coder auch eine gemeinsame Sprache.

Code Reviews brauchen den richtigen Zeitpunkt im Prozess

Es ist eine Sache Code Reviews einzuführen. Aber eine andere Sache ist es, das erfolgreich und effizient zu tun. Und das hängt sehr stark von dem Zeitpunkt und der Art der Durchführung ab. Im Allgemeinen ist es besser Code Reviews möglichst früh und auch öfter durchzuführen. Dann gehen Meinungen und auch das Arbeitsergebnis nicht so weit von dem “Best Practice”-Ergebnis auseinander. Es ist wichtig, dass Entwickler das Feedback eines Reviews als Hilfe und Unterstützung für ihre Arbeit bekommen. Und gerade dann sind Code Reviews auch stark. Der helfende Schulterblick, der eine zweite Meinung und Feedback zu einem aktuellen Lösungsweg gibt, hilft sehr schnell und effektiv. Wenn der ganze Task fertig ist, dann kann eine Code Review als zusätzliche Belastung oder gar als Schikane wahrgenommen werden. Hier klären sich dann auch keine Fragen mehr zur User Story und zum gesamten Verständnis. Das Ziel ist doch, dass keine Entwicklung in die falsche Richtung oder gar in Einbahnstraßen läuft. Und das hilft und ist wichtig. Hier wird auch der tatsächliche Entwicklungsaufwand klar und auch mit einer zweiten Meinung bestätigt. Dann heißt es nicht mehr “Warum brauchst du dafür länger?”, sondern “Das dauert hier länger weil…”. Das ist sehr wichtig für das Betriebsklima und die Arbeitsbedingungen.

Teamfähigkeit, Ansprüche und Ziele von Code Reviews

Offene Kommunikation und Transparenz ist gerade für die Management-Ebene wichtig. Nur so kann auf Dinge frühzeitig reagiert werden und dadurch Stress und Druck vermieden werden. Frühe und regelmäßige Code Reviews helfen dabei, diese Transparenz zu fördern. Konkret geht es hier um Feedback. Die Aufgabe eines Lead Developers ist es an dieser Stelle anderen Entwicklern beizubringen, wie man mit Feedback umgeht und wie man auch selber Feedback gibt. Hier geht es ja auch immer darum neues Wissen zu empfangen und auch zu vermitteln. Das alles sind im einzelnen sehr sensible Themen, die auch einen inneren kulturellen Wandel erfordern. Und diesen Weg wollen nicht alle gehen. Bei einer agilen Transformation geht man von 30% der Belegschaft aus, die nicht zu der neuen Unternehmenskultur passen und das Unternehmen verlassen müssen. Auf der anderen Seite ist ein Code Review allerdings auch ein wichtiges Werkzeug, dem Team zu helfen bessere Software zu produzieren und die eigenen Fähigkeiten deutlich zu steigern. Richtig eingesetzt machen Code Reviews aus Einzelkämpfern echte Developer-Teams und fördern den Zusammenhalt. Denn jeder Entwickler hat hier auch eine größere Rolle, da der Aufgabenbereich und die Verantwortung und auch das eigene Wort mehr Gewicht bekommen. Das hilft bei der Identifikation mit der Software, dem Unternehmen und dem Team. Insgesamt können gut eingespielte Teams gemeinsam so schneller Software und gerade neue Features produzieren. Wichtig ist an dieser Stelle der Hinweis, dass Code nicht geändert werden muß und hier weniger ganz klar mehr ist. Code Reviews sollen Prozesse nicht länger und komplizierter machen, sondern unterstützen und verbessern. Es geht um die Einhaltung von Code-Standards, die im Team kommuniziert sind und die Verbesserung der Lesbarkeit. Darüber hinaus geht es darum, Komplexibilität durch den zweiten Blick zu erkennen und abzubauen.

TYPO3 Review Days in Düsseldorf

Open-Source-Projekte wie TYPO3, haben Code Reviews fest in ihren Entwicklungsprozess etabliert. Als PHP-Entwickler kann man hier immer aktuelle Merge Requests mit reviewen und damit helfen, das Projekt und sich selber als Entwickler weiterzubringen. Die TYPO3 GmbH bieten einmal eimal Monat an einem Freitag die Möglichkeit hier auch im TYPO3-Headquarter selbst vorbeizuschauen und mitzumachen. Das ist wirklich sehr gut, da man schnell Feedback bekommt und auf die Bahn gebracht wird. Hier lernt man immer auch selber sehr viel und ist auch eine gute, geschätzte und respektierte Hilfe. Hier geht es zu einem Blog Post zu den TYPO3 Review Days im Blog von dkd.