it-swarm-eu.dev

Wann ist Code "Legacy"?

Wir haben es alle geschafft, wir haben Code (oft Dinge, die wir geerbt haben) als "Vermächtnis" bezeichnet? Aber es wird immer noch in den Produktionssystemen verwendet - ist es also wirklich ein Vermächtnis? Und was macht es zum Vermächtnis? Sollten wir uns vor dieser ungerechtfertigten Kennzeichnung von perfekt funktionierendem Code scheuen? Wo ist die Kennzeichnung eine reine Überzeugung, die es uns ermöglicht, neue Dinge durchzusetzen und das obere Management schön und glücklich zu halten?


Zusammenfassung der Antworten

Wenn ich die Antworten durchschaue, sehe ich vier allgemeine Themen. Hier ist, wie ich die Aufschlüsselung sehe:

  1. Jeder Code, der geliefert wurde: 6
  2. Tote Systeme: 2.5
  3. Keine Unit-Tests: 2
  4. Entwickler gibt es nicht: 1.5
64
Nim

Ich bin ziemlich parteiisch gegenüber Wikipedia-Zusammenfassung mir selbst:

Ein Legacy-System ist eine alte Methode, Technologie, ein Computersystem oder ein Anwendungsprogramm, das weiterhin verwendet wird, normalerweise, weil es immer noch für die Bedürfnisse der Benutzer funktioniert, obwohl jetzt neuere Technologien oder effizientere Methoden zur Ausführung einer Aufgabe verfügbar sind.

Vieles, was andere Leute in ihren Antworten beschreiben, ist Gründe warum Code zu "Vermächtnis" wird. Die wesentliche Frage selbst lautet jedoch:

Aber es wird immer noch in den Produktionssystemen verwendet - ist es also wirklich ein Vermächtnis? Und was macht es zum Vermächtnis?

Die Tatsache, dass es immer noch in der Produktion verwendet wird , macht es zu einem Vermächtnis . Wenn der Code nicht ordnungsgemäß funktioniert oder nicht mehr in der Produktion verwendet wird, ist dieser Code "defekt" bzw. "im Ruhestand". Legacy bedeutet, dass es noch verwendet wird und einwandfrei funktioniert, jedoch Designs oder Techniken enthält, die nicht mehr gebräuchlich sind.

Jeder Code oder jedes System, das Sie entweder (a) aktualisieren/aktualisieren möchten, aber nicht können oder (b) sich noch im Upgrade befinden, ist ein Legacy-System. Dies bedeutet nicht Refactoring oder allgemeine Codebereinigung, sondern signifikant Änderungen am Design, möglicherweise unter Verwendung eines neuen Frameworks oder sogar einer neuen Plattform.

Es gibt eine Reihe von Gründen, warum Systeme oder Code werden Legacy:

  • Mangel an regelmäßiger Wartung oder Software rot . Wenn die Anwendung nicht regelmäßig gewartet wird, kann sie natürlich nicht mit den wichtigsten Änderungen in der Software-Welt Schritt halten. Dies kann auf einfache Vernachlässigung zurückzuführen sein oder auf bewusste Entscheidungen, die auf geschäftlichen Prioritäten oder Budgetbeschränkungen beruhen.

  • Fehlende Tests. Eine andere Antwort verweist auf die hyperbolische Behauptung eines populären Autors, dass Code, der nicht durch Tests abgedeckt wird, Legacy-Code ist. Dies ist wirklich keine genaue Definition, aber ist eine mögliche Grundursache; Ohne gute Tests (automatisiert oder manuell) werden Entwickler schüchtern und haben Angst, größere Änderungen vorzunehmen, weil sie sich Sorgen machen, etwas zu beschädigen, was zu der oben genannten "Software-Fäulnis" führt.

  • Rev-Locking, ein oft übersehener Faktor, der in Projekten mit großen Open-Source-Bibliotheken oder Frameworks besonders heimtückisch ist (obwohl ich gesehen habe, dass dies auch bei kommerziellen Tools der Fall ist). Oft werden umfangreiche Anpassungen am Framework/der Bibliothek vorgenommen, was ein Upgrade unerschwinglich schwierig oder teuer macht. Somit wird das System zum Legacy, da es auf einer älteren (und möglicherweise nicht mehr unterstützten) Plattform ausgeführt wird.

  • Der Quellcode ist nicht mehr verfügbar, dh das System kann immer nur hinzugefügt, nie geändert werden. Da diese Systeme neu geschrieben werden müssen, um ein Upgrade durchzuführen - im Gegensatz zu einer schrittweisen/iterativen Überarbeitung -, werden sich viele Unternehmen nicht darum kümmern.

