Code Reviews – Es wird weiter entwickelt

Heute hatten wir ein wirklich langes Team-Meeting. Sieben Stunden waren veranschlagt und wir haben sie auch wirklich gebraucht. Klingt lange. War es auch. Aber manchmal braucht es eine “Auszeit” um “zueinander” zu finden. Ein zentraler Bestandteil waren die Code Reviews. Neben – mittlerweile – zahlreichen Beiträgen zu diesem Thema hatte ich eine Umfrage gestartet und auch die vorläufigen Ergebnisse veröffentlicht. Mittlerweile kamen zwar zahlreiche Stimmen hinzu, an der Aufteilung hat sich jedoch nichts verändert. Aber wie geht es weiter …

Innerhalb des Teams mehrten sich die Stimmen, dass die aktuelle Form der Code Reviews nicht zielführend sei. Es wurde kritisiert, dass Verantwortlichkeiten fehlen. Was ist damit gemeint?

Es sollten Bereiche und dafür Verantwortliche (zwei) definiert werden. Diese sollten Check-Ins für ihren jeweiligen Bereich reviewen und so eine bestimmte Qualität garantieren. Entsprechend der Umfrage wird das von einigen so gehandhabt. Ich war hier jedoch skeptisch und habe dieses Thema angesprochen.

Schlussendlich konnte hier festgestellt werden, dass es hier grundsätzlich am Entwicklungsprozess mangelt. Hierzu vielleicht eine Erklärung wie ich selbst Code Reviews empfinde:

Ein Code Review dient der Prüfung hinsichtlich Stabilität des Codes, dessen Verbesserung hinsichtlich der Lesbarkeit, Eleganz und der Angleichung aller Team-Mitglieder an Coding Standards als auch Techniken.

In einem Code Review sehe ich nicht das Verteilen von Know How. Dies muss aus meiner Sicht in einem separaten Kommunikationsprozess stattfinden. Wenn aber nun die Forderung nach Verantwortlichen besteht, was sagt uns das? Es soll eine Prüfung hinsichtlich Funktionalität und “Integration” geben. Nun gut, man kann Bereiche definieren, auch Zuständigkeiten. Schlussendlich erreicht man jedoch eine Bürokratisierung des Code Reviews. Die Motivation daran teilzunehmen sinkt. Ein nicht erstrebenswerter Zustand.

Wie also in den Griff bekommen?

Der Entwicklungsprozess legt uns dabei alle Möglichkeiten in die Hände, sie müssen nur genutzt werden. Ein Anpassung und Erweiterung desselben fand schlussendlich auch den (vorerst) gültigen Konsens. Hier in aller Kürze:

  1. Entwicklung; Laufende Prüfung gegen die Spezifikation. Lücken müssen besprochen bzw. erfasst werden.
  2. Schreiben von Unit Tests bei Änderung bzw. bei Neuimplementierung. Auf Mocking von Services wird verzichtet. Behandelt werden atomare Bestandteile.
  3. Integrationstests testen das Zusammenspiel unterschiedlicher Komponenten und zeigen weitreichendere Probleme auf.
  4. Sämtliche Implementierungen werden gegen das Daily-System getestet. Erst wenn dort alle Anforderungen abgedeckt sind und das System funktioniert, kann der Punkt abgeschlossen und für ein Review freigegeben werden.
  5. Code Reviews für abgeschlossene Punkte. Diese dienen der Verbesserung des Codes/der Technik.
  6. Business-Abnahme durch QA-Phase

Teile dieses Prozesses sind vorhanden, andere wurden eine Zeit lang gepflegt und sind dann wieder in “Vergessenheit” geraten. Der Schlüssel liegt jedoch in der gesamtheitlichen Betrachtung. Dieser Prozess bietet den Vorteil, dass an den jeweiligen (korrekten) Stellen auf die Gegebenheiten reagiert wird und wiederverwendbare und nachvollziehbare Prüfstellen aufgebaut/gefestigt werden. Bei einer Zuteilung von Verantwortlichkeiten kann dies nicht erreicht werden. Dagegen spricht eine Fluktuation innerhalb des Teams, Schwankendes Know How etc.

Fazit

Vermutlich wird auch dies nicht der Weisheit letzter Schluss sein. Es stellt jedoch eine wesentliche Verbesserung dar und findet den Konsens aller Team-Mitglieder. Eine solide Basis auf der (hoffentlich) weiter aufgebaut werden kann. Ich werde dich über unsere weitere Entwicklung und den notwendigen Änderungen/Anpassungen auf dem Laufenden halten. Gerne lese ich auch dein Feedback um eine zusätzliche Bereicherung zu erfahren. Natürlich stehe ich auch für Diskussionen rund um dieses Thema zur Verfügung. Entweder hier über die Kommentare, oder aber via Twitter.

Veröffentlicht von Norbert Eder

Ich bin ein leidenschaftlicher Softwareentwickler. Mein Wissen und meine Gedanken teile ich nicht nur hier im Blog, sondern auch in Fachartikeln und Büchern.

Schreibe einen Kommentar

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

Cookie-Einstellungen
Auf dieser Website werden Cookie verwendet. Diese werden für den Betrieb der Website benötigt oder helfen uns dabei, die Website zu verbessern.
Alle Cookies zulassen
Auswahl speichern
Individuelle Einstellungen
Individuelle Einstellungen
Dies ist eine Übersicht aller Cookies, die auf der Website verwendet werden. Sie haben die Möglichkeit, individuelle Cookie-Einstellungen vorzunehmen. Geben Sie einzelnen Cookies oder ganzen Gruppen Ihre Einwilligung. Essentielle Cookies lassen sich nicht deaktivieren.
Speichern
Abbrechen
Essenziell (1)
Essenzielle Cookies werden für die grundlegende Funktionalität der Website benötigt.
Cookies anzeigen