 |
(25.02.04 21:05)
Gut strukturierter und einfach verständlicher Quellcode ist unendlich wertvoll. Darum müssen wir jederzeit bereit sein, bestehenden Code wegzuschmeissen. Das kann weh tun, ist aber eine unverzichtbare Voraussetzung um zu verhindern, dass sich unsere Software schleichend in Zement verwandelt und damit einmal getroffene Entscheidungen unwideruflich macht. An dem Tag, an welchem wir uns nicht mehr getrauen, unseren Code zu ändern, wird er zur Hypothek.
Software ist nie fertig, im besten Fall ist sie angemessen und erfüllt die momentan an sie gestellten Anforderungen. Ändern sich die Anforderungen, führt dies auch zu mehr oder weniger umfangreichen Anpassungen an unserem Code. Und weil wir das zu lösende Problem mit der Zeit hoffentlich besser verstehen lernen, geschieht es häufig, dass Code, der einmal mit viel Hirnschmalz und Herzblut entworfen, implementiert und getestet worden ist, plötzlich nicht mehr nötig ist. Hier gilt es dann sein eigenes Zartgefühl zu erwürgen, und bei aller Liebe zu seinen Schöpfungen mit der gebührenden Härte durchzugreifen; Sentimentalitäten sind fehl am Platze.
Hunt&Thomas vergleichen das Schreiben von Software mit dem Anlegen und Pflegen eines Gartens. Das scheint mir ein sehr schöner Vergleich: Auch eine Software will geplant und bewirtschaftet werden, sie entsteht nicht von heute auf morgen. Einiges von dem, was wir säen, gelangt nicht zur gewünschten Blüte und Manches schiesst ins Kraut. Büsche wachsen und müssen von Zeit zu Zeit zurecht gestutzt werden, Beete und Wege sind regelmässig von Unkraut zu befreien, und ab und zu kommt es eben auch vor, dass wir sogar einen gesunden Baum fällen müssen, damit unser Garten als Ganzes in seiner vollen Pracht erstrahlen kann. Wer hier zögert, riskiert, dass sein Garten mehr und mehr verwildert und schliesslich zu einem unwirtlichen und garstigen Ort wird, an dem sich niemand zu lange aufhalten möchte.
Und noch etwas hält die Garten-Metapher für uns bereit: Die Erkenntnis, dass es ohne anständige Werkzeuge nicht geht. Wer möchte schon mit einem Suppenlöffel ein Loch graben oder mit einer Papierschere seine Büsche schneiden? Ertaunlich, wieviele Entwickler genau dies tun müssen, weil ihnen die nötigen Werkzeuge z.B. für sichere und rasche Refactorings fehlen. Welcher C++ oder Dephi-Entwickler hat nicht schon neidisch auf Entwicklungsumgebungen wie IntelliJ oder Eclipse geschielt und sich ähnliche Code-Refactoring-Unterstützung gewünscht?
Wer Software entwickeln will, der kommt um kontinuierliches Designen und Refaktorisieren nicht herum. Für manche Manager ist dies eine bittere Pille. Die oft gestellte Frage "Wann können wir damit rechnen, dass sich nichts mehr ändert?" zeugt nicht nur von einem fundamentalen Missverständnis bezüglich dessen, was es heisst, Software zu entwickeln. Diese Frage setzt Entwickler auch unnötig unter Druck, die Software doch endlich in Ruhe zu lassen. Diese Manager haben dabei häufig das Gefühl, dass die Entwickler mit Gold Plating wertvolle Zeit verlieren, anstatt neue Features zu implementieren. Sie sehen nicht ein, dass es oft nötig ist, Bestehendes zu verändern oder zu ersetzen, um Neues schaffen zu können. Leider sind das häufig die gleichen Leute, die gerne von Qualität reden, aber dem Erstellen der hierzu nötigen Tests nicht genügend Zeit einräumen. Diese pathologische Form des Managements ist Gift für gute Software.
Das Schreiben von echter Software ist schwierig. Die Vorstellung, es sei eine Sünde, einmal geschriebenen Code wegzuschmeissen, führt uns unwiderruflich auf den Pfad der Finsternis, an dessen Ende die Code-Hölle auf uns wartet.
-nemo :-)
Über diesen Artikel diskutieren.
|
|
