Von Pyramiden und (nicht vorhandener) Dokumentation
Seite 2: Mittel der Wahl
Ein erster Ansatz kann die Betrachtung der Pyramiden vor Ort sein. Ganz klassisch: Man notiert seine Eindrücke, vermisst von Hand, prüft die verwendeten Materialien, führt Ausgrabungen durch und vieles andere mehr. In der IT entspricht das einer manuellen Analyse. Man sieht sich die Entwicklungsobjekte in der Entwicklungsumgebung an. Methoden, Klassen und Datenbanktabellen, manchmal sogar Unit-Tests und all die anderen Bausteine einer Anwendung.
Einen weiteren Ansatz bietet moderne Technik. Cäsar hätte darauf zwar nicht zurückgreifen können, aber Drohnen mit hochauflösenden Kameras und Bodenradar können heute schnell neue Erkenntnisse über die Pyramiden und ihre Umgebung liefern. Solche Möglichkeiten bestehen auch für Software. Man kann sich zum Beispiel ein Klassendiagramm generieren lassen. Dadurch erhält man schneller einen Überblick und kann interessante Entwicklungsobjekte und ihre Zusammenhänge identifizieren.
Dann wäre da noch der Ansatz durch Ausprobieren. In Bezug auf die Pyramiden: Gibt es einen antiken Mechanismus, den man heute noch aktivieren kann? Zwar lehrt jeder gute Abenteuerfilm, dass man genau das nicht tun sollte. In der Realität kann die Beobachtung der Funktionsweise aber sehr aufschlussreich sein – wenn man dadurch nur nicht gerade einen uralten Fluch freisetzt. In der Softwareentwicklung bedeutet das, die Software nach Möglichkeit in einer Testumgebung auszuführen. Der Debugger hilft, die Funktionsweise nachzuvollziehen. Daraus kann wiederum ein Laufzeitdiagramm entstehen.
Zu guter Letzt wäre da noch die Dokumentation am oder im zu untersuchenden Objekt selbst. In den Pyramiden gibt es beispielsweise Abbildungen an den Wänden, die aus der Zeit ihrer Entstehung berichten. In Quelltexten gibt es wiederum Kommentare, und manche Entwicklungsobjekte lassen sich sogar separat dokumentieren, wobei die Dokumentation dadurch ein Bestandteil des Entwicklungsobjekts ist. Eine mehr als sinnvolle Einheit, die auch noch Jahre später Aufschluss geben kann.
Das waren nun mehrere Ansätze, die vielen Entwicklern aus ihrem Arbeitsalltag bekannt vorkommen dürften. Alle Ansätze stützen sich dabei auf das, was überdauert: die Entwicklungsobjekte selbst. Im Gegensatz zu einer Dokumentation, die häufig mit einer Textverarbeitung als separate Datei erstellt wird. Durch die fehlende Verbindung zwischen der Dokumentation und den eigentlichen Entwicklungsobjekten, die zur Ausführung der Anwendung notwendig sind, kann das Unglück ungehindert seinen freien Lauf nehmen. Denn es entstehen zwei "Lebenszyklen". Der eine betrifft die Anwendungsobjekte, der andere die Dokumentation. Berücksichtigt man nun noch die in der Praxis häufig unterschiedlichen Ablageorte, ist die fehlende Verfügbarkeit von Dokumentation keine Überraschung mehr, ebenso der zeitlich schnelle Verlust der inhaltlichen Gültigkeit. Eine logische Einheit ist eben keine technische Einheit.
Damit rückt, zumindest für Entwickler, die Bedeutung der Aussagekraft von Entwicklungsobjekten noch stärker in den Vordergrund. Glücklicherweise gibt es für dieses Thema Hilfe: Clean Code. Eine Sammlung von Regeln, Konzepten, Verfahren und einigem anderen mehr, um verständliche und damit wartbare Entwicklungsobjekte zu erzeugen. Auch für die vom Autor verwendete Programmiersprache ABAP (Advanced Business Application Programming) der Firma SAP gibt es seit ungefähr einem Jahr eine an diese Sprache angepasst Umsetzung in Form des "Clean ABAP"-Handbuchs. Es ist öffentlich und jeder kann, dank der Möglichkeiten von GitHub, daran mitarbeiten.
Schlussworte
Die Bewertung nach einem Jahr Arbeit, unter bestmöglicher Berücksichtigung der Empfehlungen aus diesem Handbuch im Arbeitsalltag, fällt mehr als positiv aus. Die Entwicklungsobjekte selbst beantworten nun schon so manche Frage, die früher eine Dokumentation hätte beantworten müssen. Eine Dokumentation wird dadurch zwar nicht obsolet, aber das Fehlen einer Dokumentation wird erträglicher. Das Schreiben einer Dokumentation wird übrigens, dank der Strukturiertheit, die Clean Code einfordert, leichter.
Zum Schluss dieses Artikels noch eine interessante, historische Tatsache: Auch die Erbauer der Pyramiden mussten üben. Zeugnis davon legt heute noch die Knickpyramide ab. Sie entspricht nicht "ganz" der gängigen, geometrischen Vorstellung einer Pyramide. Und auch hier findet sich eine Parallele zu der Arbeit von Entwicklern: Das Programmieren nach Clean-Code-Prinzipien muss geübt werden. Wieder und wieder ...
Michael Keller
arbeitet als Softwareentwickler mit der Programmiersprache ABAP im Logistikumfeld von SAP-ERP-Systemen. Darüber hinaus beschäftigt er sich auch in seiner Freizeit mit dieser Sprache, ist als Blogger in der SAP-Community und als Dozent an einer Fachhochschule tätig.
(ane)
