26.01.2021 | Alex
Die Breite an Themen, die unter dem Aspekt ‘Software-Qualität’ zusammengefasst werden, ist überwältigend: Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Wartbarkeit, Portabilität - jede Kategorie mit ihren jeweiligen Unterkategorien. Und so vielfältig wie die Anforderungen sind, so zahlreich sind auch die Massnahmen, um diesen gerecht zu werden. An dieser Stelle möchte ich auf eine Methode eingehen, die gleich auf mehrere Qualitätsanforderungen einzahlt und zusätzlich Reibungsverluste im Fokus hat: Peer Reviews.
Ein zentraler Aspekt von Peer Reviews ist sicherlich die Erhöhung der Softwarequalität: Durch das “2n-Augen-Prinzip” (mit n>1) können Bugs frühzeitig erkannt und behoben werden. Nicht zu unterschätzen sind aber auch diejenigen Aspekte, die nicht direkt auf ein ‘hartes’ Qualitätsziel einzahlen:
Wissensaustausch: Aus meiner Sicht DAS Kriterium, weshalb Peer Reviews unabdingbar sind. Peer Reviews fördern den Wissensaustausch im Team in fachlicher sowie technischer Hinsicht und steigern damit die Maturität des Teams. Dies ist nicht nur hilfreich im Krankheitsfall, sondern erhöht auch die Planungsflexibilität: Weil Wissens-Silos vermieden werden können bestimmte Stories nicht ausschliesslich von einer spezifischen Person erledigt werden. Gleichzeitig verbessert sich damit die Güte von Schätzungen: Je breiter das Wissen, desto genauer die Schätzung.
Konsistenz, Uniformität: Durch Peer Reviews nähert sich das Team einem gemeinsamen Code-Stil an, der Code wirkt wie ‘aus einem Guss’. Dies erleichtert neuen Projektmitgliedern den Einstieg und verbessert die Wartbarkeit.
Einfachheit: Hat man sich während dem Entwicklungsprozess tief in die Fachlichkeit eingearbeitet, erscheint vieles klar. Versteht der Reviewer die Programmlogik aber nur mit Erklärungen, so läuft man Gefahr, dass selbst der Urheber nach geraumer Zeit erheblichen Aufwand betreiben muss, um die Logik wieder zu verstehen.
Identifikation: Jeder, der am Review beteiligt ist, trägt zur Qualität des Inhalts bei und identifiziert sich somit auch stärker mit dem Resultat.
Wissensaufbau: Expertise ist in keinem Team gleichmässig verteilt. So kann im Rahmen eines Reviews jeder von den Stärken des jeweils anderen profitieren und sein eigenes technisches Wissen erweitern.
Will man aber Peer Reviews neu etablieren, so schlägt einem nicht selten eine steife Brise entgegen. Auf einige Einwände soll hier (nicht abschliessend) eingegangen werden:
Wer soll denn das alles reviewen?
Das ist einfach: Jeder, der etwas dazu beitragen kann. Handelt es sich primär um Programmcode, so ist ein Entwickler sicherlich die richtige Ansprechperson. Beinhaltet der Code komplexe Fachlogik, so ist es nie falsch, einen entsprechenden Experten hinzuzuziehen. Ist jemand neu im Team, lohnt sich möglicherweise auch eine Zweitmeinung. Mit etwas Augenmass kommt man hier sehr weit.
Aber damit verlieren wir doch nur Zeit!
Das Gegenteil ist der Fall. Sicherlich braucht ein gutes Review im ersten Moment etwas Zeit. Diese Investition wird sich aber schon bald auszahlen durch einfacheren Code, bessere Wissensverteilung und ein stärkeres Teamgefüge.
Wir haben doch schon statische Code-Analyse
Semantische Fehler in der Business-Logik werden damit leider nicht abgedeckt, auch findet kein Wissensaustausch statt. Und nicht zuletzt hindert mich niemand daran, ohne triftigen Grund //nosonar einzuchecken 😉.
Aus all diesen und noch viel mehr Gründen ist für mich eindeutig klar: Qualität ist nicht verhandelbar, und: Reviews sind unabdingbar.
Du findest, das töne alles gut, bist aber noch auf der Suche nach dem Team, um qualitativ hochstehende Software zu erzeugen? Dann solltest du dich unbedingt mit dem avega Enabling Team über deine Projektidee unterhalten!