© Ozz Design/Shutterstock.com
Nichtfunktionale Anforderungen: Struktur, Organisation und Wartung

Qualität ist besser!


Um der Definition von Codequalität gerecht zu werden, genügt es nicht, sich einzig auf den Quelltext zu konzentrieren. Auch Struktur, Organisation und Wartung spielen eine wichtige Rolle.

Aus Erfahrung wissen die meisten von uns, wie schwierig es ist, auszudrücken, was wir unter Qualität verstehen. Warum ist das so? Es gibt viele verschiedene Ansichten zum Thema Qualität, und jede von ihnen hat ihre Bedeutung. Im Kontext eines Projekts muss die Definition von Qualität mit den Bedürfnissen und dem Budget des Projekts übereinstimmen. Der Versuch, Perfektionismus zu erreichen, kann kontraproduktiv sein, wenn ein Projekt erfolgreich beendet werden soll. Wir werden unsere Überlegungen auf der Grundlage eines 1976 von Barry W. Boehm verfassten Aufsatzes [1] beginnen. Boehm beleuchtet die verschiedenen Aspekte der Softwarequalität und den zugehörigen Kontext. Schauen wir uns das etwas genauer an.

Wenn wir über Qualität sprechen, sollten wir uns auf drei Bereiche konzentrieren: Codestruktur, Korrektheit der Implementierung und Wartbarkeit. Viele Manager kümmern sich nur um die ersten beiden Aspekte, der Bereich Wartung wird von ihnen meist vollständig vernachlässigt. Das ist gefährlich, da das Risiko einer Investition für Unternehmen in die individuelle Entwicklung einer Anwendung nicht eingegangen wird, um diese nur für kurze Zeit in Produktion zu nutzen. Abhängig von der Komplexität der Anwendung kann der Preis für die Erstellung leicht mehrere Hunderttausend Euros erreichen. Da ist es mehr als verständlich, dass der erwartete Geschäftsnutzen solcher Aktivitäten als hoch eingeschätzt wird. Eine Lebensdauer von zehn Jahren und mehr in der Produktion ist üblich. Um die Vorteile auch künftig zu sichern, sind Anpassungen obligatorisch. Das impliziert einen starken Fokus auf die Wartung. Sauberer Code bedeutet nicht, dass sich Ihre Anwendung einfach ändern kann. Ein sehr leicht verständlicher Artikel [2], der dieses Thema berührt, wurde von Dan Abramov geschrieben. Bevor wir weiter darauf eingehen, wie Wartung definiert werden kann, werden wir den ersten Punkt diskutieren: die Struktur.

Einrüstarbeiten

Ein häufig unterschätzter Aspekt in Entwicklungsabteilungen ist ein fehlender Standard für Projektstrukturen. Eine klare Definition, wo Dateien abgelegt werden müssen, hilft Teammitgliedern, sogenannte Points of Interest (POI) schnell zu identifizieren. Eine solche Metastruktur für Java-Projekte wird beispielsweise vom Build-Werkzeug Maven definiert. Vor mehr als einem Jahrzehnt haben Unternehmen den Einsatz von Maven in ihren Projekten ausprobiert und das Tool an die vorhandene Verzeichnisstruktur angepasst. Das führte zu umfangreichen Wartungsarbeiten, da im Laufe der Zeit immer mehr Infrastrukturtools für die Softwareentwicklung hinzugekommen sind, wie beispielsweise SonarQube zur Codeanalyse. Solche Tools arbeiten nach dem von Maven definierten Standard. Das bedeutet, dass jede Anpassung des Standards an eigene Strukturen den Erfolg der Integration neuer Tools oder des Austauschs eines vorhandenen Tools gegen ein anderes beeinflusst.

Ein weiterer zu betrachtender Aspekt ist die unternehmensweit definierte Metaarchitektur. Wenn möglich, sollte jedes Projekt der gleichen Metaarchitektur folgen. Das reduziert die Zeit, die ein neuer Entwickler benötigt, um einem bestehenden Team beizutreten und produktiv zu werden. Eine solche Metaarchitektur muss für Adaptionen offen sein, was in zwei einfachen Schritten erreicht werden kann:

  • Kümmern Sie sich nicht um zu viele Details.

  • Folgen Sie dem KISS-Prinzip (Keep it simple, stupid!).

Ein klassisches Muster, das gegen das KISS-Prinzip verstößt, besteht darin, dass Standards stark angepasst werden. Ein sehr gutes Beispiel für die fatalen Auswirkungen einer starken Anpassung beschreibt George Schlossnagle [3]. In Kapitel 21 seines Buchs erklärt er die Probleme, die für ein Team entstanden, als der ursprüngliche PHP-Kern angepasst wurde, anstatt dem empfohlenen Weg zu folgen und Erweiterungen zu nutzen. Das führte dazu, dass jedes Update der PHP-Version manuell bearbeitet werden musste, um die eigenen Entwicklungen in den neuen Kern aufzunehmen. In diesem Zusammenhang bilden die besprochenen Maßnahmen hinsichtlich Struktur, Architektur und KISS bereits drei Qualitätsziele, die einfach umzusetzen sind.

Das auf GitHub gepostete Open...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang