Röntgenblick für Architekten

Softwareentwickler verändern bestehenden Code weit häufiger, als sie neuen schreiben. Diese Änderungen können notwendig sein, um vorhandene Features zu erweitern oder neue bereitzustellen. Häufig dienen sie aber auch der besseren Wartbarkeit, Lesbarkeit und Veränderbarkeit von Code. Insofern dabei nur die interne Struktur, aber nicht das Verhalten angepasst wird, spricht man von einem Refactoring. Refactorings geschehen in der Programmierung recht häufig, ohne dass wir uns zuvor größere Gedanken darüber machen. Mal ist es notwendig, den Namen einer Methode anzupassen, damit dieser ihr Verhalten besser widerspiegelt. Ein anderes Mal muss ihr Rückgabetyp verändert werden, weil zusätzliche Daten bereitzustellen sind. Refactorings aber auf einen solchen Level zu reduzieren ist falsch, denn je länger an der Software gearbeitet wird, desto mehr verändert sich die Struktur nicht nur im Kleinen, sondern auch im Großen, und dies kann Auswirkungen auf die Architektur des Softwaresystems haben. An diesem Punkt hilft dann auch eine reine Quellcodeansicht nicht mehr, da diese zu feingranular ist. Wir sehen im Code zwar genau, was jeder Bestandteil tut, nicht aber, wie diese Bestandteile in Gänze miteinander kommunizieren beziehungsweise interagieren. Verliert man die Zusammenhänge jedoch aus den Augen, läuft man langfristig Gefahr, ein undurchdringliches Dickicht von Abhängigkeiten zu schaffen, welches Anpassungen an der Software oder die Suche nach Fehlern erschwert.