Legacy-Code ist Krebs

Ursprünglicher Autor: Bruno Skvorc
  • Übersetzung
Immer öfter sehe ich, dass die Leute sich vor der neuesten Technologie zurückhalten und sich für die Abwärtskompatibilität entscheiden. „Wir können die Mindestanforderungen für PHP nicht auf 5.5 erhöhen, da wir 50% der Benutzer auf anderen 5.4 haben“, heißt es. "Ein Upgrade auf ist nicht möglich. Guzzle 4+Wir haben ein Backend für Version 3, das zu lang und zu teuer ist." Und das beste Argument von WordPress: "Wir können nicht zu einem vollständigen OOP kommen, weil die meisten Benutzer auf Shared Hosting mit 5.1 sitzen oder nichts über MVC wissen."

Unsinn.

Legacy-Code ist ein großes NEIN


Vielleicht ist dies eine kontroverse Schlussfolgerung, aber ich bin fest davon überzeugt, dass in modernen Systemen kein Platz für Legacy-Code ist. Ich werde ein paar Worte sagen, bevor Sie anfangen, Ihre Heugabel zu schärfen und die Fackeln anzuzünden. Ich meine, es sollte nicht den geringsten Grund geben, die alte Funktionalität zu unterstützen. Sie fügen Aktualisierungen rückwirkend zur alten Version hinzu, nur weil einige Leute sie noch verwenden. Auch wenn die Mehrheit dieser Menschen - dies nicht tun.

Zur Klarstellung: Korrektur von Fehlern früherer Versionen, bis deren langfristiger Supportvertrag abgelaufen ist, ja. Hinzufügen neuer Funktionen, die in der Version freigegeben werden können X, in der Version X-1, nur um Benutzer nicht zu beleidigen X-1- absolut und 100% nicht. Ähnliches gilt für das HinzufügenX-1Code in Version X, nur weil er nützlich sein kann, sollte als ungültig betrachtet werden. Wenn Sie immer noch Leute dafür X-1bezahlen und Ihre Upgrades darauf aufbauen, dann haben Sie einen sehr schlechten Geschäftsplan.


Obwohl, wer bin ich, um solchen Unsinn zu tragen? Ich habe noch nie ein großes Projekt mit einer Reihe von Stakeholdern und Unterstützern unterstützt, das sich nur sehr langsam entwickelt und alle glücklich macht. Wie lange es dauert und wie es funktioniert, ist unwichtig, weil es möglicherweise 100-mal sicherer und 1000-mal schneller arbeiten kann, oder? Nicht wirklich. Mein größtes Kind war die Website eines großen Verlags mit einem ausgeklügelten Backend für ZF1.

Wenn Sie schon einmal Projekte durchgeführt habenZF1Wissen Sie, dieser Rahmen ist ein Wirbelwind aus Krücken und Anti-Mustern. Als die Anwendung aufgrund des erhöhten Datenverkehrs Anzeichen einer Verschlechterung aufwies, baute ich das Frontend des am häufigsten verwendeten Teils der Anwendung neu auf, um Ajax- und API-Aufrufe vollständig zu verarbeiten. Die Last ist stark gesunken und wir haben uns genug Zeit genommen, um alle anderen Teile der Anwendung zu übertragen Zend Framework 2. Diejenigen, die etwas Ähnliches gemacht haben, wissen, dass dies immer noch die gleiche Mischung aus Krücken und Anti-Mustern ist, aber etwas weniger dicht.

Ich versuche zu sagen, dass große Veränderungen und Umgestaltungen nur stattfinden können, wenn fähige Leute dahinter stehen. Wenn alles, was Sie tun, solide, agile Rallyes und Brainstorming-Sitzungen sind, kann keine Menge von LTS-Verträgen Sie davon abhalten, fünf Jahre lang albern auszusehen.

Selbst wenn Sie kostenlos und / oder Open Source arbeiten, sollten Sie die Kompatibilität für X-1-Benutzer nicht beeinträchtigen. Wenn Sie ihnen einen Gefallen tun und alte Versionen mit einem globalen Update entwickeln, kann dies zu einem Verlust der Abwärtskompatibilität führen. Lernen Sie nur eines - sie müssen sich entweder anpassen oder sterben.

Warum sollten wir also alten Code aus modernen Systemen verbannen?

Unendlicher LTS-Fluch


Wenn Sie sich dem Konzept "Alles unterstützen, solange wir können" anschließen, befinden Sie sich in einer Baugrube ohne Boden. Wenn Sie nach einigen Jahren gezwungen sind, vier verschiedene Versionen Ihres Produkts zu unterstützen, stoßen Sie Ihren Kopf an die Wand Das hat die Benutzer V1 und V2 nicht abgelehnt, wenn sie könnten. Bei dem Versuch, eine Zielgruppe zu halten, gehen Entwickler oft über ihre Möglichkeiten hinaus und werden dem Joch von Tonnen von Legacy-Code nicht gerecht. Aus dem gleichen Grund ist WordPress in seinem aktuellen Zustand gelandet. Lass dich nicht an die alte Version ketten.



Diese Benutzer sind ein Eigengewicht, sie müssen zerstört werden, egal wie viel Geld sie Ihnen bringen. Geben Sie ihnen die Gelegenheit, sich zu bewegen und weiterzumachen. Wenn sie dazu in der Lage sind, werden sie Sie einholen. Wenn nicht, dann sind sie es nicht wert.

Wenn Sie ältere Versionen zu lange unterstützen, üben Sie einen WP-Fluch auf sich selbst aus. Alte Versionen sind anfällig, ihre Unterstützung erfordert immer mehr Aufwand, um Fehler zu beheben. Verbringen Sie diese Stunden besser damit, neue Versionen zu erstellen und Entwickler einzustellen, die den Benutzern bei der Umstellung helfen.

Sie sind entfremdet und beeinträchtigen fortgeschrittene Benutzer


Das letzte Mal, als ich bei der InstallationCMS auf einen verzweifelten alten Code stieß , stellte sich heraus, dass dies eine sehr schwierige Aufgabe in der Umgebung war Vagrant- nicht nur aufgrund von Problemen symlink, die heute allen bekannt sind (sogar dem Ersteller Vagrant), sondern auch, weil viele Leute veraltete Versionen verlassen CMSweil Einige Module / Plugins haben ihre Updates noch nicht veröffentlicht. Warum sollte der Kernel aktualisiert werden, da es keine Modulaktualisierungen gibt? Warum hast du es eilig, wenn du nicht bereit dafür bist?

Wenn Sie den alten Code in der neuen Version belassen, haben Sie ein Frankenstein-Monster, das anscheinend funktioniert, aber schlecht funktioniert, und der neue Code, der Potenzial hat, kann ihn aufgrund eines Durcheinanders in der geerbten Codebasis nicht entwickeln. Dieser Ansatz erleichtert zwar die Arbeit von Entwicklungsunternehmen, die noch irgendwo in den 90er Jahren feststeckten, erschwert es jedoch gleichzeitig fortgeschrittenen Anwendern, mit dem Produkt zu arbeiten. Mit Entscheidungen, die für eine Menge getroffen wurden, die lange und hoffnungslos hinter der Technologie zurückgeblieben ist, entfremden Sie fortgeschrittene Benutzer und beeinflussen sie negativ, die viel Geld einbringen können.



Sie wissen, wie es passiert: Nehmen Sie sich zu viel Zeit, um Funktionen in älteren Browsern zu unterstützen. Infolgedessen verwendet keiner der Benutzer diese Funktionen. Gleiches gilt für Benutzer von Bibliotheken oder Inhaltsverwaltungssystemen. Wer sich nicht um veraltete Inhalte kümmert, kümmert CMSsich nicht darum, was Sie in neuen Versionen tun. Sorgen Sie sich also nicht mehr um die übermäßige Unterstützung älterer Versionen, als Sie wirklich benötigen.

