Die Ursache für mangelhafte Dokumentationen ist meist: Programmierer bauen lieber neue Features in ihre Software ein als alte Funktionen zu dokumentieren. Dabei ist es gar nicht so schwer, dem Programm zumindest so viel Informationen mitzugeben, dass auch andere Entwickler und Benutzer davon profitieren können. Schließlich ist das ja auch ein Grund dafür, Software samt Quellcode zu veröffentlichen.
Der Kasten "Schritte zur Dokumentation" gibt zunächst ein paar allgemeine Tipps für das Dokumentieren von Programmen. Im Mittelpunkt dieses Artikels steht dann aber das Tool Apache Forrest, das sehr ansprechende Dokumentationen erzeugt, ohne dass der Anwender großartige Kenntnisse im Webdesign braucht. Das Ergebnis lässt sich mit dem Code zusammen paketieren, man kann es auch gleichzeitig als Webauftritt des eigenen Projekts nutzen. Apache Forrest wird von Apache für einige Projekte wie Xml.apache.org selbst verwendet. Es hat also seine Nützlichkeit in einem größeren Umfeld bereits bewiesen.
|
Programme entstehen oft für den Eigenbedarf, der Entwickler veröffentlicht sie erst, wenn sie eine gewisse Reife erreicht haben. An Dokumentation denkt er zuerst kaum, aber das lässt sich nachträglich ändern.
Jedes Programmpaket sollte unbedingt eine Datei »README« im Wurzelverzeichnis der Quellen haben. Hier beschreibt der Entwickler die grundsätzliche Funktionalität und wie der Anwender das Programm aufruft. Ein weiterer Quasi-Standard ist eine Datei »INSTALL« mit der Installationsanleitung. Überaus nützlich für die tägliche Arbeit ist eine Kurzhilfe innerhalb des Programms. Der Aufruf »Programm -?« oder »Programm -h« sollte alle wesentlichen Aufrufparameter und wichtige Hinweise ausspucken. Eine besondere Form der Benutzerhilfe ist das Prinzip der kleinsten Überraschung (Principle of least surprise): Ein Programm sollte das tun, was der gesunde Menschenverstand von ihm erwartet.
Für Kommandozeilenprogramme ist der Unix- und Linux-Benutzer durch Unmengen von Tools darauf vorbereitet, Optionen und Parameter zu parsen. Am besten verwenden Programmierer also von vornherein die »getOpts()«-Funktion, die unter diesem oder einem ähnlichen Namen für alle gängigen Programmier- und Skriptsprachen verfügbar ist. Der Klassiker: Die Manpage
Wer mehr Arbeit investieren will, schreibt als Nächstes eine Manpage. Niemand sollte sich dabei von der inzwischen obskur anmutenden Syntax aus den Urzeiten von Unix abschrecken lassen, es ist einfacher, als man denkt.
Für GUI-Anwendungen wichtiger als eine Manpage ist die Einbindung in das Hilfesystem der entsprechenden Desktop-Umgebung. Sowohl KDE als auch Gnome stellen Entwicklungsumgebungen und Anwendungstemplates zur Verfügung, der Entwickler muss also nur relativ wenig Aufwand treiben. GUI-spezifische Hilfe
Wer nicht für die großen Desktop-Umgebungen programmiert, sollte einen Blick auf andere Anwendungen werfen, die mit dem gleichen GUI-Toolkit entwickelt wurden. Meist findet sich hier etwas, was wiederverwendbar ist (Java-Anwendungen sollten zum Beispiel Javahelp nutzen).
In jedem Fall gelten aber die Regeln: Etwas Dokumentation ist besser als gar nichts. Mehr Doku ist natürlich besser als wenig - aber nur, wenn sie nicht veraltet ist und den User dadurch in die Irre führt.
|
Forrest erledigt natürlich nicht die inhaltliche Dokumentation, sondern nur die ansprechende Formatierung als HTML- und PDF-Dokument. Es genügt prinzipiell, die Doku-Seiten in einfachstem HTML zu schreiben, zum Beispiel die Tags »h1« und »p«. Mehr ist möglich, aber nicht unbedingt nötig.
Download und Installation
Die ersten Schritte sind der Download (aktuell ist die Version 0.7), die Installation sowie die Konfiguration der Benutzerumgebung. Am besten ist es, den gut 20 MByte großen Tarball von [1] herunterzuladen und ihn an einem geeigneten Ort zu entpacken, zum Beispiel im Verzeichnis »/usr/local«. Das Paket bringt eine ganze Reihe weiterer Tools mit, zum Beispiel Ant und Jetty, sodass zusätzliche Installationsschritte entfallen. Es setzt nur eine Java-Runtime-Umgebung voraus, das GNU-Pendant GCJ funktioniert allerdings nicht. Die folgenden Zeilen richten die Umgebung ein:
export FORREST_HOME=/usr/local/apache-forrest-0.7
export PATH=$PATH:$FORREST_HOME/bin
Der nächste Schritt - das lokale Generieren der Forrest-Dokumentation - ist ein bisschen schwieriger, denn in die Version 0.7 hat sich ein Fehler eingeschlichen, der ironischerweise die eigene Dokumentation betrifft. Warum bisher noch keine gepatchte Version erschienen ist, bleibt rätselhaft. Wer die Mühe des im Folgenden beschriebenen Workaround scheut, findet die Forrest-Hilfe auch online.
Versionskonflikt
Im Prinzip ist der Schritt sehr einfach, denn die Erzeugung von Dokumentationen ist schließlich das Kerngeschäft von Forrest. Man wechselt in das Verzeichnis »$FORREST_HOME/site-author« und führt den Befehl »forrest« aus. Wichtig ist, dass zumindest beim ersten Aufruf eine Verbindung zum Internet besteht, denn dabei lädt Forrest Plugins und Skins herunter - was es damit auf sich hat, erklärt der Artikel später.
Preis für die Aktualität sind Versions-Inkompatibilitäten. Die Dokumentation für Forrest 0.7 benötigt von zwei Plugins nicht die aktuellen, sondern ältere Versionen. Deshalb ist es erforderlich, in der Datei »$FORREST_HOME/site-author/forrest.properties« die Liste der Plugins in der letzten Zeile folgendermaßen zu verändern:
project.required.plugins=org.apache.forrest.plugin.input.dtdx-0.1,org.apache.forrest.plugin.input.projectInfo-0.1,...
Damit verwendet Forrest die Plugins »input« und »projectInfo« in der älteren Version 0.1.
Dass es bisher weder dieser kleine Workaround noch die Doku dazu auf die Forrest-Webseite geschafft haben, ist das einzig Enttäuschende an diesem Projekt und ein Beispiel für Dokumentation, wie sie nicht sein sollte: veraltet. Auf der Forrest-Mailingliste ist dies eine oft gestellte Frage, denn es trifft jeden, der die Doku lieber lokal hält. Mit der oben beschriebenen Änderung läuft die Generierung der Dokumentation innerhalb weniger Minuten durch. Insgesamt entstehen über 500 Seiten mit etwa 12 MByte.