Entwicklung von Webanwendungen für eine lange Lebensdauer (über 20 Jahre)

160

Ich entwickle derzeit eine Webanwendung für die staatliche Landplanung. Die Anwendung wird hauptsächlich im Browser ausgeführt und verwendet Ajax zum Laden und Speichern von Daten.

Ich werde die erste Entwicklung machen und dann meinen Abschluss machen (es ist ein Studentenjob). Danach wird der Rest des Teams das gelegentliche Feature nach Bedarf hinzufügen. Sie wissen, wie man programmiert, aber sie sind meistens Landplanungsexperten.

Wie kann ich in Anbetracht der Geschwindigkeit, mit der sich die Javascript-Technologien ändern, Code schreiben, der in 20 Jahren noch funktioniert? Welche Bibliotheken, Technologien und Entwurfsideen sollte ich verwenden (oder vermeiden), um meinen Code zukunftssicher zu machen?

Dan
quelle
94
Ich habe Ende 1966 in Fortran angefangen zu programmieren, also hatte ich viel Zeit, um über genau diese Art von Problem nachzudenken. Wenn Sie jemals auf eine zu 50% zuverlässige Antwort stoßen, lassen Sie es mich bitte wissen. Denken Sie in der Zwischenzeit an die fast unausweichliche Überalterung als "Arbeitsplatzsicherheit" :)
John Forkosh
11
In Software Engineery ist nichts für immer gültig. Nur HOST bei Banken und weil sich niemand traut, solche kritischen Systeme zu aktualisieren. Nun, ich denke, das Programm, das in der Voyager läuft, zählt auch.
Laiv,
9
@Laiv Vor einiger Zeit arbeitete ich an Geldtransferanwendungen für Bankers Trust mit Swift-Nachrichten, die auf Vax / VMS ausgeführt wurden. Ein paar Jahre später beendete Swift den gesamten VMS-Support. Junge, hat das ein paar Probleme verursacht ... und mir einen weiteren Vertrag bei BTCo gegeben. Wie ich oben schon sagte, "Arbeitsplatzsicherheit" :). Mein Punkt ist jedenfalls, dass selbst kritische Finanzmarktanwendungen nicht gegen Veralterung gefeit sind.
John Forkosh
102
Wie wäre es mit "Code schreiben, den der nächste Entwickler verstehen kann"? Wenn der Code so veraltet ist, dass ein Programmierer gefunden werden muss, um ihn zu aktualisieren, ist das beste Szenario, dass er versteht, was Ihr Code tut (und möglicherweise, warum bestimmte Entscheidungen getroffen wurden).
David Starkey
38
Verwenden Sie einfach altes HTML, kein JS, keine Plugins, nichts Besonderes. Wenn es in Lynx funktioniert, ist es für alle Zeiten gut.
Gaius,

Antworten:

132

Planungssoftware für eine solche Lebensdauer ist schwierig, weil wir nicht wissen, was die Zukunft bringt. Ein bisschen Kontext: Java wurde vor 1995, 21 Jahren veröffentlicht. XmlHttpRequest wurde vor 17 Jahren als proprietäre Erweiterung für Internet Explorer 5 veröffentlicht. Es dauerte ungefähr 5 Jahre, bis es für alle gängigen Browser verfügbar wurde. Die 20 Jahre, in denen Sie nach vorne schauen möchten, sind fast die Zeit, in der es überhaupt umfangreiche Webanwendungen gibt.

Einige Dinge sind seitdem sicherlich gleich geblieben. Es wurden große Anstrengungen zur Standardisierung unternommen, und die meisten Browser entsprechen den verschiedenen Standards. Eine Website, die vor 15 Jahren browserübergreifend funktioniert hat, funktioniert immer noch genauso, vorausgesetzt, sie hat auf die gemeinsame Untergruppe aller Browser abgestellt und nicht auf Problemumgehungen für jeden Browser.

Andere Dinge kamen und gingen - vor allem Flash. Flash hatte eine Vielzahl von Problemen, die zu seinem Untergang führten. Vor allem wurde es von einer einzigen Firma kontrolliert. Anstelle eines Wettbewerbs innerhalb der Flash-Plattform gab es einen Wettbewerb zwischen Flash und HTML5 - und HTML5 gewann.

Aus dieser Geschichte können wir einige Hinweise gewinnen:

  • Machen Sie es sich einfach: Machen Sie das, was gerade funktioniert, ohne Abhilfemaßnahmen. Dieses Verhalten wird wahrscheinlich aus Gründen der Abwärtskompatibilität noch lange verfügbar sein.

  • Vermeiden Sie es, sich auf proprietäre Technologien zu verlassen, und bevorzugen Sie offene Standards.

Die heutige JavaScript-Welt ist relativ volatil mit einer großen Anzahl von Bibliotheken und Frameworks. In 20 Jahren wird jedoch fast keiner von ihnen von Bedeutung sein - das einzige „Framework“, von dem ich mir sicher bin, dass es bis dahin noch verwendet wird, ist Vanilla JS .

Wenn Sie eine Bibliothek oder ein Tool verwenden möchten, weil dies die Entwicklung erheblich vereinfacht, stellen Sie zunächst sicher, dass es auf den heute gut unterstützten Standards basiert. Anschließend müssen Sie die Bibliothek oder das Tool herunterladen und in Ihren Quellcode aufnehmen. Ihr Code-Repository sollte alles enthalten, was benötigt wird, um das System lauffähig zu machen. Alles Externe ist eine Abhängigkeit, die in Zukunft brechen könnte. Eine interessante Möglichkeit, dies zu testen, besteht darin, Ihren Code auf ein USB-Stick zu kopieren, auf einen neuen Computer mit einem anderen Betriebssystem zu wechseln, die Verbindung zum Internet zu trennen und zu prüfen, ob Sie Ihr Frontend zum Laufen bringen können. Solange Ihr Projekt aus einfachem HTML + CSS + JavaScript und möglicherweise einigen Bibliotheken besteht, werden Sie wahrscheinlich bestehen.

amon
quelle
4
Großanwendungen sind in Vanille js ab sofort nicht mehr möglich. ES6 behebt das Problem bereits, aber es gibt einen Grund, warum Flow oder TypeScript immer beliebter werden.
Andy
34
@DavidPacker Absolut, TypeScript usw. sind großartig und erleichtern die Entwicklung. Sobald ich jedoch einen Build-Prozess einführe, werden alle für den Build-Prozess erforderlichen Tools zu Abhängigkeiten: NodeJS, Gulp, NPM - wer sagt, dass NPM in 20 Jahren noch online sein wird? Ich muss meine eigene Registrierung ausführen, um sicherzugehen. Das ist nicht unmöglich. Aber irgendwann ist es besser, Dinge loszulassen, die die Entwicklung nur sofort erleichtern, aber auf lange Sicht nicht.
amon
30
@DavidPacker Es gibt viele dynamische Sprachen, und überraschenderweise wurden viele erfolgreiche Systeme mit Smalltalk, Ruby, Perl, Python und sogar mit PHP und JS erstellt. Während statisch typisierte Sprachen in der Regel besser zu warten sind, während dynamische Sprachen für Rapid Prototyping besser geeignet sind, ist es nicht unmöglich, wartbare JS-Dateien zu schreiben. In Ermangelung eines Compilers wird eine hohe Durchschnittskompetenz im Team, handwerkliches Können und die besondere Betonung einer klaren Code-Organisation noch wichtiger. Ich persönlich denke, Typen machen alles einfacher, aber sie sind keine Wunderwaffe.
amon
4
Habe ich gerade gelesen "Nehmen Sie USB und testen Sie auf einem anderen Computer"? Warum nicht einfach virtualbox hochfahren oder den Inkognito-Modus verwenden (mit deaktiviertem ethX)?
Kyslik
5
Ich bin nicht sicher , ob Vanille JS in 20 Jahren eine sichere Sache sein wird. Die Geschichte war steinig und experimentell, und es hat sich eine Menge Kruft angesammelt, auch wenn sich herausgestellt hat, dass es eine entzückende und effektive Sprache ist (ich persönlich bevorzuge JavaScript oder TypeScript). Es ist nicht schwer vorstellbar, dass die Anbieter einen Teil oder die gesamte Cruft loswerden möchten, ob es nun darum geht, eine neue alternative Sprache anzubieten - wie Google anscheinend mit Dart vorschlägt, auch wenn vieles, was nirgendwo hingegangen zu sein scheint - Oder indem Teile von JS verworfen und dann beseitigt werden.
KRyan
178

Noch wichtiger als das 20-jährige Überleben Ihres Codes ist das 20-jährige Überleben Ihrer Daten . Wahrscheinlich ist es das, was es wert ist, bewahrt zu werden. Wenn es einfach ist, mit Ihren Daten zu arbeiten, ist es einfach, ein alternatives System mit neuerer Technologie darauf aufzubauen.

  • Beginnen Sie also mit einem klaren und gut dokumentierten Datenmodell.
  • Verwenden Sie ein etabliertes, gut unterstütztes Datenbanksystem wie Oracle [1] oder SQL Server.
  • Nutze die Grundfunktionen, versuche nicht, auffällige neue hinzuzufügen.
  • Lieber schlicht als schlau .
  • Akzeptieren Sie, dass zukünftige Wartbarkeit auf Kosten von Aspekten wie Leistung gehen kann. Sie könnten beispielsweise versucht sein, gespeicherte Prozeduren zu verwenden, diese können jedoch die zukünftige Wartbarkeit einschränken, wenn sie verhindern, dass jemand das System auf eine einfachere Speicherlösung migriert.

Sobald Sie das haben, ist die Zukunftssicherung der App selbst einfacher, da sie das Datenmodell umgibt und ersetzt werden kann, wenn beispielsweise in 10 Jahren niemand mehr Javascript verwendet und Sie die App nach migrieren müssen WASM oder so. Die Modularität und Unabhängigkeit der Komponenten erleichtert die zukünftige Wartung.


[1] Die meisten Kommentare zu dieser Antwort sprechen sich entschieden gegen die Verwendung von Oracle für eine Datenbank aus und führen eine Reihe absolut legitimer Gründe an, warum es schwierig ist, mit Oracle zu arbeiten, die Lernkurve steil ist und der Installationsaufwand hoch ist. Dies sind durchaus berechtigte Bedenken bei der Auswahl von Oracle als Datenbank. In unserem Fall suchen wir jedoch nicht nach einer Universal-Datenbank, sondern nach einer Datenbank, bei der das Hauptaugenmerk auf der Wartbarkeit liegt . Oracle gibt es seit den späten 70ern und wird wahrscheinlich noch viele Jahre unterstützt. Es gibt ein riesiges Ökosystem von Beratern und Support-Optionen, die Ihnen dabei helfen, es am Laufen zu halten. Ist das ein überteuertes Durcheinander für viele Unternehmen? Sicher. Aber bleibt Ihre Datenbank 20 Jahre lang in Betrieb ? Ziemlich wahrscheinlich.

Avner Shahar-Kashtan
quelle
141
Es tut mir leid, aber ich muss das sagen. Wenn Sie Oracle verwenden, schießen Sie jedem in den Fuß, was das "einfache Arbeiten" betrifft. Es ist nicht leicht, mit Oracle zu arbeiten. Eine Menge Funktionen, die SQL Server, PostgreSQL und wahrscheinlich sogar MySQL einfach machen, hat Oracle entweder gar nicht oder macht es übermäßig schwierig. Ich habe nie so viele dumme Probleme mit anderen DBs wie mit Oracle. Schon das Einrichten des Kunden ist ein großes Ärgernis. Auch googeln ist schwer. Wenn Sie einfach arbeiten möchten, halten Sie sich von Oracle fern.
jpmc26
4
+1, um die Daten so einfach wie möglich zu halten. Verwenden Sie hierfür Standard-SQL, z. B. OUTER JOIN anstelle des Orakel-spezifischen Operators + . Verwenden Sie einfache Tabellenlayouts. Normalisieren Sie Ihre Tabellen nicht auf das absolute Maximum. Entscheiden Sie, ob einige Tabellen redundante Daten enthalten können oder ob Sie wirklich eine neue Tabelle erstellen müssen, damit jeder Wert nur einmal vorhanden ist. Sind Stored Procedures herstellerspezifisch ? Wenn ja, dann benutze sie nicht. Verwenden Sie nicht die heißeste Funktion Ihrer aktuellen Sprache: Ich habe mehr COBOL-Programme ohne OOP-Funktionen als mit ihnen gesehen. Und das ist völlig in Ordnung.
some_coder
3
@ jpmc26 Ich stimme Ihrer Meinung zu Oracle zu, aber wie gesagt: "Einfach zu arbeiten" ist hier nicht unbedingt die Hauptanforderung. Ich bevorzuge hier eine solide unterstützte Plattform, auch wenn es schwierig ist, mit ihr zu arbeiten. Denn wenn es über 20 Jahre amortisiert ist, ist es nicht so schlimm.
Avner Shahar-Kashtan
8
Vermeiden Sie in der Tat Oracle. Die einzige DB, die heute existiert und in 20 Jahren wahrscheinlich keine schlechte Wahl sein wird, ist Postgresql.
Joshua
3
Ich möchte hinzufügen, dass großartige Open-Source-DBMS vorzuziehen sind, da die Wahrscheinlichkeit groß ist, dass sie nicht sterben. Wenn Oracle in 10 Jahren aufhört, Geld zu verdienen, wird es in 11 Jahren weg sein. PostreSQL scheint das beste Pferd zu sein, auf das man wetten kann.
Shautieh
36

Die vorherige Antwort von amon ist großartig, aber es gibt zwei zusätzliche Punkte, die nicht erwähnt wurden:

  • Es geht nicht nur um Browser; Geräte sind auch wichtig.

    amon erwähnt die Tatsache, dass eine „Website, die vor 15 Jahren browserübergreifend funktioniert hat, immer noch dieselbe Funktion hat“ , was zutrifft. Schauen Sie sich jedoch die Websites an, die vor nicht fünfzehn, sondern zehn Jahren erstellt wurden und bei den meisten Benutzern in den meisten Browsern funktionierten. Heutzutage kann ein großer Teil der Benutzer diese Websites überhaupt nicht mehr verwenden, nicht weil sich die Browser geändert haben, sondern weil sich die Geräte geändert haben. Diese Websites würden auf kleinen Bildschirmen mobiler Geräte furchtbar aussehen und letztendlich überhaupt nicht funktionieren, wenn Entwickler sich für JavaScript- clickEreignisse entscheiden, ohne zu wissen, dass dieses tapEreignis ebenfalls wichtig ist.

  • Sie konzentrieren sich auf ein falsches Thema.

    Technologische Veränderungen sind eine Sache, aber eine wichtigere ist die Veränderung der Anforderungen . Möglicherweise muss das Produkt skaliert werden oder es müssen zusätzliche Funktionen bereitgestellt oder die aktuellen Funktionen müssen geändert werden.

    Es ist egal, was mit Browsern, Geräten, W3C oder was auch immer passiert.

    Wenn Sie Ihren Code so schreiben, dass er überarbeitet werden kann , entwickelt sich das Produkt mit der Technologie weiter.

    Wenn Sie Ihren Code so schreiben, dass niemand ihn verstehen und pflegen kann, spielt die Technologie keine Rolle: Jede Änderung der Umgebung kann Ihre Anwendung ohnehin zum Erliegen bringen, z. B. eine Migration auf ein anderes Betriebssystem oder einfach nur natürliches Datenwachstum .

    Als Beispiel arbeite ich seit zehn Jahren in der Softwareentwicklung. Unter den Dutzenden von Projekten gab es nur zwei, für die ich mich aus technologischen Gründen entschieden habe , genauer gesagt, weil sich PHP in den letzten zehn Jahren stark weiterentwickelt hat. Es war nicht einmal die Entscheidung des Kunden: Es würde ihn nicht weniger interessieren, ob die Site die Namespaces oder Closures von PHP verwendet. Es gab jedoch viele Änderungen in Bezug auf neue Anforderungen und Skalierbarkeit!

Arseni Mourzenko
quelle
4
Die Anpassung an unterschiedliche Bildschirmgrößen ist ein generelles Problem. Im Moment ist Mobile angesagt, aber wenn Sie diese Website in einem Vollbild-Browserfenster auf einem Bildschirm mit ausreichender Auflösung anzeigen, ist viel (verschwendeter) Speicherplatz vorhanden. Das Ändern des Layouts und der Darstellung von Informationen, um die verfügbaren Pixel optimal zu nutzen, ist nie wirklich auf intelligente Weise geschehen. Mobile machte dies deutlich. Aber in die andere Richtung zu denken, könnte für die vorliegende Frage wichtiger sein.
Null
9
@null: Auch wenn ich Ihrem Kommentar zustimme, sind StackExchange-Websites möglicherweise nicht das beste Beispiel für Ihren Standpunkt. Angesichts der Daten, die angezeigt werden sollen, haben die Designer / Entwickler von StackExchange meiner Meinung nach hervorragende Arbeit geleistet, um die Daten so anzuzeigen, wie sie angezeigt werden müssen, auch auf großen Monitoren. Sie können die Hauptspalte nicht breiter machen, da der Text dann viel schwieriger zu lesen ist, und Sie können nicht mehrere Spalten verwenden, da kurze Fragen und Antworten nicht gut aussehen.
Arseni Mourzenko
Ein weiteres gutes Beispiel ist das "Hover" -Ereignis, das häufig in Menüsystemen verwendet wurde. Viele dieser Menüs schlagen bei Touch-Geräten kläglich fehl.
Justas
Sie haben 110% (oder mehr) Recht mit Geräten, und ich kann Ihnen Jahrzehnte ältere Beispiele liefern. In den späten 1980er Jahren arbeitete ich an CICS-Anwendungen, die auf IBM-Mainframes und synchronen 3270-Terminals ausgeführt wurden. Die CICS-Region ist vergleichbar mit serverseitigen Apps und sendet bildschirmfüllend Daten auf einmal an die synchronen Terminals, die daher mit dedizierten Gerätebrowsern vergleichbar sind. Und CICS-Programmierung war vielleicht 80% Cobol, 20% PL / 1. Beide Sprachen sind heutzutage größtenteils veraltet, und das Erscheinen von Unix-Workstations (Sun und Apollo) in den frühen
neunziger Jahren
31

Sie planen nicht, 20 Jahre zu dauern. Schlicht und einfach. Stattdessen verlagern Sie Ihre Ziele auf die Unterteilung.

Ist Ihre App-Datenbank agnostisch? Wenn Sie jetzt die Datenbank wechseln müssten, könnten Sie. Ist Ihre Logiksprache agnostisch? Wenn Sie die App jetzt in einer völlig neuen Sprache schreiben müssten, könnten Sie das? Befolgen Sie gute Designrichtlinien wie SRP und DRY?

Ich habe Projekte länger als 20 Jahre laufen lassen, und ich kann Ihnen sagen, dass sich die Dinge ändern. Wie Popups. Vor 20 Jahren konnte man sich auf ein Pop-up verlassen, heute geht das nicht mehr. Vor 20 Jahren war XSS noch keine Sache, jetzt müssen Sie CORS berücksichtigen.

Stellen Sie also sicher, dass Ihre Logik gut getrennt ist und dass Sie keine Technologie verwenden, die Sie an einen bestimmten Anbieter bindet.

Dies kann manchmal sehr schwierig sein. .NET eignet sich beispielsweise hervorragend, um Logik und Methode für seinen MSSQL-Datenbankadapter bereitzustellen, für den es keine Entsprechungen in anderen Adaptern gibt. MSSQL scheint heute ein guter Plan zu sein, aber wird es dies auch für 20 Jahre bleiben? Wer weiß. Ein Beispiel dafür, wie Sie dies umgehen können, um eine Datenschicht zu erhalten, die von den anderen Teilen der Anwendung völlig getrennt ist. Im schlimmsten Fall müssen Sie dann nur die gesamte Datenschicht neu schreiben, der Rest Ihrer Anwendung bleibt davon unberührt.

Mit anderen Worten: Stellen Sie es sich wie ein Auto vor. Ihr Auto schafft es nicht 20 Jahre. Aber mit neuen Reifen, neuem Motor, neuem Getriebe, neuen Fenstern, neuer Elektronik usw. kann dasselbe Auto sehr lange unterwegs sein.

coteyr
quelle
2
"Wenn Sie jetzt zwischen Datenbanken wechseln müssten, könnten Sie das." Dies ist nahezu unmöglich, wenn Sie mehr als CRUD in einer Zeile gleichzeitig ausführen.
Jpmc26
1
Viele ORMs sind datenbankunabhängig. Ich konnte eines der Projekte, an denen ich arbeite, angeben, dass ich mühelos von SQLLite zu MySql und Postgre wechseln könnte.
Coteyr
5
Und ORMs sind keine guten Werkzeuge mehr für den Job, wenn Sie mehr als nur CRUD für eine einzelne Aufzeichnung gleichzeitig ausführen. Deshalb habe ich es qualifiziert. Ich habe es versucht. Mit zunehmender Komplexität von Abfragen werden selbst die besten ORMs schwieriger als nur das Schreiben der Abfrage, und selbst wenn Sie Ihre Abfrage erzwingen, werden Sie schnell feststellen, dass Sie datenbankspezifische Funktionen oder Optimierungen verwenden.
jpmc26
1
Definiere "komplex". War das eine Massenoperation? Enthielt es Fensterabfragen? Unterabfragen? CTEs? Gewerkschaften? Komplexe Gruppierungsbedingungen? Komplexe Mathematik für jede Zeile und die Aggregate? Wie viele Joins in einer einzelnen Abfrage? Welche Arten von Verknüpfungen? Wie viele Zeilen wurden gleichzeitig verarbeitet? Zugegeben, über eine einzelne Zeile CRUD (wohlgemerkt, das bedeutet eine Zeile pro Abfrage, nicht pro Webanforderung oder was auch immer.) Zu sagen , ist ein wenig übertrieben, aber der Weg, wann der ORM mehr Ärger macht, als er wert ist, ist viel kürzer als du denkst. Die Schritte zum Ausführen einer Abfrage sind sehr häufig datenbankspezifisch.
jpmc26
4
"Ist Ihre App-Datenbank agnostisch? Wenn Sie jetzt zwischen Datenbanken wechseln müssten, oder? Ist Ihre Logiksprache agnostisch. Wenn Sie die App jetzt in einer völlig neuen Sprache schreiben müssten, könnten Sie?" - Dies ist ein absolut schrecklicher Rat! Beschränken Sie sich nicht künstlich auf das, was Sie für den größten gemeinsamen Nenner von Programmiersprachen oder Datenbanken halten - dies wird Sie dazu zwingen, das Rad ständig neu zu erfinden. Versuchen Sie stattdessen, den NATÜRLICHEN Weg zu finden, um das gewünschte Verhalten in Ihrer Programmiersprache und Datenbank Ihrer Wahl auszudrücken.
fgp
12

