Effizient im Team mit Architektur- und Code-Reviews

Inhaltsverzeichnis

Besser informierte Teammitglieder und qualitativ hochwertigere Programme – beides lässt sich mit gut geplanten Code- und Architektur-Reviews erreichen. Das gemeinsame Durchgehen von Quelltexten und Strukturentscheidungen hilft nicht nur, den Wissensaustausch unter allen Beteiligten zu fördern, sondern bringt auch Fehler frühzeitig ans Licht.

Das magische Dreieck des Projektmanagements (siehe Abb. 1) basiert auf den drei Steuerungsgrößen Zeit, Kosten und Funktionsumfang (Scope). Jede Größe beeinflusst das jeweils andere Element. Eine Vergrößerung des Scopes führt beispielsweise automatisch zu einer Erhöhung der Kosten oder einer Verschiebung des Zieltermins. An beiden Größen festzuhalten geht stets zulasten der Qualität.

Abhängig vom konkreten Projekt stehen andere Elemente im Vordergrund. In Entwicklungsprojekten sind häufig Termin (Zeit) und Kosten feste Größen. Ist das der Fall, bleiben nur Abstriche am Funktionsumfang oder der Qualität. Bei langfristigen Projekten mit Lebenszyklen über Jahrzehnte hinweg liegt der Fokus oft anders. Hier stehen die Qualität und damit die Wartbarkeit im Vordergrund. Ein Erhöhen der Kosten oder ein Verschieben des Zieltermins ist in solchen Fällen häufig eher akzeptabel.

Aber ist das magische Dreieck tatsächlich ein unumstößliches Gesetz, oder wurde vielleicht noch ein Element vergessen? Die Teameffizienz fehlt. Durch eine Optimierung von Prozessen und durch Nutzung effizienter Werkzeuge kann sie verbessert werden. Damit steht eine weitere Stellgröße zur Verfügung, selbst wenn es sich nur um eine langfristig veränderbare handelt.

Die Teameffizienz wird von einer Vielzahl von Faktoren beeinflusst. Um möglichst kurzfristig Fortschritte zu erzielen, gilt es, die Methoden zu finden, bei denen man mit wenig Aufwand viel erreichen kann. Eine oft unterschätzte Methode in der Design- und Implementierungsphase stellen Architektur- und Code-Reviews dar. Hierbei prüfen Entwickler entweder gegenseitig Implementierungen und Entwürfe oder lassen es einen erfahrenen Kollegen tun. Zu den zu beachtenden Kriterien zählen unter anderem Verständlichkeit, Wartbarkeit, Funktionalität, Sicherheit und Performance. Durch die intensive Prüfung lässt sich eine Vielzahl Schwachstellen früh erkennen.

Nebenbei steigert die intensive Zusammenarbeit der Entwickler die Teamkommunikation, und sowohl das fachliche als auch das technische Wissen werden vertieft. Die Beteiligten lernen voneinander, was die Kompetenz des gesamten Teams und damit dessen Effizienz steigert. Außerdem lässt sich die Verantwortung so auf mehrere Schultern verteilen, und es gibt eine Vertretung, sollte ein Teammitglied einmal ausfallen. Trotz aller Vorteile kommt die Methode in der Praxis nur selten zur Anwendung. Unter anderem ist das auf folgende Ursachen zurückzuführen:

• Reviews werden in der Regel von erfahrenen Entwicklern durchgeführt. Diese sind allerdings oft durch andere Aufgaben aus- beziehungsweise überlastet und stehen damit nur eingeschränkt zur Verfügung.
• Eine Vielzahl kleiner Fehler (zum Beispiel Benennungsregeln) verhindern oft das Erkennen von Architektur- und fachlichen Fehlern. Damit entsteht durch die Reviews kein entscheidender Mehrwert.
• Bei Reviews immer wiederkehrende Fehler senken die Motivation der Prüfer, sich die Zeit für Reviews zu nehmen.
• In Reviews konzentriert man sich darauf, Fehler zu identifizieren. Das häufige negative Feedback wird nicht als konstruktive Kritik aufgenommen, sondern führt dazu, dass Entwickler ihre Software nur noch ungern einem Review unterziehen lassen.
• Der Zeitaufwand und die damit verbundenen Kosten sind hoch.

Durch das Schaffen der richtigen Voraussetzungen lässt sich dem jedoch entgegenwirken. Hierbei gilt es, die Effizienz der Reviews und deren Akzeptanz zu steigern.