Codequalität (II): Entwickler, denkt nicht nur an die Nutzer

Entwickler im QTK-Dreieck

Einsparungen bei der Codequalität erzeugen langfristig höhere Ausgaben für den Product Owner – so lautet das Fazit des ersten Teils dieser kleinen Artikelreihe. Doch nicht nur die Stakeholder müssen umdenken. Entwickler haben den größten Anteil am Erfolg beim Einsatz dieser Prinzipien. Wir sprachen mit einem unserer Senior Developer und stellen einige Empfehlungen vor.

Codequalität heißt lesbarer Code

Für einige Entwickler muss diese eine Denkschranke noch fallen, um die Vorteile von guter Codequalität wirklich umsetzen zu können: Quelltext wird nicht nur für den Nutzer geschrieben, sondern auch für andere Entwickler. Diese Aussage klingt nur solange seltsam, bis man weiß, dass  Quelltext viel häufiger gelesen, als geschrieben wird.
Natürlich bleibt die funktionierende Umsetzung der Anforderungen das Primärziel. Aber lesbarer Code folgt direkt dahinter. Es gibt viele Situationen, in denen andere Entwickler die eigene Arbeit nachvollziehen müssen: Zu Wartungszwecken, für Änderungen an der Software oder auch die Adaption bestimmter Quellcodeteile für andere Applikationen.

Das gesamte Entwicklerteam muss mitziehen

Um eine gute Codequalität zu erreichen, setzen sich die Entwickler sich schon vor dem Projektstart als Team Standards. Ronald Marske, einer der Senior Developer bei der secu-ring GmbH, betonte im Gespräch, dass alle Mitglieder hinter diesen Richtlinien stehen müssen. Bei konsequenter Umsetzung entstehe so eine Struktur, die alle Entwickler im Team (auch zukünftigen), leicht nachvollziehen könnten. Dabei sollten spezifische Richtlinien festgelegt werden, welche sich z.B. an den genutzten Programmiersprachen orientieren. Da bei secu-ring viele Webapplikationen bisher mit PHP realisiert wurden, wählten die Entwickler PHP PSR1 und passten diese Vorgaben an die eigenen Bedürfnisse an. Um alle Teammitglieder an die internen Richtlinien heranzuführen, werden regelmäßig Vorträge gehalten und die Inhalte zur Diskussion gestellt. So wird das Verständnis für Codequalität gefördert und der Aufwand für späteres Refactoring reduziert sich.

Die fünf Eigenschaften von Qualitätscode

Lesbarer Code beschränkt sich nicht nur auf eine übersichtliche Formatierung. Andere wichtige Punkte sind u.a. Namensgebung von Klassen bzw. Funktionen, nachvollziehbare Codeanweisungen und der sinnvolle Einsatz von Kommentaren.
Über die exakten Eigenschaften von gutem Quelltext existieren viele verschiedene Ansichten (z.B.: Link I | Link II). Interessant ist z.B. der Ansatz aus einem Beitrag auf Stackoverflow, welcher es auf fünf Eigenschaften bringt:

  1. Lesbar/Verständlich
  2. Testfähig
  3. Flexibel
  4. Konform
  5. Ökonomisch

Der erste Punkt besitzt die höchste Priorität und sollte nicht verhandelbar sein. In der Realität jedoch kann Code im ersten Durchlauf selten optimal geschrieben werden, weshalb sich dafür Refactoring im Nachgang empfiehlt. Für unseren Senior Developer Ronald Marske ist auch der zweite Punkt nur bedingt flexibel. Das Streben nach einer prinzipiellen Testfähigkeit beeinflusst die Qualität des Quelltextes nachhaltig im positiven Sinne. Sollte das initiale Budget für die Einrichtung von Tests nicht reichen, vereinfacht die solide Basis, diesen Part der Qualitätssicherung einzuführen. Ein guter Quellcode ermöglicht es also Entwicklern wie auch Projektleitern bzw. Product Ownern flexibel zu reagieren. Wie die Stakeholder mit Requirement Engineering die Konformität des Endproduktes mit den Anforderungen erreichen, darüber wird Berit Kitzing in diesem Blog bald berichten.
Der letzte Punkt, Ökonomischer Code, ist nicht mit übertriebener Mikrooptimierung auf maximaler Effizienz zu verwechseln. Diese Anpassung kann Quelltext schnell wieder unverständlich werden lassen. Hier ist es wichtig, die Vorteile mit dem jeweils verbundenen Mehraufwand abzuwägen

Der Kampf um die Mehrkosten

Viele Entwickler werden bei dem letzten Satz aufstöhnen. Vielleicht haben sie schon versucht den Product Owner/Projektleiter zu überzeugen, den Mehraufwand für qualitativen Code zu bewilligen. Stattdessen wurde ein Prototyp weiterentwickelt und das Testing als unnötig ganz gestrichen.
Das Problem: Beide Seiten argumentieren nur aus ihrer eigenen Perspektive.  Das Ziel einer Zusammenarbeit sollte aber in einem Kompromiss bestehen, der positive Eigenschaften beider Seiten vereint. So wie sich der Product Owner in die Welt der Entwickler eindenken sollte, gilt dies auch vice versa. Wenn nur ein beschränktes Budget zur Verfügung steht, liegt der Fokus ganz klar auf Bootstrapping und Codequalität. So erhält der Kunde ein MVP als qualitativ hochwertige Basis, die im Laufe der Zeit mit vertretbarem Aufwand gewartet und erweitert werden kann.
Für den Entwickler bedeutet Codequalität dagegen eine enorme Arbeitserleichterung, die sich in Zufriedenheit und Zeitersparnis niederschlägt. Beide Faktoren wirken auch auf den Auftraggeber zurück. Das Ergebnis ist eine Win-Win-Win-Situation, denn im Endeffekt profitieren auch Nutzer von besserem Code und einer anforderungsgetriebenen Entwicklung, die sich an realem Feedback orientiert.

Schreibe einen Kommentar

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