© Excellent backgrounds/Shutterstock.com
Java Magazin
Auf dem Weg zur validierbaren Architekturdokumentation

jQAssistant: dein Code, deine Regeln

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.

Oliver B. Fischer


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 vom neuen System, doch neue Erfahrungen und neue Anforderungen fließen in neue Bestandteile des Systems ein. Die Weiterentwicklung kann auch 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 [1] 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 weist David L...

Java Magazin
Auf dem Weg zur validierbaren Architekturdokumentation

jQAssistant: dein Code, deine Regeln

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.

Oliver B. Fischer


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 vom neuen System, doch neue Erfahrungen und neue Anforderungen fließen in neue Bestandteile des Systems ein. Die Weiterentwicklung kann auch 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 [1] 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 weist David L...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang