Startup, neue Technologien, moderne Sprachen und Frameworks. Es ist alles so aufregend, wenn wir anfangen, etwas von Grund auf neu zu machen. Und wir werden auf jeden Fall versuchen, moderne, beliebte Technologien zu wählen, die von Millionen für unser Projekt geliebt werden. Aber die Zeit hört nicht auf, unerbittlich zu laufen, und plötzlich schauen wir zurück und sehen, dass unser "Startup" bereits 15 Jahre alt ist. Und die Welt hat sich längst verändert. Und wir haben immer noch das gleiche Basic / Delphi / Fortran / was auch immer in unserem Projekt. Und wie soll man damit leben?
Nein, ich möchte überhaupt keinen weiteren Holivar züchten, und das ist alles andere als ein Fan. Es ist nur mein persönlicher Schmerz, Projekte mit mehr als einer Million Codezeilen auf veralteten Technologien, insbesondere auf Delphi, zu leiten.
Und es wird interessant, wie lange ein erfolgreiches Projekt im Allgemeinen weiterlebt. Wenn Sie sich umschauen, dann gibt es im Prinzip einige Projekte mit einer "bärtigen Geschichte". Dies sind WinRAR, Microsoft Office, AutoCAD, Photoshop, 3DSmax und viele andere. Darüber hinaus sind dies Projekte für ein Massenpublikum. Und wie viele verschiedene Bankensysteme, CIS, CRM und andere "Unternehmens" -Systeme auf verschiedenen Ebenen existieren. Und viele von ihnen wurden nicht in den letzten fünf Jahren geschrieben.
Natürlich möchte ich mit der Zeit Schritt halten, aber die Migration eines großen Projekts von einer Sprache in eine andere ist meiner Meinung nach eine schwierige Aufgabe. Diese Migration findet nicht nur statt und das Schreiben von neuem Code, das alte Projekt sollte auch weiterhin funktionieren, leben und sich weiterentwickeln. In einem neuen Projekt ist es notwendig, die gesamte Logik des alten zu wiederholen, aber es ist nicht immer klar. In einem alten Projekt kann eine Menge Logik auf Bibliotheken aufgebaut werden, die von ihren Entwicklern lange Zeit nicht unterstützt wurden. In einem neuen Projekt sollten diese Bibliotheken ersetzt werden. Wenn es sich um visuelle Komponenten handelt, ist dies noch schwieriger, da Sie nicht nur einen Ersatz finden, sondern auch überlegen müssen, wie Sie den Code für die Arbeit mit diesen visuellen Komponenten neu schreiben, damit die neue Komponente das Verhalten der alten Komponente wiederholt. Natürlich ist alles lösbar und es gibt kein Ziel, die Arbeit des Projekts zu 100% zu wiederholen.Aber selbst 50% sind sehr, sehr schwierig, und bei einem solchen Umschreiben kann sich herausstellen, dass die Plattform / Sprache, in die Sie sich für das Umschreiben entschieden haben, irgendwie nicht geeignet ist oder bereits an Popularität verliert.
Natürlich spreche ich hauptsächlich von großen Projekten mit einer signifikanten Logikschicht. Eine Million Zeilen und mehr. Jene. nicht über Mini-Sites, nicht über Microservices, sondern über solche Monolithen (selbst wenn sie in "Komponenten" / "Schichten" usw. unterteilt sind).
Ich würde gerne die Meinung der hier Anwesenden erfahren. Sind Sie auf ähnliche Probleme gestoßen und wie haben Sie sich in ähnlichen Situationen verhalten?
Welche Lösungen würden Sie empfehlen, um sie während der Entwicklung anzuwenden, damit in 10-15 Jahren kein Wunsch besteht, das Projekt auf eine andere Plattform zu übertragen?
Danke für die Antworten!