4 Augen sehen mehr als 2

Hallo Spaß Coder,

ist euer Code immer perfekt? Macht ihr keine Fehler? Habt ihr immer auf Anhieb die beste Struktur und Architektur gefunden? Dann ist dieser Artikel nichts für euch. Heute wollen wir uns mit dem Thema beschäftigen, wie wir im Team voneinander lernen können.

Eine Möglichkeit, Wissen im Team zu verteilen und zu lernen, haben wir mit dem Pair Programming ja bereits vorgestellt. Diesmal schauen wir uns an, wie wir auch in verteilten Teams gemeinsam zu besserem Code kommen können. Dabei helfen uns Code Reviews.

 

Was ist ein Code Review?

Unter einem Review verstehen wir in der Softwareentwicklung die manuelle Überprüfung der Arbeitsergebnisse. Beim Code Review geht es dabei insbesondere darum, den entstandenen Code zu prüfen. Wir schauen uns den Code eines Kollegen an und prüfen, ob der Code das macht, was er laut Beschreibung tun soll, sich an vereinbarte Standards hält und gut lesbar ist. Wir achten auf eine saubere Struktur, die Einhaltung der SOLID-Prinzipien, die sinnvolle Verwendung von Patterns, saubere Fehlerverarbeitung, und so weiter und so weiter.

Wir schauen also kritisch auf den Code und prüfen ihn eingehend auf Fehler und Sauberkeit.

 

Warum sollten wir Code Reviews durchführen?

Durch Code Reviews finden wir Fehler bereits im Code, die wir sonst ggf. erst sehr spät in der Testphase entdecken. Ein 4-Augen-Pronzip ist eine günstige Art der Prüfung. Dadurch erhöhen wir die Qualität der Software.

Ein Code Review sollte immer möglichst im Dialog erfolgen. Dieser muss nicht zwingend direkt geführt werden, sondern kann auch asynchron erfolgen, etwa via E-Mail oder ein geeignetes Code Review-Werkzeug. Dadurch tauschen wir Wissen zwischen den beteiligten Entwicklern aus. Der Autor bekommt aktives Feedback zu seinem Code. Fehler werden entdeckt, auf mögliche Testautomatisierung hingewiesen, schlecht lesbarer (und damit schlecht wartbarer) Code wird aufgedeckt. Der Reviewer liest Code, sieht guten Code und elegante Lösungen. Aber auch Fehler, die er selbst vielleicht auch gemacht hätte. Beide lernen dabei was für sich.

Unterm Strich haben wir also mit recht geringem Kostenaufwand einen hohen Nutzen erzielt. Zusätzlich erhöhen wir die Qualität der Software und die Wartbarkeit des Codes…und wir verringern den Truck Factor als Risiko für das Projekt. Alles in allem erhöhen wir damit also die Kundenzufriedenheit durch saubere Software.

 

Was brauchen wir für Code Reviews?

Was generell für Teams gilt, damit diese gut und effizient zusammenarbeiten können, gilt für gemeinsam durchgeführte Code Reviews insbesondere. So sind Einigungen über Namenskonventionen, Code-Formatierung, Einsatz erlaubter Frameworks usw. im Vorfeld zu klären, damit nicht jeder „seinen“ Code-Stil  durchsetzen will. Im Team kommt es darauf an, einheitlich zu arbeiten. Persönliche Vorlieben müssen dabei hinten anstehen.

Damit ein Code Review zu einem guten Ergebnis für alle Beteiligten wird, sollte der Autor kritikfähig sein. Es geht darum, den Code zu bewerten, nicht den Autor zu diskreditieren. Wir wollen gemeinsam besseren Code und bessere Softwarequalität erreichen. Rechtfertigungen und unausgesprochene Kritik sind dabei fehl am Platz. Aber auch der Reviewer sollte sich an gewisse Feedback-Regeln halten.

Hilfreich ist es – vor allem, wenn man gerade im Team mit Code Reviews beginnt – sich Ziele für das Code Review zu setzen. „Diese Woche schauen wir insbesondere auf saubere Benennung von Packages, Klassen und Variablen.“ oder „In diesem Sprint ist uns wichtig, dass es zu möglichst jeder Klasse ausreichend automatisierte Tests gibt.“

Dass jeder Entwickler vor dem Einchecken ins Versionskontrollsystem den eigenen Code noch einmal überprüft, versteht sich natürlich von selbst.

 

Wie führen wir Code Reviews durch?