Fehler sind manchmal ein Zeichen für Erfolg


Natürlich ist dies manchmal einfach nicht möglich, und solche Ausnahmen sind sehr seltenes und wertvolles Schulungsmaterial. Einer der interessanten Fälle der Versionierung ist 2nd und 3rd Python. Python ist eine erstaunliche Sprache, mit der Sie fast alles können. Aber es wird nicht so gut funktionieren wie eine Sprache, die speziell für Ihren Zweck entwickelt wurde. Dies ist ein häufiger Mangel von Sprachen, die alles beherrschen - sie können etwas sehr gut, aber es gibt keine Möglichkeit, die Arbeit mit ihnen zu erledigen einwandfrei. Als Python 3 ankam, wurden einige Funktionen eingeführt, die die Kompatibilität beeinträchtigten und bei denen Benutzer der 2. Version nicht mehr einfach darauf umsteigen konnten.

Die meisten Ausreden wie "Py3-Pakete sind immer noch nicht genug" und "Wir haben zu viel Code in Py2, um all dies umzuschreiben" lassen sich von mir beantworten - "portieren, was Sie brauchen" und "Arme Programmierer, sie sind gezwungen, Code zu schreiben". dementsprechend. Ich stimme zu, es gab mehrere Argumente , aber diese nehmen in der Regel ein Beispiel für Projekte, die ursprünglich falsch entworfen wurden, was zu ihrer absurd großen Größe führte.

Tatsächlich hat sich die Konfrontation von Py2 gegen Py3 bereits zu einer Pause entwickelt, auf beiden Seiten gibt es Programmierer. Aber viele denken nicht daran, dass Menschen, die sich so vehement geweigert haben, auf Version 3+ umzusteigen, bis Python 4 erscheint, auf Py2 bleiben und die Inkompatibilität noch größer wird. Zu diesem Zeitpunkt konnten sie bereits eine andere Sprache beherrschen und Änderungen in der aktuellen nicht widerstehen. Auf der anderen Seite erhalten diejenigen, die es "gewagt" haben, den Fehler zu überwinden und ihren Code ohne Bedenken auf 3+ umzuschreiben, die neuesten Funktionen zukünftiger Versionen ohne Lohnkosten.



Die Abwärtskompatibilität Schrott effektiv genug faul Fach und bereitete Python für eine neue Generation von Entwicklern. Meiner Meinung nach ist dies ein großer Erfolg. Wie in vielen anderen Bereichen des Lebens basiert das Programmieren immer noch auf dem Überleben der Stärkeren. Wenn Sie die neuen Technologien nicht angemessen einsetzen können, sollten Sie diejenigen, die dies können, nicht stören.

Anwendungen vs Bibliotheken / Pakete


Es gibt auch Fragen zur Konfrontation zwischen Anwendungen und Bibliotheken. Mit anderen Worten, wenn die Regel "Nicht verfallen" für Anwendungen gilt, z. B. wenn eine neue Version eines Frameworks eingeht, sollte sie auch für Bibliotheken gelten?



Ja

Bibliotheken, die eine Unebenheit erhalten, X+1sollten eindeutig dem Fortschritt folgen - ab dem Moment, in dem Ihre Version der Bibliothek öffentlich verfügbar ist, unterstützen Sie nur die Fehlerkorrekturen der letzteren.

Anwendungen, die solche Bibliotheken verwenden, sind aufgrund ihrer Abhängigkeit von der API in einer schwierigeren Situation, die Änderungen unterliegen kann. Ein vernünftiger Ansatz wäre es, vor Beginn des Übergangs auf das Feedback der Community zur Stabilität zu warten. Während der Übergangszeit können sowohl die alte als auch die neue Version der Bibliothek / des Frameworks weiterhin verwendet werden. Nachdem alle erforderlichen Teile aktualisiert wurden, muss die alte Version gelöscht werden. Es dauert nicht lange, oder?

Es gibt keine ausreichend große Bewerbung


