Oliver Fischer E-Post Development

Mit jQAssistant steht ein mächtiges Werkzeug zur Verfügung, mit dem sich Projekte explorativ untersuchen und beliebige Codierungs- und Architekturregeln validieren lassen.

In jedem Projekt gibt es eine Reihe von Regeln zum Aufbau und der Funktionsweise der technischen Aspekte, die jedoch immer nur schwer einzuhalten sind. Ein Ansatz, der auf der Überführung eines Projekts in einen Graphen basiert, zeigt hier mögliche Wege auf.

Softwareentwicklung im Kleinen ist nicht schwer, im Großen dafür umso mehr. Eine Weisheit, die jedem Softwareentwickler zu einem bestimmten Zeitpunkt bewusst wird, spätestens jedoch bei einem großen und langlaufenden Softwareprojekt. Am Anfang steht der Auftrag für ein neues System. Ein neues Projekt entsteht immer auf der Basis des Wissens der beteiligten Entwickler und deren Erfahrungen aus vorhergehenden Projekten. Dieses Wissen kann aus allgemeingültigen Praktiken und, sofern nicht ein vollkommen neuer Technologiestack gewählt wird, bewährten Lösungen für die eingesetzten Technologien bestehen. Die Beteiligten wissen, welche Probleme sie womöglich auf technologischer Seite erwarten und wie ein Projekt erfolgreich strukturiert wird, um die Übersicht zu bewahren.

Demnach müsste jedes Softwareprojekt immer besser sein als der Vorgänger. Leider ist dem nicht so. Die Gründe hierfür sind vielfältig und beginnen sofort mit der beim Projektbeginn einsetzenden Erosion der Softwarearchitektur des Systems. Das klingt widersprüchlich, denn das System ist neu und auch noch gar nicht fertig. Und schon soll es erodieren? Dass dies kein Widerspruch ist, zeigt der Projektalltag. Die Entwickler beginnen zwar mit einer klaren Vorstellung des neuen Systems, doch neue Erfahrungen und neue Anforderungen fließen in neue Bestandteile des Systems ein. Die Weiterentwicklung kann auch positiv als ständige Evolution der Softwarearchitektur bezeichnet werden, und ist insofern auch positiv. Die Zeit diese Veränderungen nachträglich auf das gesamte System zu übertragen, fehlt jedoch meistens oder fristet nur in Form eines vergessenen To-dos seine Existenz im Code. Oft genug geht auch einfach der Überblick verloren. Der Berg an technischen Schulden wächst.

Es gibt auch noch weitere zerstörende Faktoren. Änderungen in der Teamzusammensetzung wirken sich ebenso auf die Softwarearchitektur aus, die im Team entsteht. Das Ausscheiden von Teammitgliedern ist auch immer ein Wissensverlust. Junge, nicht so erfahrene Entwickler schreiben anders Code als erfahrene. Sämtliche Änderungen hinterlassen ihre Spuren in einem Softwareprojekt. Wer kennt noch die Konzepte und Ideen, die anfangs dem System zugrunde lagen, wenn die Beteiligten nicht mehr an Bord sind?

In seinem Refactoring-Buch führt Martin Fowler aus, dass eine Notwendigkeit für ein kontinuierliches Refactoring in dem Umstand liegt, dass das Verständnis für Code verloren geht, der über mehrere Jahre nicht angefasst wurde. Auch weißt Parnas in seinem lesenswerten Artikel „Software Aging“ auf diesen Umstand hin und bezeichnet es als „Ignorant Surgery“, wenn Änderungen ohne Kenntnis der eigentlichen Konzepte und Strukturen vorgenommen werden.

Ein Mittel gegen diesen Wissensverlust ist die Erstellung und Pflege der Dokumentation zur Architektur der Software. Das Paradoxon der Softwarearchitekturdokumentation liegt darin, dass sie umso schneller veraltet, je gründlicher sie ist. Auf den zweiten Blick klärt sich auch dieser Widerspruch. Die Dokumentation eines Systems und das System selbst sind zwei unterschiedliche Artefakte. Software unterliegt oft einem schnelleren Änderungsrhythmus als die Dokumentation. Zudem kann das Dokumentieren selbst oft länger dauern, als die Programmierung selbst. Außerdem ist Dokumentation schmerzfrei. Irgendwann entfernen sich Dokumentation und Software so weit voneinander, das die Dokumentation ihren Nutzen verliert und deshalb auch nicht mehr als wertvoll erachtet wird. Zu sagen, das sei unvermeidlich, ist natürlich falsch. Denn die Bereitstellung von mehr Zeit und die Einstufung von Dokumentation als First-Class Citizen sind Mittel dagegen. Doch am Ende ist es eine Frage der Kosten. Und diese wird meist zugunsten von Fachlichkeit beantwortet.

Ideal wäre es, wenn automatisch sichergestellt werden könnte, dass Dokumentation und Software übereinstimmen. Wenn es also ein Tool gäbe, dass die Dokumentation lesen und ein bestehendes Softwareprojekt auf Einhaltung sämtlicher vorgegebener Regeln überprüft.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 1.17 - "Ich habe fertig!"

Alle Infos zum Heft
579750559jQAssistant: Code und Dokumentation stimmen automatisch überein?
X
- Gib Deinen Standort ein -
- or -