Einführung in Wartbarkeit

Artikel vom 7. September 2009 (↻ 5. April 2018). ISSN 1614-3124, #42. Schwerpunkt: Webentwicklung (RSS-Feed für alle Themen).

Dieser und viele andere Beiträge sind auch als hübsches, wohlerzogenes E-Book erhältlich: On Web Development.

Diese Dokumentation zu Wartung und Wartbarkeit bedeutet einen Anfang, der im Gleichschritt mit der englischen Erstfassung weiter ergänzt wird [und 2018 von einer umfassenderen Sammlung abgelöst wurde].

Einleitung

Wartbarkeit ist wichtig, um mit Veränderungen umzugehen. Gute Wartbarkeit bedeutet, mit Änderungen einfacher und günstiger umgehen zu können, sowie Änderungen zu vermeiden, die nicht notwendig sind. Dieser Artikel behandelt Wartbarkeit mit einem besonderen Fokus auf Webentwicklung.

Definition

Wartbarkeit wird üblicherweise als die Leichtigkeit bezeichnet, mit der ein System – zum Beispiel eine Website oder Webapplikation – verändert oder erweitert werden kann, so 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 Softwareprodukt 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

Sowohl traditionelle Software- als auch Webentwicklung drehen sich um Wahrscheinlichkeiten. Wartbarkeit zu verbessern, schließt ein, die Wahrscheinlichkeit von Code-Ä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 Veränderungen, die vermeidbar sind.
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 erzielen, 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 auch erweiterbar. Das heißt, dass es leicht(er) ist, neue Funktionalität hinzufügen. 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

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

Unnachgiebigkeit, was für und wie viel Code tatsächlich verwendet wird, ist nicht nur der Effizienz und Performance bekömmlich, 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):

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

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 ein Auge nach alternativen Lösungen Ausschau hält, kann zu schlankerem, schnellerem und wartbarerem Code beitragen.

»Don’t Repeat Yourself«

Weitere Details in diesem Artikel schuldigbleibend: Wiederholen Sie sich nicht.

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 Dokumentstruktur mit Präsentation.

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, andernfalls:
Verwenden Sie 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

Generell muss man zumindest ein Stylesheet oder Skript aus dem HTML von Dokumenten verlinken, um »Separation of Concerns« zu erreichen. Jedes weitere Stylesheet oder Skript – was beliebt zu sein scheint, wie Stichproben andeuten – erhöht wiederum die Wahrscheinlichkeit von HTML-Änderungen. Diese Wahrscheinlichkeit muss 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 unnötigen Ä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 werden 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 von 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 Präfixes

Wenn Sie mit mehr als 200 verschiedenen ID- oder Klassennamen hantieren, sollten diese durch Präfixes geschützt werden, sogenannte »Pseudo-Namensräume«. Präfixes 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 darstellen würde, 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, so sie dem Verständnis dienen. Kommentare sind insbesondere hilfreich bei weniger populären Lösungen, 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.

Nachtrag (5. April 2018)

Beachten Sie auch die aktualisierte und erweiterte Fassung dieser Einführung.

Über mich

Jens Oliver Meiert, am 30. September 2021.

Ich bin Jens (lang: Jens Oliver Meiert), und ich bin ein Frontend-Engineering-Leiter und technischer Autor/Verleger. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin Mitwirkender an verschiedenen Webstandards und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Ich experimentiere gerne, nicht nur in der Webentwicklung (und im Engineering Management), sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Ansichten und Erfahrungen. (Sei kritisch, interpretiere wohlwollend und gib Feedback.)