Alles, was Aktualisierungen einer Codebasis verlangsamt oder stoppt, kann dazu führen, dass diese Codebasis zum Legacy wird.

Nun lautet die separate, nicht angegebene, aber implizite Frage: Was ist los mit Legacy-Code ? Sie wird oft als abwertender Begriff verwendet, daher die Frage:

Sollten wir uns vor dieser ungerechtfertigten Kennzeichnung von perfekt funktionierendem Code scheuen?

Und die Antwort ist nein, wir sollten nicht; Die Kennzeichnung ist ist gerechtfertigt und der Begriff selbst impliziert eindeutig funktionierenden Code. Der Punkt ist nicht das es ist Funktion, sondern wie es funktioniert.

In einigen Fällen ist an Legacy-Code nichts auszusetzen. Es ist kein schlechtes Wort. Legacy-Code/Systeme sind nicht böse. Sie haben gerade etwas Staub gesammelt - manchmal ein wenig, manchmal viel.

Legacy wird veraltet wenn das System nicht mehr (alle) Anforderungen des Kunden erfüllen kann. Das Label ist eines, auf das wir achten müssen. Ansonsten ist es einfach eine Kosten-Nutzen-Gleichung. Wenn die Kosten für das Upgrade niedriger wären als die Kosten für die Vorteile (einschließlich niedrigerer zukünftiger Wartungskosten), lassen Sie das Upgrade ansonsten in Ruhe. Sie müssen das Wort "Vermächtnis" nicht in demselben Ton ausspucken, den Sie normalerweise für "Steuerprüfung" reservieren. Es ist eine vollkommen in Ordnung, in einer Situation zu sein.

43
Aaronaught

Normalerweise bedeutet dies, dass es in einer Sprache geschrieben ist oder auf einem System basiert, in dem Sie normalerweise keine Neuentwicklung durchführen.

Zum Beispiel schreiben die meisten Orte keine neuen Programme in Cobol. Ein großer Teil ihres Geschäfts läuft jedoch möglicherweise mit in Cobol geschriebenen Apps. Daher werden diese Apps als "Legacy" bezeichnet.

40
CaffGeek

Legacy bedeutet, dass jeder Code, den Sie lieber ersetzen als bearbeiten möchten. Angesichts der Einstellung der meisten Programmierer zu den meisten vorhandenen Codes umfasst dies normalerweise fast alles außer dem, was Sie gerade aktiv schreiben (und bei einem großen Projekt, bei dem Sie in ein eingefrorenes Design codieren müssen, sogar das, was Sie im Code schreiben Moment kann auch enthalten sein).

  1. Die Betonung "eher" soll vermitteln, dass Legacy-Code auch bedeutet, dass Sie nicht mehr damit arbeiten können, obwohl Sie dies lieber nicht möchten. Ich bin mir nicht sicher, ob die Betonung ausreichend war. Gründe dafür können variieren. Einige sind wirklich zu groß und komplex, um sie zu ersetzen. Andere sind Schnittstellen zu anderen Systemen. Wieder andere werden von Politik und Persönlichkeiten angetrieben (zum Beispiel ist der Code schrecklich, aber das Standbaby war unglaublich).
  2. Ein weiterer Punkt, den ich möglicherweise nicht ausreichend hervorgehoben habe, ist, dass die Codequalität zwar ein Faktor sein kann, aber selten (wenn überhaupt) der einzige Faktor ist - und oft nicht einmal ein besonders wichtiger.
  3. Ich denke, die Leute, die nit-Tests als einzigen bestimmenden Faktor drücken, sind wie der Typ, der unter der Straßenlaterne nach dem Ohrring sucht, den seine Frau einen Block entfernt hat. Das Licht mag besser sein, aber Sie suchen immer noch am falschen Ort. Denken Sie nach, bevor Sie trinken Sie die Kool-Aid .
  4. (Eine Folge von 3.) Es scheint mir, dass einige Leute mehr darüber sprechen, wie sie sich wünschen, dass die Dinge so sind, wie sie wirklich sind. Wenn John Conways ' Spiel des Lebens für ein Apple IIc Plus kein Vermächtnis ist, liegt es daran, dass es so klein und einfach ist, dass es leicht wieder hergestellt werden kann -Umsatz von Grund auf. Der perfekteste Unit-Test, der jemals geschrieben wurde, ändert nichts an einem einzigen iota .