"Aber Bruno, einige Anwendungen sind riesig und es wird einige Monate dauern, bis sie neu geschrieben sind", sagen Sie. „Der Übergang von ZF1 zu ZF2 ist ein Jahr der Arbeit!“, Worauf ich antworte: Unsinn. Es gibt keine ausreichend große Webanwendung, für deren Aktualisierung ähnliche Bedingungen gelten. Ich werde noch weiter gehen und sagen, dass es tatsächlich keine Webanwendungen gibt, die groß genug sind, um mit Symfony oder Zend vergleichbar zu sein.

Natürlich trifft alles, was ich sagte, auf keines dieser Frameworks zu, es sind hyperkomplexe Hippos aus einem sehr professionellen Code, aber wenn Sie dem Konzept der Aufgabentrennung folgen, Ihre Services und APIs in Ihre Anwendung einschließen, können Sie das Frontend separat vom Backend schreiben Dies befreit Sie unabhängig von der Größe und / oder Popularität der Anwendung von zahlreichen Hindernissen für den aktuellen Code - vorausgesetzt, Sie haben Programmierer in Ihrem Team, keine Theoretiker. Egal wie viele Strukturen und Algorithmen Sie kennen, die Hauptsache ist, dass Sie wissen, wie Sie sie verwenden, um bei Migrationen effektiv genug zu sein.

Schema aktualisieren


Was ist der beste Weg, um zu aktualisieren? Es gibt nur eine akzeptable Option für Software-Updates, die Entwickler unabhängig von der Popularität ihrer Anwendung / Bibliothek einhalten sollten:

  1. Erstellen Sie einen neuen Zweig für die neue Version
  2. Alte Version / Zweig als veraltet markieren
  3. Geben Sie öffentlich an, um wie viel mehr Sie die alte Version unterstützen werden
  4. Warnen Sie alle Benutzer der alten Version
  5. Implementieren Sie neue Funktionen NUR im neuen Zweig, in den alten One-Bug-Fixes
  6. Wenn die Lebensdauer der alten Version abläuft, brechen Sie alle Enden ab. Korrigieren Sie nicht, raten Sie nicht, entfernen Sie im Allgemeinen die Erwähnung der alten Version aus der Dokumentation. Töte sie.

Nach Abschluss dieses Vorgangs erben Sie keine Probleme mehr.

Eines der Projekte, die diesem Weg folgen, ist Guzzle . Er hat eine 3+ Version und 4+ für diejenigen, die auf dem neuesten Stand sein und immer auf dem Höhepunkt des Fortschritts sein wollen.

Fazit


Als Webentwickler bin ich fest davon überzeugt, dass Legacy-Code weggeworfen werden sollte, wenn es um neue Funktionen oder größere Versions-Upgrades geht. Wenn Sie ein großes Projekt haben, das den vor zwei oder mehr Monaten veröffentlichten Versionscode verwendet, sollten Sie alle Aktivitäten damit beenden und es mit einer neuen Version überschreiben, insbesondere wenn die von Ihnen verwendeten Produkte für das Geschäft von entscheidender Bedeutung sind. Es gibt weltweit keine ausreichend großen Anwendungen, die mehr als zwei Monate benötigen, um die Umstellung abzuschließen. In diesem Fall sollten sie von Grund auf neu geschrieben werden. Das Web ist viel einfacher als erwartet.

Was denkst du? Sollte Legacy-Code auf unbestimmte Zeit gespeichert werden? Eine bestimmte Anzahl von Versionen? Vielleicht nicht alles? Wie stehen Sie zu Legacy-Code in Projekten von Drittanbietern? Sollte sich ein Entwickler über ältere Probleme in den von ihm verwendeten Bibliotheken Gedanken machen? Irre ich mich in diesem Artikel Mit diesem Beitrag wollte ich eine Diskussion darüber beginnen - schließlich sind meine Ansichten zu Problemen und Erfahrungen nur meine Ansichten. Lass es mich in den Kommentaren unten wissen.

Jetzt auch beliebt: