| Bevor Sie etwas unternehmen, sollten Sie alle relevanten Daten sichern, damit keine Daten verloren gehen, egal was passiert. Es ist schwierig, sich daran zu erinnern, was jeden Tag geändert wird. Insbesondere Konfigurationsdaten sind anfällig für diese Art von Problemen. Die Konfiguration unterliegt normalerweise keiner Versionskontrolle. Wenn Sie regelmäßige Sicherungen durchführen können, können Sie viele Probleme vermeiden. Kopieren Sie alles an einen sehr sicheren Ort, den Sie niemals berühren, es sei denn, es befindet sich im schreibgeschützten Modus. |
Es passiert mindestens einmal im Leben eines jeden Programmierers, Projektmanagers oder Teamleiters: Sie erben ein System mit über einer Million Codezeilen, und der ursprüngliche Programmierer hat das Unternehmen vor langer Zeit verlassen und ist wahrscheinlich an einem sonnigen Ort im Urlaub. Die Dokumentation ( (sofern vorhanden) höchstwahrscheinlich nicht mit dem vorhandenen System synchronisiert ist.
Und Ihre Aufgabe ist es, das Team aus diesem Schlamassel herauszuführen.
Nachdem Sie die instinktive Reaktion des Weglaufens erlebt haben, beginnen Sie, das Projekt zu verstehen, und die Geschäftsleitung des Unternehmens wird das Scheitern des Projekts nicht tolerieren. Mit dem, was Sie zur Hand haben, ist ein Scheitern jedoch ein Ereignis mit hoher Wahrscheinlichkeit. Wie also damit umgehen?
Ich hatte das Glück (oder das Pech), mehrere ähnliche Erfahrungen gemacht zu haben, und eine kleine Gruppe von Freunden und ich haben herausgefunden, dass es sich tatsächlich sehr lohnt, diesen Junk-Code in ein gesundes und wartbares Projekt umzuwandeln. Hier sind einige Erfahrungen (oder militärische Regeln), die wir zusammengefasst haben, um die Legacy-Codebasis zu verbessern.
1. Datensicherung
Bevor Sie etwas unternehmen, sollten Sie alle relevanten Daten sichern, damit keine Daten verloren gehen, egal was passiert. Es ist schwierig, sich daran zu erinnern, was jeden Tag geändert wird. Insbesondere Konfigurationsdaten sind anfällig für diese Art von Problemen. Die Konfiguration unterliegt normalerweise keiner Versionskontrolle. Wenn Sie regelmäßige Sicherungen durchführen können, können Sie viele Probleme vermeiden. Kopieren Sie alles an einen sehr sicheren Ort, den Sie niemals berühren, es sei denn, es befindet sich im schreibgeschützten Modus.
2. Wichtige Voraussetzungen zum Aufbau einer echten Simulationsumgebung
Ich habe diesen Schritt in meinem vorherigen Beitrag übersehen, weil ich davon ausging, dass diese Umgebung bereits existierte, aber viele HN-Leute haben darauf hingewiesen und sie hatten absolut Recht.
Der erste Schritt besteht darin, sicherzustellen, dass Sie wissen, was gerade in der Produktion läuft. Das bedeutet, dass Sie in der Lage sein müssen, eine Version der Software zu erstellen – die mit Ihrer realen Umgebung konsistent ist – also mit derselben Softwareumgebung wie die Binärversion .
Wenn Sie dazu keine Möglichkeit finden, könnten Sie böse Überraschungen erleben, wenn Sie Ihren Code in die Produktion überführen. Stellen Sie sicher, dass neuer Code so weit wie möglich in der richtigen Umgebung getestet wird, bevor Sie sicher genug sind, ihn in die Produktion zu übernehmen. Wenn Sie online gehen, müssen Sie jederzeit darauf vorbereitet sein, zum alten Code zurückzukehren, und stellen Sie sicher, dass relevante wichtige Inhalte im Protokoll aufgezeichnet werden, damit sie bei der späteren Fehlerbehebung nützlich sein können.
3. DB-Änderung einfrieren
Frieren Sie Datenbankänderungen so weit wie möglich ein, bis die erste Phase der Verbesserung abgeschlossen ist, bis das Team ein umfassendes Verständnis der Codebasis hat und der Legacy-Code aufgegeben wurde, bevor Sie eine Änderung der Datenbankstruktur in Betracht ziehen. Jede Datenbankänderung vor diesem Zeitpunkt kann zu schwerwiegenden Problemen führen und Sie verlieren die Möglichkeit, das alte System und die neue Codebasis nebeneinander auszuführen. Wenn Sie die Datenbank völlig unverändert lassen, können Sie den neuen Geschäftslogikcode mit dem alten Geschäftslogikcode vergleichen. Wenn alles wie erwartet funktioniert, sollte es überhaupt keinen Unterschied geben.
4. Schreiben Sie Tests
Bevor Sie Änderungen vornehmen, schreiben Sie so viele End-to-End- und Integrationstests wie möglich, um sicherzustellen, dass diese Tests die richtige Ausgabe liefern und alle potenziellen Fälle abdecken.
Diese Tests haben zwei wichtige Funktionen: Zum einen helfen sie dabei, etwaige Missverständnisse frühzeitig auszuräumen. Zum anderen schützen diese Tests Ihr System besser, sobald Sie mit dem Schreiben von neuem Code beginnen, um alten Code zu ersetzen.
Automatisieren Sie alle Ihre Tests, verwenden Sie es so schnell wie möglich, wenn Sie bereits Erfahrung mit CI haben, und stellen Sie sicher, dass Ihre Tests schnell genug ausgeführt werden, um nach jedem Commit die gesamte Testsuite auszuführen.
5. Instrumentierung und Protokolle
Wenn die alte Plattform die Instrumentierung noch erhöhen kann, tun Sie dies in einer brandneuen Datenbanktabelle, fügen Sie einen einfachen Zähler für jedes erdenkliche Ereignis hinzu und fügen Sie dazu eine einzelne Funktion hinzu, um diese Zähler basierend auf dem Namen des Ereignisses zu erhöhen .
Auf diese Weise können Sie mit ein paar zusätzlichen Codezeilen ein Ereignisprotokoll mit Zeitstempel implementieren und erfahren, wie viele Ereignisse zu einer Art von Ereignis führen. Ein Beispiel: Benutzer öffnet die App, Benutzer schließt die App. Sollten zwei Ereignisse zu einigen Backend-Anfragen führen, sollten diese beiden Zähler langfristig konstant bleiben, wobei die Differenz die Anzahl der aktuell geöffneten Anwendungen darstellt. Wenn mehr Apps geöffnet als geschlossen werden, wissen Sie, dass es eine andere Möglichkeit geben muss, die App zu beenden (z. B. einen Absturz).
Dieser einfache Trick verwandelt jede Backend-Anwendung in eine Art Buchhaltungssystem, bei dem wie bei einem echten Buchhaltungssystem alle Zahlen übereinstimmen müssen, um sicherzustellen, dass sie überall, wo sie verwendet werden, in Ordnung sind.
Im Laufe der Zeit wird dieses System für die Überwachung von Gesundheitsaspekten von unschätzbarem Wert sein und ein hervorragender Begleiter für das Änderungsprotokoll Ihres Quellcodeverwaltungssystems sein, in dem Sie den Zeitpunkt identifizieren können, zu dem jeder Fehler eingeführt wurde, und Änderungen an verschiedenen Änderungen vornehmen können die Situation.
Normalerweise behalte ich diese Zähler mit einer Auflösung von 5 Minuten (also 12 Protokollen pro Stunde), aber Sie müssen dieses Intervall möglicherweise ändern, wenn Ihr System weniger oder mehr Ereignisse hat. Alle Zähler verwenden dieselbe Datenbanktabelle, sodass jeder Zähler nur eine Spalte in dieser Tabelle ist.
6. Ändern Sie jeweils nur einen Punkt
Wenn Sie neue Funktionen hinzufügen oder Fehler beheben, tappen Sie nicht in die Falle, gleichzeitig Ihren Code zu verbessern und die Plattform zu ändern, auf der er läuft. Dies kann viele Kopfschmerzen verursachen.
7. Plattformänderungen
Wenn Sie sich entscheiden, Ihre Anwendung auf eine andere Plattform zu migrieren, tun Sie dies zuerst, aber sorgen Sie dafür, dass alles genauso funktioniert. Sie können weitere Dokumentation oder Tests hinzufügen, aber nicht über diesen Punkt hinaus sollten alle Geschäftslogiken und gegenseitigen Abhängigkeiten unverändert bleiben.
8. Architekturänderungen
Als nächstes müssen Sie die Architektur der Anwendung ändern (falls erforderlich). An dieser Stelle steht es Ihnen frei, die Struktur des Codes auf höherer Ebene zu ändern, in der Regel durch Reduzierung der Anzahl horizontaler Links zwischen Modulen, wodurch der Umfang der Codeaktivität für jegliche Interaktion mit dem Endbenutzer verringert wird. Wenn der alte Code monolithischer Natur wäre, wäre jetzt ein guter Zeitpunkt, ihn modularer zu gestalten und große Funktionen in kleinere aufzuteilen, aber die Namen von Variablen und Datenstrukturen beizubehalten.
HN-Internetnutzer Mannykannot wies darauf hin, dass Architekturänderungen nicht immer machbar seien und dass man, wenn man besonders viel Pech habe, möglicherweise ein sehr tiefes Verständnis des Codes benötige, um Architekturänderungen vorzunehmen. Ich stimme dem zu und mache daher eine kleine Ergänzung: Wenn Sie sowohl Änderungen auf hoher als auch auf niedriger Ebene vornehmen, müssen Sie diese auf mindestens eine Datei oder im schlimmsten Fall auf ein Subsystem beschränken, um die Änderungen zu begrenzen möglichst viel Reichweite. Andernfalls könnte es schwierig werden, die gerade vorgenommenen Änderungen zu debuggen.
9. Low-Level-Refactoring
Inzwischen sollten Sie ein gutes Verständnis dafür haben, was jedes Modul tut, und für die eigentliche Arbeit bereit sein: den Code umgestalten, um die Wartbarkeit zu verbessern und ihm die Möglichkeit zu geben, neue Funktionen zu erweitern. Dies ist wahrscheinlich der zeitaufwändigste Teil des Projekts, und die Dokumentation muss dazugehören. Ändern Sie ein Modul erst, wenn Sie die Dokumentationseinleitung vollständig geschrieben und ein Modul gründlich verstanden haben.
In dieser Phase können auch Variablen- und Funktionsnamen sowie Datenstrukturen geändert werden, um die Klarheit und Konsistenz des Codes zu verbessern. Denken Sie daran, relevante Testcodes hinzuzufügen (Komponententests können nach Bedarf durchgeführt werden).
10. Beheben Sie Fehler
Da Sie nun bereit sind, einige für den Endbenutzer sichtbare Änderungen vorzunehmen, müssen Sie zunächst die Fehler beheben, die sich im Laufe der Jahre in der Warteschlange angesammelt haben. Bestätigen Sie wie üblich zunächst, dass der Fehler noch vorhanden ist, schreiben Sie dann einen Test und beheben Sie den Fehler. Ihre kontinuierliche Integration und Ihre End-to-End-Tests sollten Ihnen helfen, Fehler und periphere Probleme aufgrund von Unverständnis oder Fehlern zu vermeiden.
11. Datenbank-Upgrade
Wenn die oben genannten Arbeiten durchgeführt wurden, verfügen Sie wieder über eine zuverlässige und wartbare Codebasis. Sie können das Datenbankschema ändern oder sogar die Datenbank ersetzen. Alle oben genannten Arbeiten werden Ihnen dabei helfen, mühelos Änderungen vorzunehmen, ohne Angst vor Überraschungen haben zu müssen. Sie können die neue Datenbank mit dem neuen Code und allen Tests testen, um sicherzustellen, dass mit Ihrer Datenbank nichts falsch ist Migration.
auf der Roadmap vorankommen
Herzlichen Glückwunsch, an diesem Punkt haben Sie den Dschungel hinter sich und sind nun bereit, alle neuen Funktionen zu implementieren.
Versuchen Sie nicht, den Text komplett neu zu schreiben
Eine vollständige Neufassung ist die Art von Projekt, bei der ein Scheitern fast garantiert ist. Einerseits betreten Sie Neuland und wissen nicht einmal, was Sie umgestalten sollen, andererseits schieben Sie auch alle Probleme auf den letzten Tag, den Tag bevor Sie mit dem Neuen live gehen System. Tragischerweise ist das auch der Fall, wenn man scheitert. Annahmen zur Geschäftslogik werden sich irgendwann als problematisch erweisen. An diesem Punkt werden Sie plötzlich verstehen, warum das alte System auf seltsame Weise funktioniert, und schließlich erkennen, dass nicht alle Leute, die das alte System zum Laufen gebracht haben, Idioten sind. Wenn Sie das Unternehmen (und Ihren eigenen Ruf) wirklich ins Wanken bringen wollen, sollten Sie sich für eine komplette Neufassung entscheiden. Wenn Sie jedoch schlau genug sind, kommt eine komplette Neufassung des Systems normalerweise nicht in Frage.
Alternative: Iterative Verbesserung
Der schnellste Weg, diese Zusammenhänge zu entwirren, besteht darin, mit Code zu beginnen, den Sie bereits verstehen (es könnte sich um ein Peripheriegerät, aber auch um ein Kernmodul handeln) und zu versuchen, sich innerhalb der Grenzen seines alten Kontexts schrittweise zu verbessern.
Wenn die alten Build-Tools nicht mehr verfügbar sind, müssen Sie einige Tricks anwenden (siehe unten), aber zumindest das alte System so weit wie möglich funktionsfähig halten, während Sie mit der Umstellung beginnen. Ein typischer Commit enthält normalerweise nur wenige Codezeilen.
freigeben!
Alle Änderungen werden so weit wie möglich für die Produktionsumgebung freigegeben, auch wenn der geänderte Code für Endbenutzer unsichtbar ist, denn wenn Sie nicht genug über das System wissen, wird Ihnen nur die Produktionsumgebung sagen, wo die neue Änderung Probleme hat. Tritt dieses Problem erst nach einer kleinen Änderung auf, haben Sie gleich mehrere Vorteile:
Es ist leicht herauszufinden, was falsch ist
Sie sind in der Lage, den Prozess zu verbessern
Sie sollten Ihre Dokumentation umgehend aktualisieren, um neue Erkenntnisse zu dokumentieren
Verwenden Sie Proxyserver ordnungsgemäß
Wenn Sie ein Websystem umgestalten, können Sie Gott sei Dank einen Proxyserver zwischen den Endbenutzern und dem Altsystem bereitstellen. Sie können genau steuern, welche Anfragen für jede URL an das alte System gehen und welche an das neue System weitergeleitet werden, wodurch die Steuerung der Ausführung einfacher und detaillierter wird.
Wenn Ihr Proxy leistungsstark genug ist, können Sie sogar steuern, dass ein bestimmter Prozentsatz des URL-Verkehrs an das neue System gesendet wird, sodass Sie das neue System in Aktion beobachten können. Es wäre schön, wenn Ihre Integrationstests auch eine Verbindung zu diesem Proxy herstellen könnten.
Macht Sinn, aber das alles nimmt zu viel Zeit in Anspruch!
Nun, das hängt davon ab, wie man es betrachtet. Es ist eine Menge Arbeit, wenn Sie diese Schritte befolgen, aber es funktioniert, und alle Optimierungen des Prozesses verschaffen Ihnen ein tiefergehendes Verständnis des Gesamtsystems. Ich persönlich habe auch hier einen hervorragenden Ruf und möchte mit einem solchen Job wirklich keine negativen Probleme haben.
Wenn es manchmal bereits ein Problem mit dem Unternehmenssystem gibt, das sich möglicherweise auf Kunden auswirkt und die Befolgung dieses Prozesses die Dinge verbessern könnte, wäre es mir lieber, die volle Kontrolle und Nutzung dieses Prozesses zu haben, als auf oberflächliche Weise Tage oder Wochen einzusparen. Wenn Sie bei der Vorgehensweise eher eine Art Cowboy sind und Ihr Chef zustimmt – dann ist das vielleicht ein akzeptabler, risikoreicher Ansatz, aber die meisten Unternehmen würden lieber den etwas langsameren, robusteren Weg des Refactorings wählen.