Es war einmal ein König, der erfuhr, dass seine Untertanen besser arbeiten und dem Königreich mehr Nutzen bringen könnten, wenn sie ein System hätten, um ihre Arbeit zu verbessern. Also wurde ein Rat der Heiligen Drei Könige einberufen und ein Dokument erstellt, in das jeder von ihnen schrieb, was er wollte. Dieses wiederum wurde dem Grand Manager ausgehändigt, der die Entwickler anrief und sagte: „Hier ist der Plan. Und jetzt an die Arbeit! Es sollte für gestern fertig sein!
Die Entwickler haben sich mit dem Dokument in ihrem übrigens recht praktischen Dungeon eingesperrt. Sie fingen an nachzudenken, tippten mit den Finger auf die Tastaturen und dachten noch einmal nach. Sie wurden regelmäßig mit Bottichen mit heißem Kaffee und Vorräten an Pizzen und Hamburgern aufgefüllt. Nach ein paar Wochen konnte der Grand Manager dem König endlich ihre Schöpfung zeigen — das System. Allen gefiel es sofort, es war hübsch und es sollte für alle sehr nützlich sein. Er erhielt sogar eine eigene Kammer im Schloss und wurde regelmäßig mit Daten gefüttert. Eigentlich sollte dieses Märchen mit dem Satz enden: „Und sie lebten glücklich bis ans Ende ihrer Tage.“ Leider war das Finale, wie es im Leben passiert, nicht so offensichtlich. Es stellte sich heraus, dass dem System Dinge beigebracht werden müssen, von denen selbst die größten Weisen noch nie zuvor geträumt hatten. Programmierer und die Magier selbst änderten das System immer öfter. Zusätzliche Beine, Tentakel, zusätzliche Köpfe oder Schwänze wurden ihm angenäht. Langsam wurde es immer hässlicher, größer und nahm mehrere Kammern und Stockwerke des Schlosses ein. Bis es schließlich so riesig wurde, dass es fast nicht hineinpasste. Seine Schöpfer flohen aus dem Königreich, obwohl es auch Gerüchte gab, dass es das System war, das sie verschlang. Und das System wuchs weiter und verwandelte sich langsam in ein schreckliches Monster, das niemand mehr mochte und um das sich niemand mehr kümmerte.
Früher oder später wird jeder Programmierer in seiner Karriere auf ein Projekt stoßen, in dem er sich einem solchen Monster stellen muss.
Legacy-Code (vererbter oder veralteter Code), es ist Code, der seit einiger Zeit in der Produktion läuft. Erstellt von Personen, die in unserer Organisation nicht mehr präsent sind, oder von Drittunternehmen, die auf dem Markt nicht mehr existieren. Sehr oft enthält ein solcher Code keine Dokumentation, und die ursprünglichen Annahmen während seines Betriebs haben sich stark geändert. Aus verschiedenen Gründen finden wir darin auch keine Einheiten- oder Integrationstests, oder die zuvor geschriebenen Tests haben aufgrund zu vieler Änderungen und der Einführung zusätzlicher Abhängigkeiten ihre Gültigkeit verloren.
Eigentlich hassen alle Entwickler gerne Legacy-Code. Es ist nicht schön, es enthält keine modernen und „modischen“ Technologien, es erlaubt uns nicht, „kreativ“ zu arbeiten. Es ist jedoch wichtig, sich daran zu erinnern, dass jeder Code am Ende sowieso veraltet ist. Es ist ein bisschen wie beim menschlichen Körper. Es entwickelt sich, wird alt, und wenn wir uns nicht darum kümmern und es nicht in der richtigen Form halten, wird es irgendwann krank und mit der Zeit weigert es sich zu gehorchen. Also, wenn ein solcher Code schon anfangs wirklich gut entworfen und geschrieben war, kann er jetzt wie das berühmte Frankenstein-Monster aussehen, das aus Dutzenden von Stücken genäht wurde. Die Arbeit mit einem solchen Code muss trotz der vielen Schwierigkeiten, auf die wir stoßen werden, für den Programmierer überhaupt kein Fluch sein. Ein solches Projekt gibt uns die Möglichkeit, die Grundlagen der Programmierung zu erlernen, die richtigen Techniken anzuwenden, Muster zu entwerfen, sauberen Code zu schreiben und gute Tests durchzuführen.
Was ist zu tun? Wie soll man leben?
0.“Erem sie, Tittyrittes, stirb, Monster, du bist hässlich!“ (S. Lem Cyberiada)
Leider im Fall des Monsters lCodex Legacy Dieser Zauberspruch funktioniert selten. Die Versuchung ist jedoch groß: Ist es nicht besser, alles von Anfang an zu schreiben? Manchmal ja. Es muss sich jedoch immer um eine durchdachte Entscheidung handeln, die durch eine detaillierte Analyse gestützt wird. Ohne Kenntnis des Systems, seiner Funktionsweise und der Beziehungen zwischen den Funktionen ist es besser, diese Aufgabe nicht zu übernehmen. Und mit einem produktiv arbeitenden System ist es möglicherweise einfach nicht rentabel.
1. Befreunde dich mit dem Monster.
Um das alte Codesystem effektiv und sicher verwalten oder ändern zu können, müssen Sie wissen, wie es ordnungsgemäß funktioniert. Angesichts des oben genannten Mangels an Dokumentation und der im Laufe der Jahre hinzugefügten neuen Funktionen ist dies ein ziemlich schwieriger und zeitaufwändiger Prozess. Manchmal müssen Sie sich nur noch durch jede Methode oder Klasse „klicken“ und den Code Zeile für Zeile debuggen. Ganz effektiv ist in einem solchen Fall das sogenannte Umgestaltung von Kratzern, was auf sehr einfache Weise darin besteht, den Produktionscode in ein separates Projekt, eine Art Sandbox, zu kopieren. Dort wird dann ein Refactoring durchgeführt, Tests geschrieben, es wird geprüft, wie sich unser Monster verhält, wenn wir den einen oder anderen Tentakel abschneiden. Ein solches Refactoring ermöglicht es Ihnen, schnell und effizient die Beziehungen zwischen den Elementen des Systems zu erlernen, ohne das Risiko einzugehen, dass etwas im Produktionscode beschädigt wird. Das Wichtigste an dieser Methode ist jedoch, dass all diese Änderungen entfernt werden MÜSSEN. Natürlich kann und sollte das gewonnene Wissen genutzt werden! Ich weiß aus Erfahrung, dass es ohne zu wissen, wie der Code funktioniert, sehr einfach ist, eine Sache zu korrigieren und mehrere andere zu verderben.
2. Fantastische Haustiere und wie man sie pflegt.
Wenn Sie den vorhandenen Code lernen, während Sie alte Funktionen korrigieren oder neue Funktionen einführen, schreiben Sie auf, was Sie gelernt haben. Erstellen und aktualisieren Sie die Codedokumentation — selbst das kleinste Wissen kann sich in Zukunft als unschätzbar erweisen. Versuchen Sie auch, dieses Wissen nicht nur für sich selbst zu behalten. Denken Sie daran, dass die sogenannten“BUSFAKTOR“ in einem Projekt sollte immer größer als 1 sein. In einer etwas grausamen Übersetzung bezeichnet es die Anzahl der Teammitglieder, die „über den Bus gefahren“ werden müssen, damit das Projekt nicht fortgesetzt werden kann. Wenn in unserem Projekt also „Busfaktor“ = 1 ist, bedeutet das, dass ein zufälliger Unfall, eine Krankheit oder einfach die Entscheidung, eine Karriere außerhalb dieses Projekts einzuschlagen, nur ein Mitarbeiter dazu führt, dass niemand da ist, der unseren Monstercode beherrscht.
3. Schüttle das Monster, wann immer du kannst.
Testen heißt gewissermaßen, unser Biest zu zähmen. Tests zu schreiben und dabei selbst kleinste Änderungen mithilfe von TDD (Test Driven Development) vorzunehmen, wird irgendwann dazu führen, dass der Großteil des Codes in Tests behandelt wird und die Wartung und Implementierung nachfolgender Änderungen viel einfacher und sicherer sein wird. Darüber hinaus werden Sie durch das Schreiben von Tests in der Lage sein, die Funktionsweise des Codes besser zu verstehen. Dieser Ansatz sollte zur Gewohnheit werden und das erste, was Sie tun. Paradoxerweise gibt es Fälle, in denen der Grad der Komplexität des Codes so groß und unser Wissen über seine Funktionsweise so gering ist, dass es sehr schwierig ist, aussagekräftige Tests zu schreiben. Vielleicht ist das der richtige Ort, um eine bestimmte Funktionalität komplett neu zu schreiben?
4. Refactoring - Pflege des monströsen Codes.
Die eigentliche Struktur des Codes zu verbessern, sodass er verständlicher und kostengünstiger zu verwalten ist, ohne gleichzeitig seine Funktionsweise zu ändern, das heißt, genau gesagt, ein Refactoring, ist im Fall von monströsem Code das Äquivalent einer Haarbürste und eines Klauenschneiders. Wir müssen uns oft damit abfinden, dass nicht alle Ideen, auch die besten, sofort in die Praxis umgesetzt werden können. Aber manchmal können und sollten wir sogar kleine Änderungen an vorhandenem Code vornehmen, damit er jedes Mal in einem etwas besseren Zustand ist. Den Code so lassen, wie er ist, nach dem Prinzip: „So funktioniert es, sich nicht zu bewegen!“ , ist in diesem Fall keine gute Idee. Das sich ändernde Geschäftsmodell, die Standards oder Gesetze in einem bestimmten Land zwingen uns manchmal dazu, Änderungen in einem ziemlich breiten Spektrum vorzunehmen. Ein Beispiel dafür sind die Änderungen der Bestimmungen zum Schutz personenbezogener Daten (DSGVO), die es erforderlich gemacht haben, viele Systeme zu ändern, die diese Art von Daten verarbeiten. Versuchen Sie bei der Implementierung neuer Funktionen, den Code „sauber“ zu halten und ihn so zu belassen, wie er ist. Lassen Sie uns nicht noch mehr „Ungeheuerlichkeiten“ zu denen hinzufügen, die wir bereits haben! Zuallererst jedoch, wie der berühmte Per Anhalter durch die Galaxis rät — gerate nicht in Panik! Schließlich hat der Code, mit dem Sie es zu tun haben, manchmal sogar lange Zeit einwandfrei in der Produktion funktioniert. Und sag mir ehrlich, hast du dir schon einmal deinen eigenen Code angesehen, der vor ein paar Monaten geschrieben wurde, und dich entsetzt gefragt: „Wer hat ihn eigentlich geschrieben?!“ Anstatt dich also darüber zu beschweren, wie monströs der Code ist, mit dem du dich auseinandersetzen musst, versuche, ihn wirklich unterhaltsam zu machen, was übrigens eine Wissenschaft für die Zukunft sein wird. Jemand hat einmal gesagt, wenn du tust, was du willst, wirst du keinen Tag in deinem Leben arbeiten. Was für uns alle noch zu wünschen übrig bleibt.
