(08.04.04 20:10)

Wenn ich Code schreibe, dann ist ein Teil meines Bewusstseins stets damit beschäftigt, mich bei der Arbeit zu beobachten; ich achte sehr sorgfältig darauf, wie sich der Umgang mit dem Code an und mit dem ich arbeite „an fühlt„. Diese Form der Introspektion ist für mich sehr wichtig, da sie mir hilft, die Codequalität zu erhalten. Code ist etwas sehr Organisches – ein form- und veränderbares System. Weil das so ist, kommt es immer wieder vor, dass der Code anfängt sich gegen bestimmte Dinge zu wehren. Wenn das geschieht, dann ist es an der Zeit, sich Gedanken über nötige Refactorings oder gar Redesigns zu machen. Denn: Drücken wir das System, drückt das System. Dieser Grundsatz gilt auch für Programmcode. Wenn wir versuchen, "gegen diesen Code-Druck an zu programmieren", dann verschwenden wir nicht nur Zeit und Energie, sondern wir behindern auch die gesunde Evolution unserer Codes; im schlimmsten Fall schrammen wir sogar am Ziel vorbei, das anstehende Problem zu lösen.

Code-Druck zeigt sich auf verschiedene Weise – hier nur einige Beispiele:

	Die Parameterliste einer Methode muss um ein weiteres Argument erweitert werden und wird dadurch zu lang.
	Um eine bestimmte Funktionaliät umsetzen zu können, benötigen wir Statusinformationen eines anderen Objektes.
	Wir ertappen uns beim Schreiben einer Nachrichten-Kette, um Zugriff auf bestimmte Dienste eines anderen Objektes zu erlangen.
	Wir benötigten Zugriff auf ein bestimmtes Objekt, von dem wir wissen, das es da ist, das wir aber an dieser Stelle gar nicht oder nur mit schmutzigen Tricks erreichen können.
	Die Menge des zu schreibenden Setup-Codes in einem Test ist um ein Vielfaches grösser geworden als der eigentliche Testcode für die zu testende Klasse.
	Die Verwendung einer Klasse fühlt sich nach einer Erweiterung nicht mehr gut an, und man ertappt sich dabei, wie man immer wieder den gleichen Fehler macht, wenn man Objekte dieser Klasse verwendet.

Code-Druck ist ein ernst zu nehmendes Warnsignal, dass mit unserem Code etwas nicht mehr stimmt. Das bedeutet nun nicht, dass der Code falsch oder fehlerhaft wäre, es ist schlicht der Hinweis, dass der Code den gestellten Anforderungen nicht mehr genügt und überarbeitet werden muss. Erkennen wir die Symptome früh genug, dann können wir unsern Code kontrolliert und ordnend gestalten und umformen, so dass er stets einem wohl gepflegtem und sich mit der Zeit und den Bedürfnissen seiner Benutzer wandelnden Garten gleicht. Reagieren wir dagegen auf den Code Druck unsererseits mit Druck, dann verwandelt sich unsere Software bald in einen ungepflegten Garten mit allerlei wuchernden Pflanzen und halbfertigen Wegen, in dem sich bald niemand mehr auskennt, geschweige denn wohl fühlt.

In diesem Sinne ist Softwarewartung nichts anderes als kontinuierliche Entwicklung, die - wie Gartenarbeiten auch - die richtige Mischung aus Planung, Weitsicht, Hingabe und Intuition verlangt.

-nemo :-)

Über diesen Artikel diskutieren.

Zugriffe heute: 1 - gesamt: 4649.