Werkzeuge zur Erhaltung der Softwarearchitektur / QS – Teil 1


Nach etwas Pause in diesem Blog werde ich nach und nach einige Posts zum “Thema Werkzeuge zur Architekturerhaltung / QS” veröffentlichen. In diesem Post geht es um die QS im Rahmen von Java Projekten. Viele Punkte – aber nicht alle Werkzeuge – sind aber auch auf andere Sprachen zu übertragen. Das Einhalten einer Softwarearchitektur stellt sicher, dass wir im Sinne unseres Kunden, der auch eine interne Fachabteilung sein kann, eine Investitionssicherheit mit dem Produkt liefern. Ziele sind:

  • Funktionserfüllung
    • Initiale und dauerhafte Erfüllung von (Kunden)Anforderungen
  • Zeitlich angemessene Arbeiten an dem Produkt
    • Erweiterung
    • Wartung
    • Schnelle Reaktion auf Kundenanforderungen / Funktionsumsetzung
    • ggf. zeitnahe Einarbeitung neuer Mitarbeiter

Um diese Ziele erreichen zu können, müssen wir uns schnell in den Quellcode einarbeiten und ihn verstehen können. Die Rahmenbedingungen hierbei sind

  • die Domäne, in der wir uns aktuell befinden
  • und die Technische Rahmenbedingungen

Erstere ist von uns nicht beeinflussbar, da Sie durch den Kunden vorgegeben wird. Bei dem zweiten Punkt können wir durch Definition einer Architektur und durch deren werkzeugunterstützte Einhaltung sehr viel erreichen und somit die Qualität und Zielerreichung der Software deutlich verbessern. Dabei ist es nicht relevant ob es sich um fremde Code-Teile oder eigene Code-Teile handelt. Es ist wohl jeden von uns schon einmal passiert: wir implementieren etwas, sehen darüber uns sagen „chic“, klar, deutlich, gute Lösung! Nach einigen Monaten in anderen Projekten ist man bei erneuter Durchsicht, da Änderunegen anstehen, der Meinung, dass eventuell an der einen oder anderen Stelle etwas mehr Informationen und ein klarer Entwicklungsstil besser gewesen wäre. Ziel der in dieser Postserie beschriebenen Punkte ist es, Quellcode und Architektur so zu gestalten, dass alle beteiligten Entwickler sich schnell einarbeiten können und damit die wirtschaftliche Entwicklung sicherstellen. Insbesondere wollen wir eine geringe Architekturerosion (wenige neue technische Schulden) und die Vermeidung von Code-Smells vorantreiben.

Du hast Fragen oder Anmerkungen? Kontakt: arndt@schoenb.de