Einführung in Wartbarkeit

Jens Meiert, 7. September 2009. ISSN 1614-3124, Ausgabe 42.

Diese Dokumentation zu Wartung und Wartbarkeit bedeutet einen zarten Anfang, der im Gleichschritt mit der englischen Erstfassung noch erweitert wird.

Inhalt

Einleitung
1. Definition
2. Annahmen
Attribute guter Wartbarkeit
Techniken und Empfehlungen

Einleitung

Wartbarkeit ist wichtig, um mit Veränderungen umzugehen. Gute Wartbarkeit bedeutet, dass Veränderungen einfach vorgenommen werden können, aber auch Veränderungen vermieden werden, die nicht notwendig sind; gute Wartbarkeit bedeutet ebenso, dass Anpassungen günstiger werden.

Definition

Wartbarkeit wird üblicherweise als die Leichtigkeit bezeichnet, mit der ein System – zum Beispiel eine Website oder Webapplikation – verändert oder erweitert werden kann (via Jeremy D. Miller).

Andere Definitionen halten fest: »Wartbarkeit wird als die Wahrscheinlichkeit definiert, mit der eine Reparaturaktion innerhalb einer bestimmten Zeit erfolgreich abgeschlossen wird. In anderen Worten, Wartbarkeit misst die Leichtigkeit und Geschwindigkeit, mit der ein System wiederhergestellt werden kann, nachdem ein Fehler aufgetreten ist.« Die englische Wikipedia bezieht Wartbarkeit auf die Leichtigkeit, in der ein Software-Produkt angepasst werden kann, um »Fehler zu berichtigen, neue Anforderungen zu erfüllen, zukünftige Wartung zu erleichtern oder sich auf eine veränderte Umgebung einzustellen«.

Annahmen

Zum leichteren Verständnis von Wartbarkeit sollten einige Annahmen getroffen werden:

Sowohl traditionelle Software- als auch Webentwicklung drehen sich um Wahrscheinlichkeiten; Wartbarkeit zu verbessern, schließt ein, die Wahrscheinlichkeit von Änderungen zu minimieren.
Veränderungen bedeuten Kosten, und diese Kosten stellen die Motivation dar, Wartbarkeit zu verbessern.
Veränderungen sind unvermeidbar, und dennoch gibt es vermeidbare Veränderungen.
Im Bereich der Webentwicklung sind HTML-Änderungen am teuersten (da es in nahezu allen Fällen mehr HTML-Dokumente und -Vorlagen gibt als Stylesheets und Skripte).

Attribute guter Wartbarkeit

Verständlichkeit

Ein wartbares System ist verständlich. Das heißt, dass Code strukturiert geschrieben ist, Konventionen folgt (zum Beispiel Code- und Formatierungsrichtlinien) und entweder »selbsterklärend« ist oder so kommentiert wurde, dass jeder, der an der Entwicklung beteiligt ist, versteht, was der Code genau macht.

»Separation of Concerns« und Orthogonalität

Um leichtere Wartbarkeit zu erreichen, sollten einzelne Belange getrennt werden (»Separation of Concerns«), was bedeutet, ein System in eigenständige Funktionen zu zerlegen, die hinsichtlich ihrer Funktionalität so wenig wie möglich überlappen.

Programmiersprachen erlauben die Trennung von Belangen mittels Objekten; Design-Patterns wie MVC (»Model View Controller«) ermöglichen diese Trennung via Unterscheidung in Datenverarbeitung, Darstellung und Inhalte; Standards wie HTML, CSS und JavaScript sehen die Trennung von Struktur, Präsentation und Inhalten vor.

Die Trennung von Belangen gestattet, eine Sache zur Zeit zu verändern. Das Ziel ist Orthogonalität: »Die grundlegende Idee hinter Orthogonalität ist es, dass Dinge, die konzeptionell nichts miteinander zu tun haben, in einem System ebenfalls nichts miteinander zu tun haben sollten.«

Erweiterbarkeit

Ein wartbares System ist nicht nur verständlich und trennt einzelne Belange, es ist dazu auch erweiterbar. Das heißt, dass es leichter ist, neue Funktionalität hinzufügen. Sehr allgemein formuliert kann dies erreicht werden, indem der Fokus auf einfache Lösungen gelegt wird; dieser Artikel schuldet weitere Optionen im Hinblick auf Erweiterbarkeit.

Techniken und Empfehlungen

Diese Liste befindet sich im Aufbau.

»Keep Things Simple«: Kümmern Sie sich nur um das, was absolut notwendig ist

Unnachgiebigkeit, was für und wieviel Code tatsächlich verwendet wird, ist nicht nur bekömmlich für Performance, sondern auch eine gesunde Mentalität, wenn es um die Verbesserung der Wartbarkeit geht.

So können Sie beispielsweise den HTML-Kontext nutzen, um Elemente zu stylen: Bei einem einmalig auftretenden Elternelement jedem Kindelement eine bestimmte Klasse zuzuweisen ist in der Regel allein schon ein Indikator, dass Dinge vereinfacht werden können. Sehen Sie dazu den folgenden HTML-Code:

<ul id="ergebnisse">
  <li class="ergebnis">
  <li class="ergebnis">
  <li class="ergebnis">
</ul>

Um alle li-Elemente auf dieselbe Weise darzustellen, brauchen Sie keine ergebnis-Klasse. Statt dessen kann der Kontext genutzt werden: #ergebnisse li.

Darüber hinaus bieten sowohl Software- als auch Webentwicklung gerne mehrere Wege an, ein bestimmtes Ziel zu erreichen. Die Dinge einfach zu halten, während zumindest ein Auge nach alternativen Lösungen Ausschau hält, kann enorm zu schlankerem, schnellerem und wartbarerem Code beitragen.

Verwenden Sie kein präsentationsbezogenes Markup

Vermeiden Sie präsentationsbezogene Elemente und Attribute

Präsentationsbezogene Elemente und Attribute, für die es genügend Daten gibt, um ihre Popularität zu belegen, erschweren die Wartung, da sie das Prinzip der Trennung einzelner Belange verletzen: Sie vermischen Präsentation mit Dokumentstruktur.

So können beispielsweise der Einsatz von font-Elementen oder Layout-Tabellen dazu führen, dass Sie vielleicht hunderte Dokumente oder Dutzende Vorlagen anpassen müssen für etwas, das andernfalls vielleicht nur eine einzelne Stylesheet-Änderung erfordern würde.

Behalten Sie im Hinterkopf, dass HTML-Änderungen teuer sind.

Vermeiden Sie präsentationsbezogene ID- und Klassennamen

Präsentationsbezogene ID- und Klassennamen spiegeln dasselbe Problem wider, sind jedoch etwas, das unter vollständiger Kontrolle des Autors und Entwicklers steht.

Empfehlungen für ID- und Klassennamen beinhalten:

Beschränken Sie den Einsatz von IDs und Klassen auf ein Minimum.
Verwenden Sie funktionsbezogene ID- und Klassennamen.
Verwenden Sie ansonsten neutrale ID- und Klassennamen.
Allgemein: Bevorzugen Sie Namen, die so kurz wie möglich, aber so lang wie nötig sind.

Verlinken Sie nur ein Stylesheet und Skript aus dem HTML

In den meisten Fällen müssen Sie ein Stylesheet oder Skript aus dem HTML Ihrer Dokumente verlinken, um »Separation of Concerns« zu erreichen. Jedes weitere Stylesheet oder Skript – was sehr beliebt ist, wie Stichproben andeuten – erhöht wiederum die Wahrscheinlichkeit von HTML-Änderungen. Diese Wahrscheinlichkeit muss zwar nicht exorbitant hoch sein, aber sie ist höher als notwendig, ergo vermeidbar.

Verwenden Sie funktionsbezogene oder generische Stylesheet- und Skriptnamen

Eine ungünstige Namensgebung für Stylesheets und Skripte, zumindest solche, die direkt aus HTML-Dokumenten verlinkt werden, erhöht ebenfalls die Gefahr von teuren HTML-Änderungen. Halten Sie sich an funktionale (beispielsweise produkt.css) oder generische Namen (standard.css), um diese Gefahr zu meiden und dadurch die Wartbarkeit etwas zu verbessern.

Namen wie style.css (jedes Stylesheet beinhaltet »Styles«, ebenso wie das nächste Stylesheet, das vielleicht gebraucht wird), screen.css (warum sollten x Dokumente aktualisiert werden, nur weil screen.css vielleicht auch irgendwann projection mitnehmen soll) oder standard-v3.css (wenn vielleicht standard-v2.css still und leise doch noch länger referenziert wird) sind Zeugen ungeschickter Namen, die teuer sein können.

Weisen Sie Medientypen nicht innerhalb des Markups zu

Medientypen sollten nicht innerhalb von HTML-Dokumenten und -Vorlagen angegeben werden, sondern statt dessen innerhalb Stylesheets.

Verwenden Sie anstatt

<link rel="stylesheet" href="standard.css" media="screen, print">

eher

<link rel="stylesheet" href="standard.css">

und setzen Sie auf @import- oder @media-Regeln, um Medientypen an einer zentralen Stelle zu verwalten:

@media screen {}
@media print {}

Der Grund dafür ist wieder einmal die Minimierung der Wahrscheinlichkeit von Änderungen. HTML-Dokumente anzupassen, nur um Medientypen zu ändern, ist ein Beispiel für Änderungen (und dadurch Kosten), die vermeidbar sind.

Komplexe Projekte: Verwenden Sie »Pseudo-Namensräume«

Wenn Sie mit mehr als 200 verschiedenen ID- oder Klassennamen hantieren, sollten diese durch Präfixes »protegiert« werden, also Pseudo-Namensräume. Pseudo-Namensräume verringern das Risiko von Namens- und dadurch Layout-Konflikten und können die Wartung erleichtern, indem sie die Verständlichkeit erhöhen.

Verwenden Sie zum Beispiel in einem großen Projekt eher »PROJEKT-KLASSENNAME« denn »KLASSENNAME«, wobei »PROJEKT« ein aus vielleicht zwei oder drei Buchstaben bestehendes Kürzel für Ihr Projekt, Feature oder Widget darstellt, gefolgt von einem funktionsbezogenen oder generischen Namen.

Halten Sie sich an Formatierungsregeln

Das Verständigen auf einen bestimmten Code-Stil und dessen Einhaltung kann Wartbarkeit zuträglich sein, da ein einheitlicher Stil die Verständlichkeit fördert, wenn es um die Arbeit von Teams an Systemen, Sites und Applikationen geht.

Machen Sie sinnvollen Gebrauch von Kommentaren

Kommentare können die Wartung erleichtern, da ebenfalls förderlich für die Verständlichkeit sein. Kommentare sind insbesondere hilfreich bei weniger populären Problemen, und somit kann ihr Gebrauch, wenn vernünftig, anderen Leuten – und vielleicht Ihnen selbst – helfen, zu verstehen, was der jeweilige Code löst, und warum er dies auf die gewählte Weise löst.

Jens Meiert