Software

Spaghetti so weit das Auge reicht

Bei jeder Softwarefirma arbeiten zunächst bei der Gründung nur Stümper, Dilettanten und Amateure in der Entwicklung: Der produzierte Code ist schwer lesbar, ist schlecht strukturiert, enthält klassische Designfehler, eine API-Dokumentation gibt es nicht, natürlich auch keine Design- und Konzeptdokumente usw. usw. usw. „Spaghetti-Code“ nennt man so etwas, wenn die Codepfade als sehr verschlungen und undurchdringlich erscheinen. Wieso ist dies aber bei jeder Softwarefirma so? Zumindest scheint dies so zu sein, denn Entwickler beklagen stets die Code-Altlasten, die sie mit sich herumzuschleppen haben. Bei absolut jeder Firma, die Software herstellt. Insbesondere auch bei Spezialisten auf diesem Gebiet. Also reinen Softwarefirmen.

Komisch.

Hat eine junge Softwarefirma oft unerfahrene Softwareentwickler und, wenn ja, warum? Erstellen die Gründer des Start-ups selbst die erste Codebasis ohne sich für teures Geld Know-how in die Firma holen zu wollen? Natürlich muss gerade in der Gründungsphase ein erstes Produkt schnell fertiggestellt werden. Ist also in Wirklichkeit Hektik der Grund?

Es gibt da noch eine mögliche Antwort: Es stimmt gar nicht! Tatsächlich ist die Codebasis zunächst sehr klein und übersichtlich und ganz gut. 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 schlicht schwer oder gar nicht möglich! Schlechter Code entsteht immer, 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 fehlen dafür oft die Zeit, oder schlicht der Wille und die Kraft, dies umzusetzen. Gerade wenn der Code nicht von dem gleichen Entwickler erweitert wird, der ihn ursprünglich geschrieben hat. Viel zu leicht kommt dann der irrige Gedanke auf, dass durch das Neuschreiben besserer Code entsteht und das neue Feature leichter zu realisieren ist. Dies ist nicht zuletzt deshalb ein Trugschluss, weil es voraussetzt, dass man den alten Code, und noch wichtiger, dessen Ziele, also welche Feature er implementiert, überraschend oft nicht kennt, denn es gibt ja meistens keine, oder zumindest keine vollständige, Dokumentation. Ja, auch keine der Feature. 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. Schlimmstenfalls erneut ohne ausreichende Dokumentation, denn nun „kennt man den Code doch sehr gut und er ist super lesbar“. Findet zumindest der aktuelle Entwickler. Es ist leider eine reine Zeitfrage, bis auch dieser Code leider nur noch als Altlast mit mitleidigen Augen betrachtet wird und einem erneuten Neuschreiben zum Opfer fällt. Diesmal hoffentlich final und mit guter Dokumentation.

Kategorien:Software