Zeitnah nach dem Einchecken des Codes schaut sich der Reviewer den Code an. Es sollten keine Review-Marathons durchgeführt werden. Dann fehlt die Konzentration und vor allem, wenn man alle Reviews am Ende macht, die Zeit, die Änderungen auch noch sauber einzubauen.

Zunächst schauen wir uns als Reviewer an, worum es bei dem commiteten Code überhaupt geht. Wie ist die User-Story? Wie lauten die Akzeptanzkriterien? Welche Rahmenbedingungen gilt es zu beachten?

Anschließend verschaffen wir uns einen Überblick über die Änderung. Welche Teile des Systems sind betroffen? Welche Codestellen wurden geändert? Welche verschoben? Welche entfernt?

Dann schauen wir uns den Code an. Dabei achten wir ggf. besonders auf das Ziel, welches wir uns im Vorfeld gesetzt haben. Wir prüfen den Code, ob er der Aufgabenstellung entspricht, suchen nach Fehlern und unsauberen Codestellen.

Finden wir was Auffälliges, kommentieren wir dies entsprechend. Hierbei bietet sich natürlich ein entsprechendes Code Review Werkzeug an. Aber auch direktes persönliches Feedback ist angebracht. Wichtig ist, dass wir uns ausreichend Zeit nehmen und für Ruhe sorgen. Es geht nicht darum, die Änderung abzunicken, sondern zu prüfen. Auch positive Anmerkungen sind erlaubt!

Wenn wir als Autor nun Feedback zu unserem Code erhalten, sollten wir nicht gleich in den Rechtfertigungsmodus schalten. Besser schauen wir uns den Kommentar einmal in Ruhe an, versuchen ihn zu verstehen und dann konstruktiv anzunehmen. Sind wir weiterhin der Ansicht, dass unser Lösungsvorschlag der bessere ist, bietet es sich an, dies mit dem Reviewer zu besprechen und gemeinsam zu einer einvernehmlichen Lösung zu kommen. Dabei gilt es für beide, kompromissbereit zu sein.

 

Tipps für ein besseres Code Review

Hier noch ein paar Tipps, die unser Kollege Mario dankenswerterweise zusammengestellt hat.

Für den Autor

  • Kritik/Fehler = Lernen. Nicht persönlich nehmen!
  • Job erfordert laufende Fortbildung
  • Es gibt immer jemanden der mehr weiß
  • Review ersetzt keine Gespräche/Zwischenfragen/Diskussionen
  • Reviewer an Review erinnern, wenn wichtig für eigenen Zeitplan
  • Reviewer hat nicht immer Recht

 

Für den Reviewer

  • Für Ruhe sorgen (kein klingelndes Telefon)
  • Nicht kurz schauen und OK sagen
  • Code Reviews nicht vor sich herschieben
  • „Das ist falsch!“, aber wie geht es besser?
  • Wortwahl: Fragend statt tadelnd, nicht persönlich werden
  • Nicht den Code selbst fixen (Bad fixes)
  • Guten Code/Persönliche Weiterentwicklung loben

 

Unsere Erfahrung mit Code Reviews

Wir beide arbeiten in aller Regel im Pair Programming, die extremste Form des Code Reviews. Wenn wir aber einmal getrennt an Code arbeiten, stellen wir uns diesen gegenseitig vor, besprechen die Idee hinter der Lösung, den Lösungsweg, die Architektur usw.

Dabei gibt der andere jeweils seine Einschätzung ab, was man am Code noch verbessern kann. Diese bauen wir bei Kleinigkeiten (Refactorings) dann direkt ein oder merken wir uns für später vor, wenn es um größere Änderungen geht.

Der wichtigste Punkt für uns ist dabei immer, das gegenseitige Lernen. Wir lernen unsere gesamte Codebasis kennen, auch, wenn wir sie nicht immer selbst geschrieben haben.

Formellere Reviews, die wir in dem Unternehmen, in dem wir arbeiten durchführen, zielen vielmehr auf die Punkte der Codequalität ab. Aber auch hier wollen wir immer möglichst viel lernen oder unser Wissen und unsere Erfahrung mit den Kollegen teilen.

 

Zum Abschluss noch die Einheit, in der Code-Qualität gemessen wird: WTF/Minute. Je kleiner der Wert, desto besser 😉

 

Wir wünschen euch viel Spaß beim Ausprobieren.

Eure Spaß-Coder

 

Dieser Artikel basiert neben unseren Erfahrungen auf folgenden Quellen:

http://de.wikipedia.org/wiki/Review_(Softwaretest)

http://davidwalsh.name/code-review

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert