Wann ist Code „Legacy“? [geschlossen]


63

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


Zusammenfassung der Antworten

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

  1. Jeder gelieferte Code: 6
  2. Tote Systeme: 2.5
  3. Keine Komponententests: 2
  4. Entwickler sind nicht in der Nähe: 1.5


1
Es ist Legacy-Code, sobald er geliefert wurde und funktioniert.
Martin Beckett

23
Es ist Legacy-Code, wenn Sie es nicht geschrieben haben ;-)
Steven A. Lowe

20
Es ist Legacy-Code, wenn jeder, der es geschrieben hat, im Ruhestand ist oder tot ist, und wenn diejenigen, die es weiterhin pflegen, dies wünschen. Andernfalls wird es nur als vorhandene Codebasis bezeichnet.
unpythonic

3
@ StevenA.Lowe, genug Zeit vorausgesetzt, es ist Legacy-Code, auch wenn ich ihn geschrieben habe.
Kyralessa

Antworten:


43

Ich bin selbst ziemlich parteiisch bei der Zusammenfassung von Wikipedia :

Ein Altsystem ist eine alte Methode, Technologie, ein Computersystem oder ein Anwendungsprogramm, die bzw. das weiterhin verwendet wird. Dies liegt in der Regel daran, dass es weiterhin für die Anforderungen der Benutzer funktioniert, obwohl neuere Technologien oder effizientere Methoden zur Ausführung von Aufgaben verfügbar sind.

Vieles, was andere Menschen in ihren Antworten beschreiben, ist der Grund, warum Code "Vermächtnis" wird. Die eigentliche Frage ist jedoch:

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

Die Tatsache, dass es immer noch in der Produktion verwendet wird, ist genau das, was es zum Erbe macht . Wenn der Code nicht richtig funktioniert oder nicht mehr in der Produktion verwendet wird, ist dieser Code "defekt" bzw. "zurückgezogen". Legacy bedeutet, dass es noch verwendet wird und einwandfrei funktioniert, aber Designs oder Techniken enthält, die nicht mehr allgemein verwendet werden.

Jeder Code oder jedes System, das Sie entweder (a) aktualisieren / aktualisieren möchten, aber nicht können oder (b) sich noch in der Aktualisierungsphase befinden, ist ein Altsystem. Dies bedeutet nicht , Refactoring oder allgemeine Code Bereinigung, bedeutet dies erhebliche Änderungen an die Konstruktion, möglicherweise einen neuen Rahmen oder sogar eine neue Plattform.

Es gibt eine Reihe von Gründen, warum Systeme oder Code zum Erbe werden können:

  • Fehlende regelmäßige Wartung oder Software verrotten . Wenn die Anwendung nicht regelmäßig gewartet wird, kann sie mit den großen Änderungen in der Software-Welt nicht 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 bezieht sich auf die hyperbolische Behauptung eines beliebten Autors, dass es sich bei Code, der nicht von Tests abgedeckt wird, um Legacy-Code handelt. Dies ist wirklich keine genaue Definition, aber es ist eine mögliche Grundursache. Ohne gute Tests (automatisiert oder manuell) werden Entwickler schüchtern und fürchten sich vor größeren Änderungen, weil sie sich Sorgen machen, dass etwas kaputt geht.

  • Rev-Locking, ein oft übersehener Faktor, der bei Projekten mit großen Open-Source-Bibliotheken oder Frameworks besonders heimtückisch ist (obwohl ich es auch mit kommerziellen Tools gesehen habe). Häufig werden umfangreiche Anpassungen an dem Framework / der Bibliothek vorgenommen, wodurch ein Upgrade unangemessen schwierig oder teuer wird. Dadurch wird das System zu einem Legacy-System, da es auf einer älteren (und möglicherweise nicht mehr unterstützten) Plattform ausgeführt wird.

  • Der Quellcode ist nicht mehr verfügbar, das heißt, das System kann immer nur ergänzt, 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 die Aktualisierung einer Codebasis verlangsamt oder stoppt, kann dazu führen, dass diese Codebasis zu einem Erbe wird.

Nun lautet die separate, unausgesprochene, aber implizite Frage: Was ist mit Legacy-Code falsch? Es 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 gewährleistet und der Begriff selbst impliziert eindeutig einen funktionierenden Code. Der Punkt ist nicht, dass es funktioniert, sondern wie es funktioniert.

In einigen Fällen ist der Legacy-Code nicht fehlerfrei. Es ist kein schlechtes Wort. Legacy-Code / Systeme sind nicht böse. Sie haben nur etwas Staub gesammelt - manchmal ein bisschen, manchmal viel.

Legacy wird obsolet, wenn das System nicht mehr alle Anforderungen des Kunden erfüllen kann. Bei diesem Etikett müssen wir vorsichtig sein. 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 der geringeren zukünftigen Wartungskosten), lassen Sie das Upgrade ansonsten in Ruhe. Sie müssen das Wort "Legacy" nicht in dem Ton ausspucken, den Sie normalerweise für "Tax Audit" reservieren. Es ist vollkommen in Ordnung, in dieser Situation zu sein.


Das heißt, die Steuerprüfung sollte auch in Ordnung sein.
Florian Margaine

Ich würde sagen: System, das mit dem vorhandenen Technology Stack nicht mehr skalierbar ist.
Ramiz Uddin

40

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

Beispielsweise schreiben die meisten Orte keine neuen Programme in Cobol. Ein Großteil ihres Geschäfts kann jedoch mit Apps ausgeführt werden, die in Cobol geschrieben wurden. Daher werden diese Apps als "Legacy" bezeichnet.


Ich stimme dieser Antwort am meisten zu. Bei Legacy geht es mehr darum, auf einer veralteten Plattform zu bleiben, als um lästigen (und dennoch modernen) Code, den Sie nicht unterstützen möchten. Legacy - Code ist oft recht gut (sonst wäre es niemandem wichtig, wenn Sie ihn zurücklassen!), Aber normalerweise ist er mit veralteter Hardware und veralteten Sprachen / Bibliotheken / Datenbanken / etc. Verbunden.
Satanicpuppy

3
@Satanicpuppy: Ich kann einfach nicht zustimmen - ich habe (zum Beispiel) Java behandelt, das definitiv nicht an eine bestimmte Hardware, Bibliothek oder Datenbank gebunden war - aber so "alt" wie es nur geht (und war) in Java umgeschrieben, daher war auch die Sprache nicht das Problem). Ich habe mich auch mit Code befasst, der an bestimmte Hardware gebunden war, sich aber noch kaum in der Kategorie "Legacy" befand.
Jerry Coffin

4
@ Jerry: Also, was hat es zum Vermächtnis gemacht? Vermächtnis ist kein Synonym für "schlecht".
Satanicpuppy

1
Im vorliegenden Fall handelte es sich um ein ziemlich großes verteiltes System (das auf BEA Tuxedo basiert). Das Design schien auf Lehrbuchszenarien zu basieren, in denen die Synchronisation durch Maximierung der Anzahl der erforderlichen Synchronisationsvorgänge vermittelt werden soll. Das ist (irgendwie) sinnvoll für ein Lehrbuch, aber für echte Designs ist es schrecklich . Es war groß genug, dass selbst die Planung eines Ersatzes ein mehrjähriges Projekt war. Der Austausch musste in Phasen ohne Ausfallzeiten erfolgen, da das System für das Unternehmen absolut notwendig war.
Jerry Coffin

1
@Cawas: Es scheint mir, dass @Chads Antwort zutreffen würde, wenn / wenn das neue System in einer anderen Sprache oder auf einer anderen Hardware usw. ausgeführt würde. Dies wurde neu entwickelt, immer noch unter Verwendung von Java, immer noch unter Verwendung von Tuxedo usw. Ich sehe es nicht als zutreffend an.
Jerry Coffin

28

Legacy ist jeder Code, den Sie lieber ersetzen als damit arbeiten möchten. In Anbetracht der Einstellung der meisten Programmierer zu den meisten vorhandenen Codes beinhaltet dies normalerweise fast alles außer dem, was Sie gerade aktiv schreiben (und bei einem großen Projekt, bei dem Sie zu einem eingefrorenen Design codieren müssen, auch das, was Sie gerade schreiben) Moment kann auch einbezogen werden).

  1. Die Betonung "eher" soll vermitteln, dass Legacy-Code auch bedeutet, dass Sie nicht mehr daran 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 einfach zu groß und komplex, um sie zu ersetzen. Andere sind Schnittstellen zu anderen Systemen. Wieder andere sind von Politik und Persönlichkeiten getrieben (zum Beispiel ist der Code schrecklich, aber das Standbaby war unglaublich).
  2. Ein weiterer Punkt , den ich kann nicht genug betont haben , ist , dass , während die Qualität des Codes kann ein Faktor sein, es ist selten (wenn überhaupt) der einzige Faktor - und oft nicht einmal ein besonders wichtiges.
  3. Ich denke, die Leute, die Unit-Tests als einzigen bestimmenden Faktor durchführen, sind wie der Typ, der unter der Straßenlaterne nach dem Ohrring sucht, den seine Frau einen Block entfernt abgelegt hat. Das Licht ist vielleicht besser, aber Sie schauen immer noch am falschen Ort. Denken Sie nach , bevor Sie die Kool-Aid trinken .
  4. (Eine Folge zu 3.) Es scheint mir, dass einige Leute mehr darüber sprechen, wie sie sich Dinge wünschen, als wie sie wirklich sind. Wenn John Conways " Game of Life für einen Apple IIc plus nicht Erbe ist, dann ist es , weil es ausreichend klein und einfach ist , dass es einfach ist , von Grund auf neu zu implementieren. Der perfekteste Komponententest, der jemals geschrieben wurde, ändert nichts an diesem einen Jota .

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

Erstens wird Code häufig als Erbe 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 denken, dass lokalisierte Änderungen in der Implementierung wirklich wichtig sind. Um signifikante Verbesserungen in einem größeren System zu erzielen, müssen Sie häufig (normalerweise?) Genug am Gesamtdesign ändern, dass viele (wenn nicht die meisten) Komponententests irrelevant werden. Leider können die vorhandenen Unit-Tests und die Einstellung, die sie hervorrufen, es allzu leicht machen, die wirklich notwendigen Änderungen zu ignorieren.

Vielleicht hilft ein Beispiel: Nehmen wir an, ein Programm verfügt über eine UI- Bibliothek mit hervorragenden Komponententests und mehrere Programme, die diese Bibliothek verwenden. Jemand aus der oberen Führungsebene ist davon überzeugt, dass "web enabled" wichtig ist (und nehmen wir in diesem Fall aus Gründen der Argumentation an, dass er 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 Remoteanzeige über HTML / CSS / AJAX zu wechseln, wobei die ursprüngliche Eingabevalidierung beibehalten wird.

Das ist toll, 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 überprüft werden, um die Datenintegrität sicherzustellen. Unit-Tests haben den Tag gerettet!

Oder nicht! Diese großartige, hochflexible, sorgfältig auf Unit-Tests getestete UI-Bibliothek hat allen Beteiligten vor Augen geführt, dass für dieses Programm auf dem Markt für seine Benutzer eine webbasierte UI absolut falsch ist. Was wirklich benötigt wird, ist ein Webservice mit einer REST-fähigen Schnittstelle und überhaupt keiner eigenen Benutzeroberfläche.

Nun ist es sicherlich wahr, dass Unit-Tests nicht an sich die Fähigkeit der Menschen beeinträchtigen, ihren Markt zu verstehen oder zu erkennen, dass dies wirklich notwendig ist. Gleichzeitig fällt einem die alte Linie um Hämmer und Nägel geradezu ein. Es kann noch schlimmer sein , wenn Sie nicht nur haben einen Hammer, aber eine haben viel Erfahrung mit diesem Hammer, und wissen , es ist ein wirklich ein qualitativ hochwertiges Hammer, unglaublich gut in vielen verschiedenen Situationen funktioniert. Die Tatsache, dass es in so vielen Situationen so gut ist, macht es noch schwieriger zu erkennen, ob es sich um das völlig falsche Werkzeug für den jeweiligen Job handelt.


3
Sehen Sie, jetzt weiß ich nicht, ob ich das markieren soll oder nicht, leider ist das wahr, aber ich frage mich, ob es eine Haltung ist, von der wir wegkommen müssen ...
Nim

+1. Ich wollte gleich etwas beantworten. Legacy ist jeder Code, der verwendet und nicht aktiv verwaltet wird.
Denis de Bernardy

@Nim: Ich denke nicht, dass es eine Einstellung ist, von der "wir" weg müssen. Es ist eine bloße Aussage des Offensichtlichen. :-) Denken Sie einen Moment darüber nach und fragen Sie sich, was Sie als Legacy-Code betrachten würden, wenn Sie in einer neuen Umgebung ankommen würden. Es wird alles sein, außer den neuen und coolen Dingen, die aktiv entwickelt werden.
Denis de Bernardy

@ Jerry, also magst du Unit-Tests dann nicht? ;)
Nim

1
@Nim: Nicht so - ich denke, sie sind nützlich, aber weit hinter dem Allheilmittel zurück, als das sie häufig dargestellt werden.
Jerry Coffin

17

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

Ich arbeite die ganze Zeit an altem 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 einfach ausgetauscht zu werden

Wenn es diese Eigenschaften nicht hat, dann ist es wahrscheinlich kein Erbe. Wenn Sie die Perl- Skripte Ihrer Vorgänger nicht mögen , sympathisiere ich, aber ich denke nicht, dass es 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, verglichen mit der kleinsten Änderung an unserem fürchterlichen COBOL- Abrechnungssystem.


Scary, unser Hauptentwickler ist ebenfalls Ukrainer ... haha ​​... Ich stimme dem Mittelteil Ihrer Antwort zu, dem ersten Punkt - nicht so sehr - ich denke, das hängt davon ab, wie Ihr Entwicklerteam aufgestellt ist.
Nim

1
lol, Sie haben es wahrscheinlich geschafft, alle in einem Absatz zu beleidigen (Busfahrer, die ukrainische Sprache und VB6-Entwickler). Aber verdammt habe ich gelacht :)
Darknight

Ich bin ein Zeitreisender von 1999, meinst du Visual Basic 6 ist Legacy von 2011 an?
hjk

@hjk Ich würde sagen , so ziemlich alles , nach dem Aufkommen von C # / asp.net im Jahr 2005 auf unsicheren Boden sein würde, aber auf jeden Fall einmal das Ende der Unterstützung von Microsoft gerollt um im Jahr 2008
Satanicpuppy

12

In seinem Buch Effective Working with Legacy Code definiert Michael Feathers Legacy Code als Code, der nicht in Komponententests behandelt wird. Das ist eine Definition, der ich zustimme. Ich sehe auch Legacy-Code als alt, aber immer noch verwendbar.


24
Dies erscheint mir als der Versuch, "alles, was nicht meiner gewählten Methodik entspricht", als "Vermächtnis" zu definieren. Es ist nicht mehr oder weniger als eine billige Debattiertaktik, im Grunde genommen nur Godwins Gesetz zu akzeptieren und die Sprache (kaum) zu mildern, um die Leser davon abzuhalten, sofort zu erkennen, dass es nichts anderes ist als ein nicht unterstützter (und oft unerträglicher) Angriff auf jeden, der nicht folgt seine Vorlieben.
Jerry Coffin

4
@ Jerry: Ich stimme der Definition von Feather zu. Code ohne Unit-Tests ist ein Horror, mit dem man arbeiten muss. Wenn Sie sich dazu entschließen, einige Teile zu überarbeiten, damit es einfacher wird, darüber nachzudenken, vergessen Sie es! Sie führen möglicherweise Fehler ein und der Code ist wahrscheinlich ohnehin nicht testbar! Ich finde die Definition von Feather unkonventionell, aber er ist jemand, der seinen Lebensunterhalt damit verdient hat, mit altem Code zu arbeiten.
verschlang Elysium

10
@devoured: Unit-Tests sind keine genauen Lackmustests für die Fähigkeit, mit Code zu arbeiten. Ich habe mich mit Code befasst, dem Unit-Tests fehlten, aber es war ein Kinderspiel - und mit Code, der Unit-Tests hatte und immer noch ein Albtraum war. Letztendlich lösen Unit-Tests nichts an sich. Unit-Tests für ein Design, bei dem (zum Beispiel) die Aufteilung in Units schlecht durchgeführt wurde, können immer noch absolut wertlos sein, und das gesamte Design (einschließlich Tests) muss weggeworfen und ersetzt werden, um alles Nützliche zu produzieren.
Jerry Coffin

6
Ich stimme den Kommentaren von Jerry zu. Das Fehlen von Komponententests ist nur einer von vielen Code-Gerüchen, die möglicherweise auf eine schlechte Qualität hinweisen (oder auch nicht ).
SMCI

4
Ich stimme wieder mit der Definition von Feather überein und verschlungen. Das Fehlen von Unit-Tests ist alles, da selbst das schönste Code-Snippet seine Spezifikationen nicht aufweist. Unit-Tests bestehen zu 51% aus der Dokumentation und zu 100% aus der Spezifikation des Codes. Ein Code, dem der größte Teil seiner Dokumentation fehlt und dessen gesamte Spezifikation zu Recht als Legacy klassifiziert werden sollte.

8

Technisch gesehen ist Legacy jeder Code, der fertig geschrieben ist. Sobald es in Produktion ist, ist es ein 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" .


5

Legacy-Code ist Code, der nur in der Codebasis verbleibt, da sonst viele Dinge nicht mehr funktionieren. Mit anderen Worten: Es ist nur ein Grund für die Abwärtskompatibilität.

Sie möchten es lieber ändern oder sogar wegwerfen, können es aber nicht, weil Sie den gesamten Code unter Berufung darauf brechen werden (das könnte Code sein, den Sie nicht entsprechend anpassen können). Deshalb müssen Sie es behalten (und manchmal sogar warten), aber Sie möchten, dass kein neuer Code dagegen geschrieben wird.

Ein Beispiel sind veraltete Methoden der API einer Bibliothek. Sie sind immer noch vorhanden, sodass jeder, der die Bibliothek aktualisiert, weiterhin sein Projekt erstellen kann, sie jedoch als veraltet markiert sind und Sie vom Compiler gewarnt werden sollten.

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:

Das habe ich zum ersten Mal von einem der Entwickler des Hit-Spiels SimCity gehört, der mir erzählte, dass seine Anwendung einen kritischen Fehler aufweist: Sie hat den Speicher direkt nach dem Freigeben verwendet, ein wichtiges Nein-Nein, das unter DOS aber einwandfrei funktioniert hat würde unter Windows nicht funktionieren, wenn Speicher, der freigegeben wird, wahrscheinlich sofort von einer anderen ausgeführten 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 disassemblierten, es in einem Debugger durchsuchten, den Fehler fanden und speziellen Code hinzufügten, der überprüfte, ob SimCity ausgeführt wurde, und wenn ja, den Speicher-Allokator in einem speziellen Modus ausführten, in dem Sie Speicher kann nach dem Freigeben noch verwendet werden.
- Joel über Software


4

Vermächtnis beinhaltet 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 darauf, dass Sie es nicht speziell für Ihr aktuelles Projekt geschrieben haben. Es ist nicht unbedingt eine schlechte Sache an sich.


Die Vergangenheit kann 1 Tag, 1 Stunde oder 1 Jahr sein. Das macht es nicht zum Vermächtnis.
Vince Panuccio

2

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

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

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

  • Die ursprünglichen Entwickler sind verschwunden
  • Das Programm ist schlecht geschrieben
  • Es kann auf einer neueren Plattform besser gemacht werden und ist es dem Unternehmen trotzdem wert

um das zu tun

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

Strike 2.

Ein Zusammenschluss mehrerer Organisationen zu einer - Strike 3 - Seite wird wahrscheinlich als Vermächtnis eingestuft.

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

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

Wenn das Unternehmen ein kleines Entwicklungsunternehmen ist, 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 auf Windows 3.1 entwickelt und sie einfach weiterentwickelt. Es sieht immer noch sehr gut aus wie Windows 3.1, aber es wurde auch ein Webinterface hinzugefügt. Es ist ein Zwei-Mann-Entwicklerunternehmen (meine Vermutung), und ich würde sagen, wenn sie aufhören, daran zu arbeiten, wird es als Vermächtnis betrachtet und es wird 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 Trickle-Effekte haben. Abhängig von der Schlagkraft des neuen Managements kann es viele Anwendungen wiedergeben, 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 in den Kleinanzeigen der Sunday Times nachgeschlagen, wonach Organisationen gesucht haben. Das war früher mein Barometer für das, was nicht mehr relevant war (dh das Erbe). Nun, die Sunday Times ist nicht mehr relevant :-) Und wir können verallgemeinern, dass COBOL ein Vermächtnis ist, ASP Classic ein Vermächtnis usw. Aber ich glaube, dass jede Organisation entscheiden muss, wann eine Anwendung als Vermächtnis dafür betrachtet wird.


+1, nette Antwort - besser etwas Erbe aus der Sicht der Organisation zu betrachten ...
Nim

0

Code ist ein Erbe, wenn man Angst hat, ihn zu ändern, weil er ihn brechen könnte. 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, der gute Unit-Tests hat, 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.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.