Die Antworten von @amon und einigen anderen sind großartig, aber ich wollte vorschlagen, dass Sie dies aus einer anderen Perspektive betrachten.

Ich habe mit großen Herstellern und Regierungsbehörden zusammengearbeitet, die sich auf Programme oder Codebasen stützten, die seit mehr als 20 Jahren verwendet wurden, und alle hatten eines gemeinsam: Das Unternehmen kontrollierte die Hardware. Etwas zu haben, das über 20 Jahre läuft und erweiterbar ist, ist nicht schwierig, wenn Sie kontrollieren, worauf es läuft. Die Mitarbeiter dieser Gruppen entwickelten Code auf modernen Computern, die hunderte Male schneller waren als die Bereitstellungscomputer ... aber die Bereitstellungscomputer waren in der Zeit eingefroren.

Ihre Situation ist kompliziert, da Sie für eine Website zwei Umgebungen planen müssen - den Server und den Browser.

Wenn es um den Server geht, haben Sie zwei allgemeine Möglichkeiten:

  • Verlassen Sie sich auf das Betriebssystem, um verschiedene Supportfunktionen zu erhalten, die möglicherweise viel schneller sind, aber möglicherweise ein "Einfrieren der Zeit" des Betriebssystems erfordern. In diesem Fall sollten Sie einige Sicherungen der Betriebssysteminstallation für den Server vorbereiten. Wenn in 10 Jahren etwas abstürzt, möchten Sie niemanden dazu bringen, das Betriebssystem neu zu installieren oder den Code neu zu schreiben, damit er in einer anderen Umgebung funktioniert.

  • Verwenden Sie versionierte Bibliotheken in einer bestimmten Sprache / einem bestimmten Framework, die langsamer sind, jedoch in einer virtuellen Umgebung gepackt werden können und wahrscheinlich auf verschiedenen Betriebssystemen oder Architekturen ausgeführt werden.

Wenn es um den Browser geht, müssen Sie alles auf dem Server hosten (dh Sie können kein globales CDN zum Hosten von Dateien verwenden). Wir können davon ausgehen, dass zukünftige Browser weiterhin HTML und Javascript ausführen (zumindest aus Kompatibilitätsgründen), aber das ist wirklich eine Vermutung und Sie können das nicht kontrollieren.

