Haben Sie schon einmal bei einem neuen Kunden angefangen und gleich Bauchschmerzen bekommen, wenn Sie versuchten, aus dem vorgefundenen Code klug zu werden? Solche Bauchschmerzen, dass Sie am liebsten alles auf der Stelle neu schreiben oder vielleicht sogar gleich wieder nach Hause gehen wollten? Legacy Code lässt sich nicht immer ganz vermeiden: Viele Entwickler haben an einem Auftrag gearbeitet, bevor Sie kamen. Aber manchmal möchte man seinem Vorgänger am liebsten mal so richtig seine Meinung sagen...
Legacy Code hat natürlich nicht nur Schattenseiten
Meistens gehen alte Arbeit und neue Arbeit gut Hand in Hand, sodass Legacy Code oft auch seine Vorteile hat, sogar dann, wenn er auf einem älteren Framework läuft. Vor allem Nicht-Technologie-Unternehmen müssen viel in Software investieren und wollen diese nicht jedes Jahr aktualisieren, wenn es nicht unbedingt notwendig ist.
Wann wird also Legacy-Code wirklich zu einem Problem?
Wir haben unsere Entwickler befragt und 5 Typen entwickelt, die in Praktiken schwelgen, bei denen man sich die Haare rauft. Wenn Sie sich in einem dieser Typen wiedererkennen, dann gehen Sie in die Ecke und fangen Sie an, sich zu schämen. Wenn Sie einen Kollegen in einem dieser Typen erkennen, können Sie sich gerne kreativ rächen. Und wie? Probieren Sie es mal mit zuckerfreien Haribo-Bären.....
Der ständige Erfinder des Rades
Bei diesem Typen, der das Rad immer wieder von Neuem erfindet, handelt es sich nicht um ein Wunderkind, das mit großem Geschick einen etwas überkomplizierten Code geschrieben hat. Nein, hiermit meinen wir einen Entwickler, der kleine Probleme dadurch löst, dass er das Rad wieder und wieder komplett neu erfindet. Sie kennen sie bestimmt, diese Kollegen, die lieber mal auf Standardbibliotheken und Frameworks verzichten und stattdessen das Rad von Grund auf, na ja, Sie wissen schon...
Und wenn die irgendwann gehen? Nun, dann ist es Ihre Aufgabe, herauszufinden, wie alles tatsächlich zusammengebaut ist. Und der Praktikant oder der neue Mitarbeiter? Der braucht eine intensive Einarbeitung, denn der einzige, der wirklich Bescheid weiß, ist die Person, die den ganzen Kram zusammengebaut hat und jetzt nicht mehr da ist.
Der Technik-Freak
Wer kennt sie nicht? Die Kollegen (oder noch schlimmer die Manager), die immer nur auf die neuesten Entwicklungstrends stehen. Das neue besonders hippe Framework oder die umwälzend neue Arbeitsweise ist das einzige, worüber sie reden können. Und es genügt ihnen nicht, Fans der neuesten Entwicklungen zu sein, sie bestehen auch darauf, dass es asap implementiert oder genutzt wird.
Ach ja, da tummelt sich wieder einmal das eine oder andere obskure Framework auf dem Markt, dass Sie Hals über Kopf zum Einsatz bringen müssen. Toll, nicht wahr? Aber versuchen Sie einmal, dafür in fünf Jahren noch einen Entwickler zu finden …
Der überforderte Praktikant
Manchmal möchten sich Unternehmen um die Kosten drücken, die damit verbunden sind, eine erfahrene Kraft einzustellen, wenn man sie braucht. So schnappt man sich den Praktikanten: „Programmieren kannst du doch, oder?” Der Praktikant tut natürlich sein Bestes. Aber Code, den man sich irgendwie ergoogelt oder aus Workarounds abgekupfert hat, ist in der Regel langfristig nicht die beste Lösung.
Der Flammenlöscher
Wenn man für etwas eine schnelle Lösung haben möchte, löst man es oft nur für diesen Moment. Das eigentliche Problem wird nicht angegangen, es wird nur ein Feuer gelöscht. Nehmen Sie zum Beispiel eine App, bei der eine maximale Anzahl von Benutzern programmiert wurde. Sobald Sie dieses Maximum einmal erreicht haben, können Sie natürlich die maximale Anzahl von Benutzern heraufsetzen (Flammen löschen). Besser wäre es, eine nachhaltige Lösung zu finden, damit Sie nicht bei jedem Wachstumsschub immer wieder vor dem gleichen Problem stehen. Wenn solch ein Kollege vom Typ Feuerlöscher zu lange für ein Projekt arbeitet, haben Sie früher oder später einen mit schnellen Lösungen gespickten Legacy-Code und ein zusammengeflicktes Gebilde, das man 'später' zu einem guten Ende bringen will. Leider findet dieses 'später' nie statt und die Lösung des aufgestauten Problems bleibt an Ihnen hängen.
Der flotte Vielversprecher
Bei den letzten beiden Typen handelte es sich hauptsächlich um umstandsbedingte Code-Verunreiniger, aber der flotte Vielversprecher bringt es immer wieder fertig, dass ganze Teams gezwungen werden, schlechten Code zu basteln. Wenn der Manager ihn um etwas bittet, sagt er: „Kein Problem, in zwei Tagen läuft das!” ZWEI TAGE! Das reicht gerade, um den Code irgendwo reinzuhauen, aber ohne Debugging und Test. Jetzt geht aber der Manager davon aus, dass innerhalb von zwei Tagen alles erledigt ist. Also steht er in zwei Tagen auf der Matte und will das Ergebnis haben. Alle rennen sich die Beine aus dem Leib, um den Plan des flotten Vielversprechers zu halten. Vielleicht denken Sie noch: „Das machen wir später noch richtig“. Und schon ist es passiert, Sie haben sich der Riege der Flammenlöscher angeschlossen und werden nun ebenfalls ein Flammenlöscher.
Was lernen wir daraus? Dass aufgrund von Zeitdruck und unrealistischen Erwartungen jeder ein Netz aus problematischem Code spinnen kann. Bevor Sie also irgendwelche Racheaktionen planen, sollten Sie darüber nachdenken, was Sie selbst tun können, um das zu verhindern.
