Qualität – Codequalität, Debuggingfähigkeit und Infrastruktur

Parameter wie die Codequalität, Debuggingfähigkeit oder die Build-Infrastruktur entscheiden bei großen Projekten letztendlich, wie einfach es ist, die Software zu warten und zu erweitern. Aber auch die Analytics spielt eine wichtige Rolle.

Wartbare Software

In seinem Artikel “Hackable Projects – Pillar 1: Code Health“ (siehe unten) beschreibt der Autor, wie man Software so programmiert, daß sich der Code später leicht ändern läßt. Diese Eigenschaft ist wichtig, um in späteren Projektphasen problemlos neue oder geänderte Anforderungen implementieren zu können, ohne, daß unvorhergesehene Fehler entstehen.

Ein leicht wartbarer Code erfordert Überlegungen in mehreren Bereichen:

  • Sauberer Quellcode
  • Debugbarkeit
  • (Build-) Infrastruktur

Unter dem Oberpunkt „Quellcode“, bespricht der Autor des zitierten Artikels unterschiedliche Testmethoden, wie Unit Tests, Integration Tests oder End 2 End Tests. Er hebt die Bedeutung von Code Reviews hervor, und geht auf die Rolle ein, die das einheitliche Codeformat spielt. Schliesslich beleuchtet er die Freigabeprozesse (Submit).

Die Erstellung von wartbarem Code erfordert weiterhin die folgenden Maßnahmen:

  • Statt eine monolitische Anwendung zu entwickeln, werden einzelne funktionale Bereiche wie die Zweige eines Baumes voneinander separiert.
  • Man achtet darauf, daß die einzelnen logischen Bereiche der Software nur lose gekoppelt sind.
  • Technische Schulden („technical debt“), die sich in früheren Entwicklungsphasen in den Code eingeschlichen haben, sollten stetig und aktiv abgebaut werden.

Empfehlung

Meiner Erfahrung nach trifft der Autor den Nagel auf den Kopf. Speziell die Punkte „wartbarer Code“ und „Unit Testing“ sind in der Praxis nicht zu unterschätzen.  Gerade auch Produktowner sollten darauf achten, daß sich das Entwicklungsteam ausreichend Zeit nimmt, um an diesen Punkten zu arbeiten (auch wenn es dafür ein Feature wegläßt).

Ist der Code nämlich erst kompliziert, und nicht testbar, aber ausgeliefert, schwinden die Freiheitsgrade schnell dahin, und die Entwicklung neuer Features ist nur sehr begrenzt möglich. Am Ende macht das Entwicklungsteam Bugfixing, und kommt oft gar nicht mehr zu neuen Entwicklungsvorhaben.

Da speziell in umfangreicher Software weder jede Codezeile noch die implementierten Anforderungen gleich wichtig sind, rate ich jedoch dazu, etwas spezifischer und analytischer vorzugehen, um herauszufinden, auf welche Bereiche der Software hierbei ein besonderes Augenmerk gelegt wird.

Hierfür gibt es mehrere Verfahren:

  • Analyse der Code Coverage – hiermit stellt man fest, welche Teile des Codes wie intensiv getestet werden.
  • Abhängigkeitsstatistiken und –grafen, um zu sehen, welche funktionalen Bereiche wie zusammenhängen
  • Verwendung geeigneter Software Metriken, wie Lines-of-Code (LoC), Code Duplicates, Nesting Level (NL) oder Cyclomatic Complexity (McCabe), um den Code selbst zu vermessen, und einen Eindruck der Größe der Codebasis zu bekommen.

Weiterführende Artikel im zitierten Testingblog von Google (von dort stammen die Artikel) befassen sich mit den Bereichen Debuggingfähigkeit und Infrastruktur (siehe dort).

Zu der erwähnten, eher analytischen Vorgehensweise kann ich den Online Kurs „Automatted Visual Sofware Analytics“ empfehlen, den das Hasso Plattner Institut (HPI) durchgeführt hat.

Weiterführende Informationen

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph).

Das heutige Artikelfoto stammt von der Messe München.

Neu erscheinende Artikel gibt es über die (→Mailingliste), oder, indem Sie →mir auf Twitter folgen.In der Online Version finden Sie hier die versprochenen weiterführenden Links:

I

This entry was posted on Montag, Januar 16th, 2017 at 7:37 pm. It is filed under Agile&Scrum, Thema des Tages and tagged with , , , , . You can follow any responses to this entry through the RSS 2.0 feed.

Andreas Rudolph - Fotoshop Andreas Rudolph - AS-Photo-Project.de

Comments are closed.