Wenn die Software dann endlich fertig entwickelt ist und einen ersten „Smoke Test“ erfolgreich bestanden hat, geht es meist allzu schnell ins nächste Projekt.
Es ist viel hilfreicher die Überreste von Zwischenschritten und von Lösungsansätzen schließlich noch zu entfernen. Das heißt für die C Programmierung: Functions, Typedefs und Macros, die noch vorhanden sind, aber nicht benutzt werden, löschen.
Als Repository für „mögliche Lösungen für später“ verschiebt man diese Sachen besser in ein Repository, das extra dafür angelegt ist. „Google Code“ ist ein Beispiel für ein solches Repository.
Der Code im konkreten Projekt gewinnt durch diese Aufräumaktion sehr an Übersichtlichkeit und weniger potentiellen Fehlern. Damit wiederum geht die Zeit und anderer Aufwand, die für die Fehlersuche aufgebracht werden müssen, deutlich zurück. Das sind Aufwände, die weit mehr ausmachen, als der Aufwand für die Aufräumaktion.
Noch größer wird der Gewinn, wenn man die vorhandene Struktur vereinfacht und noch mehr Übersicht hineinbringt. Code wird schließlich nicht nur einmal geschrieben, sondern ständig gewartet, gepflegt und weiterentwickelt. Es ist also Sinnvoll, sich selbst und anderen die weitere Arbeit am Code so weit wie möglich zu erleichtern. Jeder, der einmal eine Software „debuggt“ und Fehler gesucht hat, wird wissen was ich mit diesem Post zum Ausdruck bringe,vor allem dann, wenn es die eigene jahrealte Software ist. 😉
Literaturhinweise dazu:
Martin Fowler
– Refactoring: Improving the Design of Existing Code
Henry David Thoreau
– Walden
als deutschsprachige Ausgabe:
– Walden oder Leben in den Wäldern
