Beruflich und privat fasziniert mich Software-Entwicklung. Besonders gilt dem Streben nach qualitativ hochwertiger Software mein Augenmerk. Die folgenden Niederschriften entstanden aus Gedanken, die durch Leute wie Martin Fowler, Robert C. Martin und wie sie alle heißen beeinflusst wurden. Niedergeschrieben habe ich sie, weil ich hoffe, dass meine Kollegen ebenfalls nützliches daraus ziehen mögen.
Die tolle Abkürzung DTI ist meine eigene Erfindung. Was sie bedeutet will ich jetzt noch nicht erläutern. Ich halte es für eindrucksvoller, wenn Ihr Euch die Bedeutung nach und nach aus dem Artikel erschließt.
Um es kurz zu machen: nein, einfach so umbauen geht gar nicht! Oft ist es verführerisch, weil man die Lösung ja schon im Kopf hat. ABER: man hat zwar die Lösung an einer speziellen Stelle, dennoch kann die Dokumentation durch die Lösung veralten, Tests können fehlschlagen und Abhängigkeiten zu anderen Codestellen können übersehen werden. Bevor man Änderungen vornimmt sollte man hinreichend prüfen, wo mögliche Fallstricke lauern und entsprechend behutsam vorgehen.
Auf die Fragestellung bin ich gekommen, weil zum Thema DTI immer wieder die Frage aufgetaucht ist, wie das denn ist, wenn ich einen Umbau auf bestehendem Code vornehmen muss. Vor allem, weil die Dokumentation dann veraltet, die ja wegen DTI schon da ist. Wie kann das funktionieren? Ganz vorneweg will ich dazu anmerken, dass das es KEIN DTI-Immanentes Problem ist! DTI verschärft es höchstens, weil die Dokumentation immer schon fertig ist (im Gegensatz zu Arbeitsweisen, bei denen die Dokumentation nie fertig wird).