Many software companies, about to ship a new product or update, realize too late that they’re missing something vitally important – first class documentation.
(Aus der Werbung einer Dokumentationsfirma)
Die Dokumentation gilt als ewiges Sorgenkind der Software-Entwicklung. Sie müsste es nicht sein. In diesem Kapitel klären wir den Dokumentationsbegriff und diskutieren die Bestandteile und die Qualität einer Dokumentation.
Dokumentieren ist eine Daueraufgabe. Das noch immer verbreitete Vorgehen, erst nach Ende der Codierung zu dokumentieren, führt zu schlechter Software-Qualität, denn die Information, die es aufzuzeichnen gilt, ist vergessen oder – mit der Person, die diese Information im Kopf hatte – verschwunden. Bei einer nachträglichen Dokumentation bestehen also, in milderer Form, die gleichen Probleme wie beim Reengineering (siehe Kap. 23).
Dokumentation tritt demnach im Software-Lebenslauf nicht als eigene Tätigkeit auf, weil das Dokumentieren wie Denken und Diskutieren zu allen konstruktiven Tätigkeiten gehört. Jeder Schritt liefert ein Dokument oder modifiziert es (siehe Abschnitt 9.1.3). Damit lassen sich Software-Entwickeln und Dokumentieren nicht trennen, das Resultat der Entwicklung ist die Dokumentation. Wir verwenden in diesem Kapitel folgende Begriffe:
Integrierte Dokumentation ist gleichbedeutend mit den im Programm enthaltenen Kommentaren. Auch die Bezeichner der Variablen, die Verwendung von Leerzeilen usw. tragen zur integrierten Dokumentation bei. Die integrierte Dokumentation betrachten wir eingehend im Kapitel Codierung (siehe Abschnitt 18.3).
Separate Dokumentation ist der Teil der Software, der nicht in den Programmen enthalten ist.
Dokumentation steht für die Vereinigung von integrierter und separater Dokumentation.
Jeder Teil einer Dokumentation, der separat erstellt, verwaltet und benutzt werden kann, ist ein Dokument.
Die konkrete Form der Dokumente ist damit nicht festgelegt, einzig Stabilität ist unbedingt gefordert. Es gibt also keine »Dokumentation im Kopf«, sondern nur auf Papier, auf elektronischen Datenträgern usw. Der Programmcode ist ein spezielles Dokument. Wenn von Dokumenten die Rede ist, schließt das den Code ein.
Wo man die Wahl hat, ist die integrierte Dokumentation vorzuziehen, denn sie ist leichter zu bearbeiten und hat bessere Chancen, nachgeführt zu werden. Sie reicht aber in keinem Falle aus, denn gerade bei einem systematischen Vorgehen sind mindestens 40 % des Aufwands geleistet und damit logisch auch 40 % der Software entstanden, bevor Code geschrieben wird (siehe Abschnitt 4.2). Einige Dokumente müssen unbedingt vorher entstehen: Zuallererst ist hier das Begriffslexikon zu nennen, dann die Spezifikation. Diese Dokumente müssen irgendwo abgelegt sein, aber sicher nicht in Code-Komponenten.
Die separate Dokumentation ist grundsätzlich gefährdet, sie kann nur funktionieren, wenn
die Anforderungen an die Dokumente und die Verantwortlichkeiten für das Erstellen, Prüfen und Freigeben klar sind,
Dokumentation hoch bewertet und anerkannt wird (vgl. Abschnitt 6.4.2),
das Inhaltsverzeichnis (die Struktur) der Dokumente zu Beginn festgelegt ist,
Werkzeugunterstützung verfügbar ist,
jedes Dokument nach Fertigstellung und nach Änderungen geprüft wird und
alle Dokumente einer effektiven Konfigurationsverwaltung unterstellt werden.
Dokumentieren ist kein Selbstzweck; die erstellten Dokumente müssen einen Nutzen haben, der den Erstellungsaufwand übersteigt. Wir sehen die folgenden Ziele, die mit einer guten Dokumentation erreicht werden können:
Dokumente sind ein Mittel zum Know-how-Transfer innerhalb des Entwicklungsteams und natürlich auch zur Kommunikation zwischen Auftraggeber und Auftragnehmer.
In Dokumenten retten und bewahren wir das Wissen über Programme, auf das schon während der Entwicklung zurückgegriffen werden kann. Besonders wertvoll sind die Dokumente jedoch für die Personen, die die Software weiterentwickeln und warten müssen. Dazu müssen die Dokumente natürlich aktuell gehalten werden.
Dokumente erlauben es, systematische Prüfungen durchzuführen. Nur so können wir unsere Arbeitsergebnisse selbst prüfen oder von anderen prüfen lassen (z. B. durch Reviews).
Weil Dokumente »materielle« Arbeitsergebnisse sind, können wir sie heranziehen, um den Projektfortschritt festzustellen. Ob beispielsweise ein Programm fertig ist, kann nur beurteilen, wer die Möglichkeit hat, es auszuführen, und zudem weiß, was das Programm leisten sollte. Der Projektleiter muss sich auf die meist mündlichen und oft vagen Aussagen dieser Leute verlassen. Ob aber ein Testbericht zu dem Programm vorliegt, lässt sich sehr einfach feststellen und überprüfen, da kann es keine Missverständnisse geben.
Dokumente können herangezogen werden, wenn nachgewiesen werden muss, dass systematisch und sorgfältig entwickelt wurde. Dies kann beispielsweise der Fall sein, wenn Standards einzuhalten sind oder Haftungsansprüche geltend gemacht werden. In bestimmten Anwendungsbereichen (Banken, Versicherungen, Verwaltungen) gelten strenge Regeln für die Revisionsfestigkeit einer Dokumentation.
Ohne Dokumente werden diese Ziele und der damit verbundene Nutzen nicht erreicht; welche Kosten und Probleme entstehen, wenn die Dokumentation schlecht ist oder fehlt, haben wir schon in vielen Projekten miterlebt (siehe Abschnitt 12.7). Leider können wir den Nutzen der Dokumente aber nicht quantitativ beziffern. Wir haben damit das traditionelle Dilemma des Software Engineerings vor uns: Die Kosten sind klar sichtbar, und sie entstehen an wenigen definierten Punkten. Der Nutzen ist unbestimmt, er entsteht an vielen Punkten und ist darum kaum sichtbar. Schlechte Dokumentation hat also einen ähnlichen Effekt wie eine Industrieanlage, deren Emissionen die Umwelt belasten: Die Kosten einer Rauchgasreinigung sind wohldefiniert, sehr erheblich und von dem Unternehmen zu tragen; die Schäden, die eintreten, wenn der Rauch ungereinigt über das Land zieht, sind wahrscheinlich sehr viel höher, aber kaum nachweisbar, und sie werden über die Menschen, die Kranken- und Rentenkassen verteilt. Dies ist eines von vielen Beispielen, die zeigen, warum wir so dringend mehr und bessere Metriken brauchen.
Nachfolgend geben wir eine grobe Abschätzung für die Erstellungskosten von Dokumenten an. Dabei nehmen wir an, dass
1. die durchschnittliche Produktivität vier Seiten pro Tag beträgt,
2. ein Personentag 1 000 € kostet.
Ein 40 Seiten starkes Dokument kostet demnach etwa 10 000 €. Dabei ist die angenommene Produktivität sehr hoch; wird an einem Dokument mehrfach »poliert«, dann kommen zwei Seiten pro Tag der Wahrheit näher. Das ist viel Geld, und der Aufwand ist sicher nicht gerechtfertigt, wenn es für das Dokument keinen echten Bedarf gibt. Wird das Dokument aber für den Gebrauch oder die Wartung benötigt, dann steht den hohen Kosten ein hoher Nutzen gegenüber. Dazu gehört insbesondere, dass
Dokumentation hilft, Fehler zu vermeiden oder sie wenigstens rasch zu finden,
sich gut dokumentierte Software einfacher erweitern und wiederverwenden lässt.
Der Erstellungsaufwand für gute Dokumentation verursacht einen erheblichen Teil der Entwicklungskosten. Der Nutzen einer guten Dokumentation kommt aber erst im Betrieb und bei der Wartung der Software voll zum Tragen. Es ist darum verhängnisvoll, nur die reinen Entwicklungskosten zu betrachten. Insbesondere der Auftraggeber sollte daran interessiert sein, dass die Gesamtkosten – also Entwicklungs- und Wartungskosten – möglichst gering sind.
Alle Dokumente, die bei der Software-Entwicklung erstellt und genutzt werden, gehören in Anlehnung an Frühauf, Ludewig, Sandmayr (2002) zu einer der folgenden vier Kategorien:
Systemdokumentation
Hierzu zählen alle Dokumente, die für die Konstruktion, den Betrieb und die Wartung der Software benötigt werden. Beispiele sind die Anforderungsspezifikation, die Systemarchitektur, die Abnahmespezifikation oder die Spezifikation der Systemtestfälle. Die gesamte Benutzungsdokumentation, beispielsweise Handbuch oder Installationsanleitung, aber auch der Programmcode gehören zur Systemdokumentation.
Projektdokumentation
In diese Kategorie fallen alle Dokumente, die benötigt werden, um das Entwicklungsprojekt zu planen, zu leiten und abzuschließen. Beispiele sind der Projektauftrag, der Projektplan, die Projektstatusberichte und der Projektabschlussbericht.
Qualitätsdokumentation
Dies sind alle Dokumente, in denen die Maßnahmen zur analytischen Qualitätssicherung dokumentiert sind. Beispiele sind Test- und Review-Berichte, der Abnahmebericht und Audit-Protokolle.
Prozessdokumentation
Diese Kategorie enthält die Dokumente, die den Entwicklungsprozess und seine konkrete Umsetzung im Projekt beschreiben. Beispiele sind Richtlinien, Handlungsanweisungen, Standards und Musterdokumente.
Durch die Einordnung eines Dokuments in dieser Taxonomie sind auch die folgenden Fragen beantwortet:
Welchem Zweck dient das Dokument?
• Damit auch: Was gehört hinein, was nicht?
Wer wird es lesen, verwenden?
• Damit auch: Welche Darstellungsform und welche Terminologie sind angemessen?
Muss das Dokument nachgeführt, aktualisiert werden? Oder ist im Gegenteil eine Veränderung unzulässig?
Wie lange muss das Dokument verfügbar bleiben?
Tabelle 12–1 zeigt diese Aspekte für die vier beschriebenen Kategorien im Überblick.
Dokumentenkategorie |
Zweck |
Adressaten |
Aktualisierung |
Aufbewahrungsfrist |
Systemdokumentation |
Erhaltung und Transfer des Know-hows, Einsatz des Systems |
Entwickler, Wartungsingenieure, Tester, Kunden |
erforderlich |
bis Ende der Systemnutzung |
Projektdokumentation |
Führung des Projekts, Analyse nach Projektende |
Linien- und Projektmanager, Kunden |
unerwünscht |
bis Projektende plus n Jahre |
Qualitätsdokumentation |
Nachweis der Maßnahmen zur Qualitätssicherung |
Linien- und Projektmanager, Kunden |
verboten |
bis Ende der Systemnutzung |
Prozessdokumentation |
Beschreibung der Vorgehensweise, Unterstützung bei der Durchführung |
alle, die aktiv am Projekt beteiligt sind |
sinnvoll |
bis Ende der Systemnutzung und so lange, wie der Hersteller existiert |
Tab. 12–1 Kategorien der Dokumente im Überblick
Für alle Teile der Software und damit natürlich auch für alle Teile einer separaten Dokumentation müssen die Fragen der Konfigurationsverwaltung (siehe Kap. 21) geklärt sein:
Wo und unter welcher Bezeichnung wird das Dokument aufbewahrt?
Wer hat auf das Dokument lesenden Zugriff? Wer hat schreibenden Zugriff?
Wessen Aufgabe ist die Prüfung und die Abnahme des Dokuments?
Bei den Zugriffsrechten ist natürlich vor allem wichtig, wer keinen Zugriff hat.
Damit Software eingesetzt werden kann, muss dokumentiert sein, wie sie installiert, betrieben und bedient wird. Diese Informationen werden zusammenfassend als Benutzungsdokumentation bezeichnet. Benutzungsdokumentation tritt in vielfältigen Ausprägungen auf; so sind beispielsweise das Benutzungshandbuch, ein Tutorial, das Administrations- und das Installationshandbuch, eine kontextsensitive Hilfe, aber auch Online-Informationen (z. B. FAQ- und Known-Bugs-Listen) Teile der Benutzungsdokumentation.
Diese Dokumente werden für verschiedene Adressaten (z. B. Anwender oder Administrator) erstellt, die sehr unterschiedliche Informationen benötigen. Tabelle 12–2 zeigt in Anlehnung an Sommerville (2001) eine Zuordnung einzelner Dokumente der Benutzungsdokumentation zu Adressaten.
Adressat |
Zweck |
Dokumente |
Käufer |
Kaufentscheidung treffen |
Produktbeschreibung |
Administrator |
Installation der Software |
Installationsanweisung |
Betrieb der Software Was muss ich wissen, um die Software nach der Installation zu betreiben? |
Administrationshandbuch Release-Notes |
|
Unerfahrener Anwender |
Bedienung kennenlernen Wie kann ich die Software starten und die wichtigsten Funktionen ausführen? |
Erste-Schritte-Dokument Tutorial |
Erfahrener Anwender |
Nachschlagen |
Benutzungshandbuch FAQ-Liste |
Tab. 12–2 Zuordnung von Benutzungsdokumentation zu Adressaten
Die Norm ISO/IEC 25051 (2006) definiert Anforderungen an Produkt- und Benutzungsdokumentation für Software, speziell für Massenware (Commercial Off-the-Shelf). Die Aussagen, die die Benutzungsdokumentation betreffen, lassen sich aber auch auf Individual-Software anwenden.
Die Norm fordert zuallererst, dass die Benutzungsdokumentation als Ganzes vollständig sein muss. Sie muss alle Funktionen, alle relevanten nichtfunktionalen Eigenschaften (z. B. Leistungsmerkmale), etwaige Einschränkungen, bekannte Fehler, die Installation und den Betrieb beschreiben. Ebenso muss die Benutzungsdokumentation korrekt, genau, in sich konsistent und verständlich sein. Insbesondere darf es keine Widersprüche zwischen der Dokumentation und dem installierten System geben; das System muss so funktionieren, wie es die Benutzungsdokumentation beschreibt.
Natürlich ist es nicht einfach, diese Anforderungen umzusetzen; jeder kennt eine Software, deren Handbuch nicht mit dem realen System übereinstimmt. Mag das bei einem Textverarbeitungssystem zwar störend, aber noch akzeptabel sein, dann ist es bei einem Steuerungssystem sicherlich nicht hinnehmbar. Weil die Benutzungsdokumentation ein wichtiger Teil der Software ist, sollte sie auch nach denselben Standards entwickelt und geprüft werden, die für die Programme gelten.
Dokumente müssen so aufgebaut und geschrieben sein, dass wir sie sinnvoll nutzen können. Perfekte Dokumente wären formal und damit präzise, sie wären für die Adressaten verständlich und objektivierbar formuliert. Solche perfekten Dokumente gibt es nicht.
Das Ziel der Dokumentation muss es darum sein, brauchbare Dokumente zu erstellen. Dabei sollten wir die Eigenschaften perfekter Dokumente anstreben. Das Folgende sollte für alle Dokumente gelten:
Dokumente sind Verfassern und Prüfern zugeordnet. Die Daten ihrer Erstellung, aller Änderungen und ihrer Prüfung(en) sind in den Dokumenten notiert.
Dokumente sind zweckmäßig strukturiert und geordnet, nicht individuell vom Verfasser, sondern durch Richtlinien, Vorgaben und Templates für alle. Dann kann sich jeder schnell in eine fremde Dokumentation einarbeiten und muss nicht für jedes Projekt neue Regeln lernen. Außerdem garantieren die vorgegebenen Strukturen eine gewisse Vollständigkeit, denn alle wichtigen Themenkomplexe sind in der Standardstruktur enthalten und können nicht vergessen werden.
Dokumente haben eine definierte Syntax. Damit ist hier allgemein die Form gemeint. Es sollte also klar sein, was wo steht und wie es dargestellt (repräsentiert) ist.
Dokumente haben eine definierte Semantik. Das heißt, dass die Aussagen nicht schwammig und nebulös sind, sondern eindeutig und, wo sinnvoll, schematisch. Es ist kein Vorteil, wenn für die gleiche Aussage immer wieder andere Formulierungen gewählt werden. In allen Dokumenten gilt: Wenn zwei Informationen gleich sind, sollten auch die entsprechenden Aussagen gleich sein.
Dokumente liegen in elektronischer Form vor.
Dokumente sind der Konfigurationsverwaltung unterstellt.
Dokumente sind untereinander voll verzeigert.
Durch die Standardisierung der Dokumentation (Abschnitt 12.3) wird die Arbeit wesentlich erleichtert, sowohl für die Ersteller, die sich nicht erst Struktur und Stil ausdenken müssen, als auch für die Verwender, die wissen, wo sie welche Information finden können.
Es gehört zu den Mysterien der menschlichen Natur, dass völlig normale Leute, die so reden wie alle anderen, schreckliche Dinge von sich geben, wenn sie schreiben. Die Unbeliebtheit der Dokumentation nicht nur bei den Verfassern, sondern auch bei den potenziellen Benutzern ist auch im Kanzleistil begründet, den viele Menschen bei der schriftlichen Kommunikation für erforderlich halten. Da wimmelt es von substantivierten Verben, falschen Genitiven und lächerlichen Worthülsen. Weg damit! Unser »Leitfaden« (Deininger et al., 2005) enthält eine ausführlichere Auseinandersetzung mit diesem unerfreulichen Phänomen.
Der bei technisch geprägten Menschen weitverbreitete Hochmut gegenüber Fragen des Stils trägt zweifellos erheblich zu diesen Problemen bei. Typische Kommentare sind: »Ist doch egal, Hauptsache, das ist irgendwo dokumentiert.« oder »Ich bin doch kein Schriftsteller!« Irrtum! Wer Software entwickelt, ist natürlich ein Schriftsteller! Aber leider oft ein schlechter.
Damit Dokumente übersichtlich, leicht zu durchsuchen und zu bearbeiten sind, sollten sie nicht in freier Form verfasst werden, sondern einem vorgegebenen Schema folgen.
Die zahlreichen nationalen und internationalen Normen bieten Vorschläge in großer Zahl, oft auf spezielle Dokumente bezogen, z. B. IEEE Std 1058 (1998) »Standard for Software Project Management Plans« oder IEEE Std 1063 (2001) »Standard for Software User Documentation«. Die deutschen Normen zu diesem Thema sind relativ alt, werden aber nach wie vor in Richtlinien und Verträgen verwendet. Das sind vor allem die Normen DIN 66230 (1981), 66231 (1982), 66232 (1985) sowie 66270 (1998) für Programmdokumentation, Programmentwicklungsdokumentation, Datendokumentation und Bewerten von Softwaredokumenten. Die einschlägigen internationalen Normen werden übersetzt und übernommen, z. B. ISO/IEC 6592 (2000) »Leitfaden für die Dokumentation von computergestützten Anwendungssystemen« oder ISO/IEC 18019 (2004) »Richtlinien für die Gestaltung und Vorbereitung von Benutzerdokumentation für Anwendungssoftware«.
Eine weitere Quelle für Dokumentvorlagen sind Prozessmodelle. So stellen das V-Modell (Abschnitt 10.3) und der Rational Unified Process (Abschnitt 10.4.3) für jeden definierten Dokumenttyp ein Template zur Verfügung, das angepasst werden kann.
In der Praxis gehört die Dokumentation meist zu den Problemzonen des Software Engineerings. Von der schritthaltenden Dokumentation, wie wir sie oben gefordert haben, kann häufig keine Rede sein. Vielmehr werden oft nur die vom Kunden verlangten Dokumente angefertigt, also Handbücher, Installationsanleitungen usw. Auch diese entstehen allzu oft erst gegen Ende des Projekts, vielfach verfasst von Leuten, die gerade verfügbar sind, ohne Rücksicht auf ihre Sachkenntnis.
Wir sehen zwei Gründe, warum die Dokumentation bei der Software-Entwicklung häufig vernachlässigt wird:
Software-Entwickler haben während ihrer Ausbildung und anschließend in ihrer Berufspraxis zwar Programmieren gelernt, aber nicht, Konzepte, Ideen und Entscheidungen zu formulieren. Da sie nicht dokumentieren können, dokumentieren sie auch nicht gern (vgl. Abschnitt 6.4, S. 79), und wenn doch, dann mit schlechten Resultaten.
Die Dokumentation wird zwar ständig und überall gepriesen, das sind aber vielfach nur Lippenbekenntnisse. Auf Priorität 1 steht die Einhaltung des Liefertermins, auf Priorität 2 und 3 auch. Da die Termine in fast allen Projekten so vorgegeben sind, dass selbst die Codierung kaum zu schaffen ist, werden Projektergebnisse, die gewünscht, aber nicht zwingend gefordert werden, nicht angefertigt. Dem fällt zuallererst die Dokumentation zum Opfer.
Die Forderung nach einer systematischen Dokumentation ist aber keine sinnlose Schikane. Findet die Dokumentation nicht statt, so sind dies die unvermeidlichen Folgen:
Aufzeichnungen über die Überlegungen und Entscheidungen während der Entwicklung fehlen, und nach kurzer Zeit lassen sich diese Informationen nicht mehr beschaffen. Jeder, der später die Software ändern muss, ist in der Situation eines Archäologen, der sich mit versunkenen Kulturen befasst, die keine Schrift hatten. Er ist auf Spekulationen angewiesen und liegt damit oft falsch.
Grundlagen für die Handbücher fehlen (siehe Abschnitt 16.1.2).
Retrospektive Analysen, die sich auf die Dokumente stützen müssen, sind nicht möglich. Damit hat die Organisation keine Möglichkeit, aus dem Projekt zu lernen.
Die Zuversicht, die Dokumentation bei Bedarf später zu verbessern oder ganz zu rekonstruieren, ist unbegründet. Alle Versuche, durch Reverse Engineering (Abschnitt 23.2.1) aus dem Quellcode die Dokumente abzuleiten, haben gezeigt, dass der Aufwand riesig, der Erfolg aber sehr bescheiden ist. Der weitaus beste und billigste Weg zu einer brauchbaren Dokumentation ist der direkte. Das bedeutet: Bei der Software-Entwicklung muss schritthaltend dokumentiert werden. Dabei sollte nur das dokumentiert werden, was nötig ist, dies aber sorgfältig und konsequent.
Es ist elend schwer zu lügen, wenn man die Wahrheit nicht kennt.
Peter Esterhazy, Harmonia Caelestis. Berlin-Verlag, 2001
Parnas und Clements (1986) haben unter dem provozierenden Titel »A rational design process – how and why to fake it« einen wichtigen Gedanken zur Dokumentation formuliert: Wenn wir auf komplizierte Weise, mit Irrtümern und Umwegen, zu einem Resultat gekommen sind, ist es nicht sinnvoll, alle, die das Resultat verstehen wollen, durch unsere Irrtümer und Umwege zu führen. Wir können und sollen stattdessen beschreiben, welcher rationale Weg zum selben Ergebnis geführt hätte, wenn wir schon zu Beginn gewusst hätten, was wir erst am Ende verstanden haben.
Wenn hier also von einer Fälschung die Rede ist, dann ist das eine bewusste Überspitzung. Es geht nicht darum, den Leser hinters Licht zu führen, sondern ihm Überlegungen zu ersparen, die sich als fruchtlos erwiesen haben. Die Dokumentation ist kein Protokoll der Entwicklung, sondern eine Hilfe zum Verständnis der Programme.
Diskussionen über dieses Konzept und Missverständnisse, die dabei sichtbar geworden sind, lassen es geboten erscheinen, die Anleitung von Parnas und Clements durch zwei Anmerkungen zu ergänzen:
Die Aussagen beziehen sich auf die technische Dokumentation, nicht auf die Dokumentation des Projektverlaufs. Es geht also nicht darum, den Projektverlauf zu schönen. Wir müssen aus den Fehlern lernen. Dazu müssen sie dokumentiert sein.
Möglicherweise stellt sich am Ende heraus, dass ein rationaler Entwicklungsprozess nicht zu diesem Resultat geführt hätte; der gewählte Weg war falsch, aber es ist – aus Zeit- und Aufwandsgründen – nicht mehr möglich, ihn zu korrigieren. Dann hat es natürlich keinen Sinn, falsche Entscheidungen als richtig darzustellen. Der einzige sinnvolle Weg, mit diesem Problem umzugehen, besteht darin, die Fehlentscheidung als Setzung in den Entwicklungsgang einzuführen. Das könnte beispielsweise die Form haben: »An diesem Punkt wurde entschieden, die Lösung A zu wählen. Nach heutiger Kenntnis wäre die Lösung B sinnvoller gewesen.« Wenn es dazu auch noch eine Begründung gibt, haben es Entwickler, die später über eine Verbesserung oder eine Neuimplementierung nachdenken, wesentlich leichter.