Der letzte Punkt führt zu zwei weiteren Punkten, von denen ich denke, dass sie oft wahr sind.

Erstens wird Code oft als Vermächtnis beibehalten, auch wenn dies eigentlich nicht der Fall sein sollte. Übergeordnete Manager gehen im Allgemeinen davon aus, dass die Neuimplementierung eines Systems genauso viel oder mehr kostet als die ursprüngliche Implementierung, was selten der Fall ist.

Zweitens sind Unit-Tests ein zweischneidiges Schwert. Sie machen es allzu leicht zu glauben, dass lokalisierte Änderungen in der Implementierung wirklich wichtig sind. Um in einem größeren System signifikante Verbesserungen zu erzielen, müssen Sie häufig (normalerweise?) Das Gesamtdesign so stark ändern, dass viele (wenn nicht die meisten) Unit-Tests irrelevant werden. Leider kann das Vorhandensein von Komponententests und die daraus resultierende Einstellung es allzu leicht machen, die wirklich notwendigen Änderungen zu ignorieren.

Vielleicht würde ein Beispiel dafür helfen: Nehmen wir an, ein Programm hat eine UI Bibliothek mit großartigen Unit-Tests und mehrere Programme, die diese Bibliothek verwenden. Jemand im oberen Management ist davon überzeugt, dass "webfähig" wichtig ist (und nehmen wir aus Gründen der Argumentation an, dass er in diesem Fall tatsächlich Recht hat). Nach sorgfältiger Prüfung stellen die mittleren Manager fest, dass ihre aktuellen Komponententests ausreichen, um von einer Benutzeroberfläche, die über die Fensterfunktion des lokalen Betriebssystems angezeigt wird, zu einer Remote-Anzeige über HTML/CSS/AJAX zu wechseln, wobei die gesamte ursprüngliche Eingabevalidierung beibehalten wird.

Das ist großartig, nicht wahr? Es zeigt, wie nützlich Unit-Tests sein können. Wir haben die gesamte Implementierung der gesamten Benutzeroberfläche ausgetauscht, aber sichergestellt, dass das Erscheinungsbild und die Funktionalität praktisch konsistent bleiben und alle Benutzereingaben validiert werden, um die Datenintegrität sicherzustellen. Unit-Tests haben den Tag gerettet!

Oder nicht! Diese großartige, hochflexible, sorgfältig auf Einheiten getestete UI-Bibliothek hat dazu beigetragen, dass alle Beteiligten blind wurden, dass für dieses Programm auf dem Markt mit seinen Benutzern eine webbasierte Benutzeroberfläche völlig falsch ist. Was wirklich benötigt wird, ist ein Webdienst mit einer RESTful Schnittstelle und einer absoluten überhaupt keine Benutzeroberfläche.

Nun ist es sicher richtig, dass Unit-Tests an und für sich nicht die Fähigkeit der Menschen beeinträchtigen, ihren Markt zu verstehen oder zu erkennen, dass dies wirklich notwendig ist. Gleichzeitig fällt mir die alte Linie über Hämmer und Nägel praktisch ein. Es kann noch schlimmer sein, wenn Sie nicht nur einen Hammer haben, sondern auch viel Erfahrung mit diesem Hammer haben und wissen, dass es so ist Ein wirklich hochwertiger Hammer, der in vielen verschiedenen Situationen unglaublich gut funktioniert. Die Tatsache, dass es in so vielen Situationen so gut in so vielen Dingen ist, macht es noch schwieriger zu erkennen, wann es das völlig falsche Werkzeug für den jeweiligen Job ist.

28
Jerry Coffin

