Spaghetti so weit das Auge reicht
Entwickler bei fast jeder Softwarefirma beklagen “Code-Altlasten”: Sie sprechen davon, dass die Codebasis schwer lesbar und schlecht strukturiert sei. Sie würde Designfehler enthalten und eine Dokumentation gäbe es natürlich auch nicht. Die Codepfade seien unübersichtlich und vielfältig. Es sei „Spaghetti-Code“ produziert worden. So nennt man es, wenn die Codepfade als sehr verschlungen und undurchdringlich erscheinen.
Ich habe dies jedenfalls zunächst bei jeder Firma erlebt, bei der ich war. Interessant ist, dass dies anscheinend auch bei reinen Softwarefirmen so ist, also Firmen, deren Produkte ausschließlich Software sind. Hier müssten doch die Profis arbeiten, denen das nicht passiert. Warum ist es trotzdem so?
Hat eine junge Softwarefirma während der Entstehung vielleicht oft unerfahrene Softwareentwickler? Vielleicht die Gründer des Start-ups selbst, die die erste Codebasis entwicklen ohne sich für teures Geld Know-how in die Firma holen zu wollen? Ist es vielleicht Hektik in der Gründungsphase, da eine erste Produktversion schnell fertiggestellt werden muss?
Ich habe zwei Varianten erlebt, ich nenne sie “Code Verwitterung” und “Unwissenheit”.
Tatsächlich ist die Codebasis zunächst sehr klein und übersichtlich. Doch es kommt immer schneller immer mehr Sourcecode dazu. Und der so gewachsene Code wird mit der Zeit immer unübersichtlicher, wenn man nicht stets das Gesamtdesign im Auge behält. Der Einbau neuer Features in eine Codebasis, die dafür nicht gedacht war, ist manchmal schwer oder gar nicht möglich. Schlechter Code entsteht schnell, wenn man nicht stets auf einen geordneten Umbau achtet. Egal wie viel Zeitdruck gerade herrscht. Notfalls muss eben auch mal ein komplettes Design geändert werden. Leider fehlt dafür oft die Zeit, oder schlicht der Wille und die Kraft, dies umzusetzen.
=> “Code Verwitterung”
Eine zweite Variante ist, dass die Zeit für einen Umbau eingeräumt wird, aber dieser Umbau nicht von dem gleichen Entwickler durchgeführt wird, der den ursprünglichen Code geschrieben hat. Der aktuelle Code wird aufgrund schlechter Dokumentation als schlecht bewertet und das Neuschreiben damit begründet. Der irrige Gedanke ist, dass durch das Neuschreiben quasi automatisch besserer Code entsteht und neue Feature leichter zu realisieren sind. In Wirklichkeit jedoch, wurde die bisherige Implementierung nur nicht verstanden. So endet ein Neubau leider tatsächlich manchmal mit einem neuen Feature mehr, einem alten Feature weniger – ausversehen – und neuem Code, den der neue Entwickler perfekt versteht. Aber sonst niemand. Es ist dann leider eine reine Zeitfrage, bis auch dieser Code leider nur noch als Altlast mit mitleidigen Augen betrachtet wird - von einem weiteren Entwickler - und einem erneuten Neuschreiben zum Opfer fällt.
=> “Unwissenheit”
Wie begegnet die moderne Softwareentwicklung diesem Thema?
In der agilen Gedankenwelt ist ein Neuschreiben von Code eher die Regel als die Ausnahme. Darüber wird nicht wieder und wieder neu nachgedacht und diskutiert. Wenn ein Umbau nötig ist, wird er angegangen.
Die Tests, die immer auch erstellt/programmiert werden, sichern einen Umbau ab. Sie zeigen das gewünschte Verhalten einer Implementierung auf und sind damit gleichzeitg ein zentraler Teil der Dokumentation.
Es arbeitet nie ein Entwickler alleine an einem Teil der Codebasis. Es wird in Pair-Programming und/oder durch Reviews für Wissensweitergabe gesorgt.