Jonathan Vanasco
quelle
11
Sie müssen auch auf Sicherheit achten. Ein 20 Jahre altes nicht unterstütztes Betriebssystem wird wahrscheinlich voller Sicherheitslücken sein. Ich habe für eine Firma gearbeitet und dieses Problem geerbt. Regierungsbehörde, alte Betriebssysteme (zum Glück alle lange virtualisiert), aber dies war ein großes Problem, und ein Upgrade war nahezu unmöglich, da die Software komplett neu geschrieben werden musste (Hunderte von einzelnen Spaghetti-Code-PHP-Skripten, von denen jedes die Datenbankaufrufe aufwies fest codiert, mit veralteten Funktionen, die der neue Treiber nicht unterstützt (/ shudder).
Wenn Sie sich für das Betriebssystem entscheiden, können Sie bestenfalls hoffen, dass Sicherheitspatches angewendet wurden und dass zukünftige Betreuer in der Lage sein werden, die Netzwerkschicht abzudecken. Um zu planen, dass solche Dinge langfristig funktionieren (insbesondere, wenn kein großes Budget zur Verfügung steht, da das OP ein Student ist), müssen Sie grundsätzlich akzeptieren, dass Ihre Anwendung und Ihr Server letztendlich unsicher werden. Zum Beispiel wird es in 20 Jahren irgendwann bekannte Exploits für die SSL-Version auf dem Server geben ... aber dieses Betriebssystem ist möglicherweise in 10 Jahren nicht mehr mit OpenSSL-Versionen kompatibel. Hier geht es darum, Kompromisse zu minimieren.
Jonathan Vanasco
@FighterJet, Sie können immer eine Firewall auf einem unterstützten Betriebssystem ausführen, dann haben Sie abgesehen von SQL-Injects usw. nur wenige Risiken, für die Sie ohnehin codieren sollten.
Ian
@ Ian: Ich wünschte. Es gab eine Firewall. Aber ich habe den Code nicht geschrieben, sondern geerbt. Und ja, es gab Tausende von SQL-Sicherheitslücken, von denen ich mir wünschte, ich hätte sie beheben können, aber das eigentliche Problem war, dass der Code von einer bestimmten Version von PHP4 (die für immer veraltet und voller Sicherheitslücken ist) und von a abhing Eine bestimmte Version des Datenbanktreibers (was auf neueren Betriebssystemen nicht funktionierte), die ein Upgrade auf eine neuere Version der Datenbank verhinderte. Der Punkt ist, dass wir uns darauf verlassen, dass etwas gleich bleibt, was nicht immer funktioniert. Sagen wir einfach, ich bin froh, dass ich dort nicht mehr arbeite.
1
@FighterJet Das ist eigentlich ein wirklich gutes Beispiel dafür, worüber ich eigentlich reden wollte. Am Ende haben Sie Code geerbt, der nur auf einer bestimmten Version von PHP4 funktioniert, und einen Treiber, der nur auf einem bestimmten Betriebssystem ausgeführt wird. Sie können also den Server nicht aktualisieren. Ich würde niemandem raten, das zu tun, aber es passiert. -- viel. FWIW, ich stimme Ihnen zu, aber ich wollte, dass meine Antwort das Nachdenken über diese Art von Szenarien fördert und keine Empfehlung abgibt.
Jonathan Vanasco
6

Der Kern der meisten Anwendungen sind die Daten. Daten sind für immer. Code ist mehr entbehrlich , veränderbar, formbar. Die Daten müssen jedoch erhalten bleiben. Konzentrieren Sie sich also darauf, ein wirklich solides Datenmodell zu erstellen. Halten Sie das Schema und die Daten sauber. Erwarten Sie, dass eine neue Anwendung möglicherweise auf derselben Datenbank erstellt wird.

Wählen Sie eine Datenbank aus, die Integritätsbeschränkungen erzwingen kann. Nicht erzwungene Einschränkungen können im Laufe der Zeit verletzt werden. Niemand merkt es. Maximale Nutzung von Funktionen wie Fremdschlüsseln, eindeutigen Einschränkungen, Prüfeinschränkungen und möglicherweise Auslösern für die Validierung. Es gibt einige Tricks, mit denen indizierte Sichten missbraucht werden können, um Einschränkungen hinsichtlich der tabellenübergreifenden Eindeutigkeit zu erzwingen.

Vielleicht müssen Sie akzeptieren, dass die Anwendung irgendwann neu geschrieben wird. Wenn die Datenbank sauber ist, wird es wenig Migrationsarbeit geben. Migrationen sind sehr arbeits- und mängelintensiv.

Aus technologischer Sicht ist es möglicherweise eine gute Idee, den größten Teil der Anwendung auf dem Server und nicht in JavaScript-Form auf dem Client zu speichern. Dank der Virtualisierung können Sie wahrscheinlich über einen extrem langen Zeitraum dieselbe Anwendung in derselben Betriebssysteminstanz ausführen . Das ist nicht wirklich schön, aber es ist eine Garantie, dass die App in 20 Jahren ohne teure Wartungs- und Hardwarekosten funktioniert. Wenn Sie dies tun, haben Sie zumindest den sicheren und billigen Fallback, alten, funktionierenden Code weiter auszuführen.

Außerdem finde ich, dass einige Technologie-Stacks stabiler sind als andere . Ich würde sagen, dass .NET derzeit die bestmögliche Abwärtskompatibilität bietet. Microsoft meint es absolut ernst. Java und C / C ++ sind ebenfalls sehr stabil. Python hat bewiesen, dass es mit den wichtigsten Änderungen in Python 3 sehr instabil ist. JavaScript scheint mir eigentlich ziemlich stabil zu sein, da das Brechen des Webs für keinen Browser-Anbieter eine Option ist. Sie sollten sich jedoch wahrscheinlich nicht auf etwas Experimentelles oder Irres verlassen. ("Funky" wird definiert als "Ich weiß es, wenn ich es sehe").

usr
quelle
zum Thema .net Rückwärtskompatibilität - Ich glaube nicht, dass ich eine Java-App gesehen habe, die im Gegensatz dazu nach einer älteren Version von Java fragen würde. Das könnte sich mit Java 9 oder höher ändern, aber ich habe es noch nicht gesehen.
Eis
In der Praxis ist es erstaunlich kompatibel, und die Installation einer älteren Version nebeneinander ist kein Problem. Beachten Sie auch, dass die .NET-BCL meiner Schätzung nach 10-100x größer ist als die in Java integrierten Klassen.
USR
Abwärtskompatibilität bedeutet, dass keine ältere Version installiert werden muss. Aber wir schweifen von der ursprünglichen Frage ab, dies ist für OP nicht wirklich relevant.
Eis
0

Die anderen Antworten sind sinnvoll. Ich bin jedoch der Meinung, dass die Kommentare zur Client-Technologie zu kompliziert sind. Ich arbeite seit 16 Jahren als Entwickler. Meiner Erfahrung nach sollte es Ihnen gut gehen, solange Sie Ihren Client-Code intuitiv halten. Also keine "Hacks" mit Frames / Iframes usw .. Benutze nur gut definierte Funktionen in den Browsern.

Sie können in Browsern immer Kompatibilitätsmodi verwenden, damit diese weiterhin funktionieren.

Um das zu beweisen, habe ich erst vor ein paar Monaten einen Jahrtausend-Fehler im Javascript-Code für einen Kunden behoben, der seine Web-App seit 17 Jahren ausführt. Funktioniert immer noch auf aktuellen Computern, aktuellen Datenbanken und aktuellen Betriebssystemen.

Fazit: Halten Sie es einfach und sauber und Sie sollten in Ordnung sein.

Jonathan van de Veen
quelle
1
Frames und Iframes sind in der HTML-Spezifikation sehr gut definiert. Was macht sie ungeeignet?
curiousdannii
3
@curiousdannii: Es ist nicht so sehr die Verwendung von Iframes (Frames werden in HTML5 nicht mehr unterstützt), sondern die Verwendung von Frames und Iframes zum asynchronen Laden von Inhalten durch Skripten usw. Es kann jetzt großartig funktionieren, wird aber immer funktionieren Sicherheitsänderungen unterliegen.
Jonathan van de Veen
-2

Einige Axiome:

  • Die Wahrheit überlebt. In diesem Zusammenhang wären es Algorithmen und Datenmodelle - das, was wahrheitsgemäß das "Was" und das "Wie" Ihres Problemraums darstellt. Es besteht jedoch immer das Potenzial zur Verfeinerung und Verbesserung oder zur Entwicklung des Problems.
  • Sprachen entwickeln sich. Dies gilt für Computersprachen ebenso wie für natürliche Sprachen.
  • Alle Technologien sind anfällig für Veralterung. Es kann nur für einige Technologien länger dauern als für andere

Die stabilsten Technologien und Standards (die am wenigsten anfällig für Veralterung sind) sind in der Regel nicht proprietäre Technologien und Standards, die am weitesten verbreitet sind. Je breiter die Akzeptanz, desto größer ist die Trägheit gegen nahezu jede Form von Veränderung. Proprietäre "Standards" sind immer anfällig für das Glück und die Launen ihres Besitzers und der Konkurrenzkräfte.

Zwanzig Jahre sind eine sehr lange Zeit in der Computerindustrie. Fünf Jahre sind ein realistischeres Ziel. In fünf Jahren könnte das gesamte Problem, das Ihre Anwendung lösen soll, vollständig neu definiert werden.

Einige Beispiele zur Veranschaulichung:

C und C ++ gibt es schon lange. Sie haben Implementierungen auf nahezu jeder Plattform. C ++ entwickelt sich weiter, aber "universelle" Funktionen (die auf allen Plattformen verfügbar sind) werden garantiert nie veraltet sein.

Flash wurde fast ein universeller Standard, aber es ist proprietär. Unternehmensentscheidungen, es auf gängigen mobilen Plattformen nicht zu unterstützen, haben im Grunde genommen überall zum Scheitern verurteilt. Wenn Sie für das Web verfassen, möchten Sie, dass Ihre Inhalte auf allen Plattformen verfügbar sind. Sie möchten nicht den großen Markt verpassen, zu dem Mobile geworden ist.

WinTel (Windows / x86) ist zwar Eigentum von Microsoft und Intel, hat aber auf einer weniger als optimalen Plattform (16 Bit intern / 8 Bit extern 8088 gegenüber zeitgemäßem Apple Macintosh 32 Bit intern / 16 Bit extern 68000) und Erosion begonnen für Apple im Consumer-Markt bleibt eine De-facto-Wahl für Business-Plattformen. In all dieser Zeit (25 Jahre) hat die Verpflichtung zur Abwärtskompatibilität die zukünftige Entwicklung behindert und beträchtliche Zuversicht geweckt, dass das, was an der alten Box funktioniert hat, auch an der neuen funktioniert.

Abschließende Gedanken

JavaScript ist möglicherweise nicht die beste Wahl für die Implementierung von Geschäftslogik. Aus Gründen der Datenintegrität und -sicherheit sollte die Geschäftslogik auf dem Server ausgeführt werden. Daher sollte clientseitiges JavaScript auf das Verhalten der Benutzeroberfläche beschränkt sein. Selbst auf dem Server ist JavaScript möglicherweise nicht die beste Wahl. Bei kleinen Projekten ist es zwar einfacher zu arbeiten als bei anderen Stacks (Java oder C #), aber es fehlt die Formalität, die Ihnen hilft, besser organisierte Lösungen zu schreiben, wenn die Dinge komplexer werden.

Zenilogix
quelle