Legacy-Code ist normalerweise in irgendeiner Weise verwaist. Der Hauptentwickler, der einzige, der es verstand, wurde von einem Bus angefahren, und seine Notizen wurden in seiner ukrainischen Muttersprache geschrieben, die heute eine tote Sprache ist. Oder alternativ alles, was in Visual Basic 6.0 geschrieben ist.

Ich arbeite die ganze Zeit an Legacy-Code. Ich würde sagen, die Eigenschaften sind:

  • Es kann nicht ohne großen Aufwand erweitert werden
  • Es kann nicht einfach auf neue Hardware migriert werden
  • Es ist zu geschäftskritisch, um leicht ersetzt zu werden

Wenn es diese Eigenschaften nicht hat, dann ist es wahrscheinlich kein Vermächtnis. Wenn Sie die Perl-Skripte Ihrer Vorgänger nicht mögen, sympathisiere ich, aber ich denke nicht, dass es ein Vermächtnis ist. Ich habe kürzlich ein 15 Jahre altes Perl-Skript modernisiert, das mit einer veralteten Sybase-Datenbank verbunden war. Das war ein Kinderspiel im Vergleich zu der kleinsten Änderung an unserem gottesfürchtigen [~ # ~] Cobol [~ # ~] Buchhaltungssystem.

17
Satanicpuppy

In seinem Buch Effektiv mit Legacy-Code arbeiten definiert Michael Feathers Legacy-Code als Code, der nicht mit Komponententests behandelt wird. Das ist eine Definition, der ich zustimme. Ich sehe Legacy-Code auch als alt und dennoch verwendbar an.

12
Grant Palin

Technisch gesehen ist Legacy jeder Code, der fertig geschrieben ist. Sobald es in Produktion ist, ist es Vermächtnis. Da es dort bereits einen Wert gibt, kann man ihn nicht einfach wegwerfen ... Man muss sich damit befassen.

Es ist "vor deiner Zeit", aber "immer noch deine Kopfschmerzen".

8
Morons

Legacy-Code ist Code, der nur in der Codebasis verbleibt, da viele Dinge sonst nicht mehr funktionieren würden. Mit anderen Worten: Der einzige Grund für das Sein ist die Abwärtskompatibilität.

Sie möchten es lieber ändern oder sogar wegwerfen, aber Sie können es nicht, weil Sie den gesamten darauf basierenden Code brechen (dies könnte Code sein, den Sie nicht entsprechend anpassen können). Deshalb müssen Sie es behalten (und manchmal sogar pflegen), aber Sie möchten, dass der gesamte neue Code nicht dagegen geschrieben wird.

Ein Beispiel sind veraltete Methoden der API einer Bibliothek. Sie sind immer noch da, sodass jeder, der die Bibliothek aktualisiert, sein Projekt noch erstellen kann, sie jedoch als veraltet markiert sind und Ihr Compiler Sie warnen sollte.

Ein weiteres Beispiel sind all die seltsamen Tricks, die Microsoft unternimmt, um Programme zum Laufen zu bringen, die für Versionen ihres Betriebssystems geschrieben wurden, die vollständig veraltet sind. Der Höhepunkt dieses Wesens:

Ich habe dies zum ersten Mal von einem der Entwickler des Hit-Spiels SimCity gehört, der mir sagte, dass es einen kritischen Fehler in seiner Anwendung gibt: Es hat Speicher direkt nach dem Freigeben verwendet, ein großes Nein-Nein, das unter DOS aber in Ordnung war würde unter Windows nicht funktionieren, wenn freigegebener Speicher wahrscheinlich sofort von einer anderen laufenden Anwendung abgerufen wird. Die Tester im Windows-Team durchliefen verschiedene beliebte Anwendungen und testeten sie, um sicherzustellen, dass sie einwandfrei funktionierten. SimCity stürzte jedoch weiterhin ab. Sie meldeten dies den Windows-Entwicklern, die SimCity zerlegten, in einem Debugger durchgingen, den Fehler fanden und speziellen Code hinzufügten, der überprüfte, ob SimCity ausgeführt wurde, und falls dies der Fall war, den Speicherzuweiser in einem speziellen Modus ausführten, in dem Sie könnte nach dem Freigeben immer noch Speicher verwenden.
- Joel on Software

5
back2dos

Vermächtnis bedeutet Vererbung. Legacy-Code ist einfach Code, den Sie aus der Vergangenheit erben. Es ist Legacy-Code, auch wenn Sie ihn zuvor selbst geschrieben haben!

Alle anderen Überlegungen beruhen im Wesentlichen auf der Tatsache, dass Sie es nicht speziell für Ihr aktuelles Projekt geschrieben haben. Es ist nicht unbedingt eine schlechte Sache an sich.

4
Ando

Meiner Meinung nach hängt das, was als Legacy-Code betrachtet wird, von mehreren Faktoren ab, und das Tag "Legacy" ist wahrscheinlich organisationsspezifisch.

Wenn die Hardware/das Betriebssystem, auf dem es ausgeführt wird, alt ist und vom Hersteller eingestellt wurde - Strike 1.

Wenn es mehr Arbeit ist, zu versuchen, es zu beheben, als es aus irgendeinem Grund neu zu schreiben, weil

  • die ursprünglichen Entwickler sind verschwunden
  • das Programm ist schlecht geschrieben
  • es kann auf einer neueren Plattform besser gemacht werden und ist es für das Unternehmen immer noch wert

um dies zu tun

  • originalquelle ist nicht mehr verfügbar und/oder fehlende Teile

Streik 2.

Eine Zusammenführung mehrerer Organisationen zu einer - Strike 3 - einer Seite wird wahrscheinlich als Vermächtnis gekennzeichnet.

Gibt es eine bessere, billigere Alternative, die als Drittanbieteranwendung und/oder -dienst verkauft wird - Streik 4.

Ist die Organisation so etwas wie ein Krankenhaus oder ein Schulbezirk, in dem Beständigkeit gegenüber neuen Technologien im täglichen Betrieb geschätzt wird? Es dauert länger, bis eine Anwendung als Legacy betrachtet wird, verglichen mit derselben Anwendung in einer kommerziellen/wettbewerbsorientierten Organisation.

Wenn es sich bei dem Unternehmen um ein kleines Entwicklungsunternehmen handelt, das die Anwendung ständig erweitert/unterstützt, um die Anforderungen der Kunden zu erfüllen, wird dies als Legacy-Code oder nur als "alter" Code betrachtet. Ich kenne eine Firma namens Mc2Ok - sie haben die Software unter Windows 3.1 entwickelt und sie einfach weitergeführt. Es hat immer noch ein Windows 3.1-Erscheinungsbild, aber es wurde auch eine Weboberfläche hinzugefügt. Es ist eine Zwei-Mann-Entwicklerfirma (meine Vermutung), und ich würde sagen, wenn sie aufhören, daran zu arbeiten, wird dies als Vermächtnis betrachtet und es ist Zeit, ein oder zwei Jahre später zu migrieren, wenn sie es verwenden. Aber das könnten noch 10 oder mehr Jahre sein.

Manchmal, wenn sich das Management ändert, kann es sich in Wellen ändern, die viele Rinnsaleffekte haben ... Abhängig von der Schlagkraft des neuen Managements können viele Anwendungen als Legacy dargestellt werden, die ansonsten möglicherweise in Ordnung wären.

Ich glaube, jede Organisation muss definieren, was "Legacy-Code" für sie bedeutet. Ich habe jede Woche The Sunday Times Kleinanzeigen durchgesehen, um zu sehen, wonach Organisationen suchten. Das war früher mein Barometer für das, was nicht mehr relevant war (dh Vermächtnis). Nun, Die Sunday Times ist nicht mehr relevant :-) Und wir können verallgemeinern, dass COBOL Vermächtnis ist, ASP Classic ist Vermächtnis , etc ... Aber ich glaube, jede Organisation muss entscheiden, wann eine Anwendung als Legacy für sie betrachtet wird.

2
Gregory Thomson

Code ist ein Vermächtnis, wenn man Angst hat, ihn zu ändern, weil er ihn möglicherweise kaputt macht. Es ist noch schmerzhafter, wenn das gesamte System durch Änderungen an diesem Code zerstört wird.

Deshalb stimme ich auch der Definition von Michael Feathers zu. Code mit guten Komponententests kann furchtlos geändert werden.

Ich denke auch, dass Legacy-Code nichts damit zu tun hat, wie alt er ist. Man kann von Anfang an Legacy-Code schreiben.

0
komisacroS