Sviluppo di applicazioni Web per una lunga durata (oltre 20 anni)

160

Attualmente sto sviluppando un'applicazione web per la pianificazione territoriale del governo. L'applicazione viene eseguita principalmente nel browser, utilizzando ajax per caricare e salvare i dati.

Farò lo sviluppo iniziale e poi mi laureo (è un lavoro da studente). Successivamente, il resto del team aggiungerà la funzionalità occasionale in base alle esigenze. Sanno come programmare, ma sono per lo più esperti di pianificazione del territorio.

Considerando il ritmo con cui cambiano le tecnologie Javascript, come posso scrivere codice che funzionerà ancora tra 20 anni? In particolare, quali librerie, tecnologie e idee progettuali dovrei usare (o evitare) per rendere il mio codice a prova di futuro?

javascript web-development future-proof

— Dan
fonte

94

Ho iniziato a programmare a Fortran alla fine del 1966, quindi ho avuto un sacco di tempo per pensare esattamente a quel tipo di problema. Se ti capita mai di trovare una risposta affidabile al 50%, per favore fatemelo sapere. Nel frattempo, pensa all'inevitabile quasi certa obsolescenza come "sicurezza del lavoro" :)

— John Forkosh,

11

Nulla dura per sempre nell'ingegneria del software. Solo HOST presso le banche e perché nessuno osa aggiornare tali sistemi critici. Bene, immagino che anche il programma in esecuzione nel Voyager conti.

— Laiv,

9

@Laiv Qualche tempo fa, ho lavorato su applicazioni di trasferimento di denaro per Bankers Trust utilizzando la messaggistica Swift in esecuzione su Vax / VMS. Alcuni anni dopo, Swift ha eliminato (fine vita) tutto il supporto VMS. Ragazzo, questo ha causato alcuni problemi ... e mi ha fornito un altro contratto alla BTCo. Come ho detto sopra, "sicurezza del lavoro" :). Comunque, il mio punto è che anche le applicazioni dei mercati finanziari critici non sono immuni all'obsolescenza.

— John Forkosh,

102

Che ne dici di "Scrivi codice che il prossimo sviluppatore può capire"? Se e quando il codice diventa obsoleto al punto che dovranno trovare un programmatore per aggiornarlo, lo scenario migliore è che capiranno cosa sta facendo il tuo codice (e forse perché determinate decisioni sono state prese).

— David Starkey,

38

Usa semplicemente il vecchio HTML, niente JS, niente plugin, niente di speciale. Se funziona in Lynx, è sempre valido.

— Gaio,

132

Pianificare un software per una tale durata è difficile, perché non sappiamo cosa riserva il futuro. Un po 'di contesto: Java è stato pubblicato nel 1995, 21 anni fa. XmlHttpRequest è diventato per la prima volta disponibile come estensione proprietaria di Internet Explorer 5, pubblicato nel 1999, 17 anni fa. Ci sono voluti circa 5 anni prima che diventasse disponibile su tutti i principali browser. I 20 anni che stai cercando di guardare al futuro sono quasi il tempo in cui sono persino esistite ricche applicazioni web.

Alcune cose sono rimaste sicuramente le stesse da allora. C'è stato un forte sforzo di standardizzazione e la maggior parte dei browser si conforma bene ai vari standard coinvolti. Un sito Web che ha funzionato su browser 15 anni fa funzionerà sempre allo stesso modo, a condizione che funzioni perché era destinato al sottoinsieme comune di tutti i browser, non perché utilizzava soluzioni alternative per ciascun browser.

Altre cose andavano e venivano, soprattutto Flash. Flash ebbe una varietà di problemi che portarono alla sua scomparsa. Ancora più importante, è stato controllato da una singola azienda. Invece della concorrenza all'interno della piattaforma Flash, c'era competizione tra Flash e HTML5 - e HTML5 ha vinto.

Da questa storia, possiamo raccogliere un paio di indizi:

Mantieni la semplicità: fai ciò che funziona in questo momento, senza dover usare soluzioni alternative. Questo comportamento probabilmente rimarrà disponibile a lungo in futuro per motivi di compatibilità con le versioni precedenti.
Evita di affidarti a tecnologie proprietarie e preferisci standard aperti.

Il mondo JavaScript oggi è relativamente volatile con un alto flusso di librerie e framework. Tuttavia, quasi nessuno di loro avrà importanza tra 20 anni - l'unico "quadro" di cui sono certo che sarà ancora utilizzato da allora è Vanilla JS .

Se si desidera utilizzare una libreria o uno strumento perché semplifica davvero molto lo sviluppo, assicurarsi innanzitutto che sia basato sugli standard ben supportati di oggi. È quindi necessario scaricare la libreria o lo strumento e includerlo con il codice sorgente. Il repository di codice dovrebbe includere tutto il necessario per rendere eseguibile il sistema. Qualsiasi cosa esterna è una dipendenza che potrebbe rompersi in futuro. Un modo interessante per testarlo è copiare il codice su una chiavetta USB, passare a un nuovo computer con un sistema operativo diverso, disconnetterlo da Internet e vedere se è possibile far funzionare il frontend. Fintanto che il tuo progetto è costituito da semplici HTML + CSS + JavaScript e forse da alcune librerie, probabilmente passerai.

— amon
fonte

4

Finora le applicazioni su larga scala non sono mantenibili in vanilla js. ES6 risolve già in qualche modo il problema, ma c'è una ragione per cui il flusso o TypeScript stanno guadagnando popolarità.

— Andy,

34

@DavidPacker Assolutamente, TypeScript ecc. Sono fantastici e facilitano lo sviluppo. Ma non appena introduco un processo di compilazione, tutti gli strumenti necessari per il processo di compilazione diventano dipendenze: NodeJS, Gulp, NPM: chi afferma che NPM sarà ancora online tra 20 anni? Dovrò eseguire il mio registro per essere sicuro. Questo non è impossibile. Ma a un certo punto, è meglio lasciar andare le cose che rendono lo sviluppo più semplice solo immediatamente, ma non a lungo termine.

— amon,

30

@DavidPacker Ci sono molti linguaggi dinamici e, sorprendentemente, molti sistemi di successo sono stati realizzati con Smalltalk, Ruby, Perl, Python, anche con PHP e JS. Mentre i linguaggi tipizzati staticamente tendono ad essere più mantenibili mentre i linguaggi dinamici tendono ad essere migliori per la prototipazione rapida, non è impossibile scrivere JS mantenibili. In assenza di un compilatore, un'abilità mediana elevata nel team, abilità artigianale e un'enfasi aggiuntiva sull'organizzazione chiara del codice diventano ancora più cruciali. Personalmente penso che i tipi rendano tutto più semplice, ma non sono proiettili d'argento.

— amon,

4

Ho appena letto "prendi usb e testa su macchina diversa"? Perché non semplicemente girare su virtualbox o semplicemente usare la modalità di navigazione in incognito (con ethX disabilitato).

— Kyslik,

5

Non sono sicuro che la vaniglia JS sarà una cosa sicura tra 20 anni. La sua storia è stata rocciosa e sperimentale, e ha raccolto una buona quantità di innesti lungo la strada, anche se è emerso come un linguaggio delizioso ed efficace (personalmente preferisco JavaScript o TypeScript me stesso). Non è difficile immaginare che i venditori potrebbero voler abbandonare una parte o tutta quella cruft, sia che significhi iniziare a offrire una nuova lingua alternativa, come sembra che Google stia proponendo con Dart, per quanto ciò non sembri essere andato da nessuna parte —O deprecando e quindi eliminando porzioni di JS.

— KRyan,

178

Ciò che è ancora più importante del fatto che il tuo codice sopravviva per 20 anni è che i tuoi dati sopravvivono per 20 anni. Le probabilità sono, questa è la cosa che vale la pena preservare. Se i tuoi dati sono facili da lavorare, costruire un sistema alternativo su di esso con una tecnologia più recente sarà facile.

Quindi inizia con un modello di dati chiaro e ben documentato.
Utilizzare un sistema di database ben supportato, come Oracle ^[1] o SQL Server.
Usa le funzionalità di base, non provare a comprimerne di nuove.
Preferisci semplice piuttosto che intelligente .
Accetta che la futura manutenibilità possa andare a scapito di aspetti come le prestazioni. Ad esempio, potresti essere tentato di utilizzare le procedure memorizzate, ma queste potrebbero limitare la manutenibilità futura se impediscono a qualcuno di migrare il sistema verso una soluzione di archiviazione più semplice.

Una volta ottenuto questo, l'app stessa per il futuro è più semplice, perché è un involucro attorno al modello di dati e può essere sostituita se, tra 10 anni, nessuno usa più Javascript, ad esempio, e devi migrare l'app su WASM o qualcosa del genere. Mantenere le cose modulari, meno interdipendenti, consente una manutenzione futura più semplice.

^[1] La maggior parte dei commenti a questa risposta prende una posizione forte contro l'utilizzo di Oracle per un DB, citando molte ragioni perfettamente legittime per cui Oracle è un problema con cui lavorare, ha una ripida curva di apprendimento e costi di installazione. Queste sono preoccupazioni del tutto valide quando si sceglie Oracle come DB, ma nel nostro caso non stiamo cercando un DB per scopi generali, ma uno in cui la preoccupazione principale è la manutenibilità . Oracle esiste dalla fine degli anni '70 e probabilmente sarà supportato per molti anni a venire, e c'è un enorme ecosistema di consulenti e opzioni di supporto che possono aiutarti a mantenerlo attivo. È un casino troppo caro per molte aziende? Sicuro. Ma manterrà il tuo database in esecuzione per 20 anni ? Verosimilmente.

— Avner Shahar-Kashtan
fonte

141

Mi dispiace, ma devo dirlo. Se usi Oracle, stai sparando a tutti i piedi per quanto riguarda "facile da lavorare". Oracle non è affatto facile da lavorare. Molte funzionalità che SQL Server, PostgreSQL e probabilmente anche MySQL rendono semplici, Oracle o flat out non ha o rende eccessivamente difficile. Non ho mai avuto così tanti stupidi problemi con altri DB quanti ne ho con Oracle; anche solo la configurazione del client è un enorme dolore nel culo. Anche cercare su Google è difficile. Se vuoi "lavorare facilmente", stai alla larga da Oracle.

— jpmc26,

4

+1 per mantenere i dati il più semplice possibile. Utilizzare SQL standard per questo, ad esempio utilizzare OUTER JOIN invece dell'operatore + Oracle specifico . Usa semplici layout di tabella. Non normalizzare i tuoi tavoli al livello massimo assoluto. Decidi se alcune tabelle possono avere dati ridondanti o se devi davvero creare una nuova tabella in modo che ogni valore esista una sola volta. Le procedure memorizzate sono specifiche del fornitore ? Se sì, non usarli. Non utilizzare la funzione hottst della tua lingua corrente: ho visto più programmi COBOL senza funzionalità OOP, quindi con loro. E questo è assolutamente ok.

— some_coder

3

@ jpmc26 Concordo con i tuoi sentimenti su Oracle, ma come ho detto, "facile da lavorare" non è necessariamente il requisito principale qui. Preferisco una piattaforma solidamente supportata qui, anche se è una seccatura con cui lavorare. Perché se ammortizzato in 20 anni, non è poi così male.

— Avner Shahar-Kashtan,

8

Evita davvero Oracle. L'unico DB esistente oggi che probabilmente non sembrerà una cattiva scelta in 20 anni è Postgresql.

— Giosuè,

3

Vorrei aggiungere che sono preferibili ottimi DBMS open source perché ci sono buone probabilità che non muoiano. Se Oracle smette di fare soldi in 10 anni, poi in 11 sparirà. PostreSQL sembra il miglior cavallo su cui scommettere.

— Shautieh,

36

La precedente risposta di Amon è ottima, ma ci sono altri due punti che non sono stati menzionati:

Non si tratta solo di browser; anche i dispositivi contano.

amon menziona il fatto che un "sito web che ha funzionato su browser 15 anni fa funzionerà ancora allo stesso modo" , il che è vero. Tuttavia, guarda i siti Web creati non quindici, ma dieci anni fa, che, una volta creati, funzionavano nella maggior parte dei browser per la maggior parte degli utenti. Oggi, gran parte degli utenti non sarà in grado di utilizzare quei siti Web, non perché i browser sono cambiati, ma perché i dispositivi lo hanno fatto. Quei siti Web apparirebbero terribili su piccoli schermi di dispositivi mobili e alla fine non funzionerebbero affatto se gli sviluppatori decidessero di fare affidamento clicksull'evento JavaScript , senza sapere che l' tapevento è anche importante.
Ti stai concentrando su un argomento sbagliato.

I cambiamenti tecnologici sono una cosa, ma uno più importante sono i cambiamenti dei requisiti . Potrebbe essere necessario ridimensionare il prodotto o potrebbe essere necessario disporre di funzionalità aggiuntive o potrebbe essere necessario modificare le funzionalità correnti.

Non importa cosa accadrà ai browser, ai dispositivi, al W3C o ... qualunque cosa.

Se scrivi il tuo codice in modo che possa essere refactored , il prodotto si evolverà con la tecnologia.

Se scrivi il tuo codice in un modo in cui nessuno può comprenderlo e mantenerlo, la tecnologia non ha importanza: qualsiasi cambiamento ambientale ridurrà comunque la tua applicazione, come una migrazione a un sistema operativo diverso o anche una cosa semplice come la crescita naturale dei dati .

Ad esempio, lavoro nello sviluppo di software da dieci anni. Tra le dozzine e le decine di progetti, ce n'erano solo due che ho deciso di cambiare a causa della tecnologia , più precisamente perché PHP si è evoluto molto negli ultimi dieci anni. Non è stata nemmeno una decisione del cliente: non gliene importerebbe di meno se il sito utilizza gli spazi dei nomi o le chiusure di PHP. Tuttavia, le modifiche relative a nuovi requisiti e scalabilità, ce ne sono state molte!

— Arseni Mourzenko
fonte

4

L'adozione di schermi di dimensioni diverse è un problema generale. Al momento il mobile è la cosa più gettonata, ma se stai guardando questo sito Web in una finestra del browser a schermo intero su uno schermo con una risoluzione sufficiente, c'è molto spazio vuoto (sprecato). La modifica dei layout e il modo in cui le informazioni vengono presentate per utilizzare al meglio i pixel disponibili non sono mai avvenute in modo intelligente. Il mobile ha reso questo ovvio. Ma pensare nella direzione opposta potrebbe essere più importante per la domanda in corso.

— null,

9

@null: mentre sono d'accordo con il tuo commento, i siti Web StackExchange potrebbero non essere la migliore illustrazione del tuo punto. Dati i dati da visualizzare, credo che i progettisti / sviluppatori StackExchange abbiano fatto un ottimo lavoro nel visualizzarli come devono essere visualizzati, anche su monitor di grandi dimensioni. Non puoi allargare la colonna principale, perché il testo diventerebbe molto più difficile da leggere e non puoi usare più colonne perché non sembrerà carino per brevi domande e risposte.

— Arseni Mourzenko,

Un altro buon esempio è l'evento 'hover' che veniva spesso utilizzato nei sistemi di menu. Molti di questi menu falliscono miseramente con i dispositivi touch.

— Giusto

Hai il 110% (o più) di ragione sui dispositivi e posso fornirti esempi vecchi di decenni. Alla fine degli anni '80 ho lavorato su applicazioni CICS in esecuzione su mainframe IBM e terminali sincroni 3270. La regione CICS è in qualche modo analoga alle app sul lato server, che inviano schermate di dati alla volta ai terminali sincroni, che sono quindi analoghi ai browser dedicati per dispositivi. E la programmazione CICS era forse l'80% di Cobol, il 20% di PL / 1. Entrambe queste lingue sono per lo più obsolete al giorno d'oggi, e la comparsa di workstation Unix (Sun e Apollo) nei primi anni '90 ha praticamente ucciso del tutto il CICS

— John Forkosh,

31

Non prevedi di durare 20 anni. Chiaro e semplice. Invece sposta i tuoi obiettivi verso la compartimentazione.

Il database delle tue app è indipendente? Se dovessi cambiare banca dati in questo momento, potresti farlo. Il tuo linguaggio logico è agnostico. Se dovessi riscrivere l'app in una lingua completamente nuova in questo momento, potresti? Stai seguendo buone linee guida di progettazione come SRP e DRY?

Ho progetti in corso da più di 20 anni e posso dirti che le cose cambiano. Come i pop-up. 20 anni fa potevi contare su un pop-up, oggi non puoi. XSS non era una cosa 20 anni fa, ora devi tenere conto di CORS.

Quindi, ciò che fai è assicurarti che la tua logica sia ben separata e che eviti di utilizzare QUALSIASI tecnologia che ti blocchi a un fornitore specifico.

Questo può essere molto complicato a volte. .NET, ad esempio, è perfetto per esporre la logica e il metodo per la sua scheda di database MSSQL che non ha equivalenti in altre schede. MSSQL potrebbe sembrare un buon piano oggi, ma rimarrà tale per 20 anni? Chissà. Un esempio di come aggirare questo per avere un livello dati totalmente separato dalle altre parti dell'applicazione. Quindi, nel peggiore dei casi, devi solo riscrivere l'intero livello dati, il resto dell'applicazione rimarrà inalterato.

In altre parole, pensala come un'auto. La tua auto non ce la farà 20 anni. Ma, con pneumatici nuovi, nuovo motore, nuova trasmissione, nuovi finestrini, nuova elettronica, ecc. Quella stessa macchina può essere sulla strada per molto tempo.

— coteyr
fonte

2

"Se dovessi cambiare subito le basi di dati, potresti" Questo è quasi impossibile da realizzare se fai qualcosa di più di CRUD su una riga alla volta.

— jpmc26,

1

Molti ORM sono indipendenti dal database. Potrei dare uno qualsiasi dei progetti a cui sto lavorando su Gaurentee che potrei passare da SQLLite a MySql e Postgre senza alcuno sforzo.

— coteyr,

5

E gli ORM cessano di essere ottimi strumenti per il lavoro quando si fa più del semplice CRUD su un singolo record alla volta. Ecco perché l'ho qualificato. Ho provato. Con l'aumentare della complessità della query, anche i migliori ORM diventano più problematici della semplice scrittura della query e, anche se imposti la query in essi, ti ritrovi abbastanza rapidamente a utilizzare funzionalità o ottimizzazioni specifiche del database.

— jpmc26,

1

Definire "complesso". È stata un'operazione di massa? Includeva le domande sulla finestra? Sottointerrogazioni? CTE? I sindacati? Condizioni di raggruppamento complesse? Complessa matematica su ogni riga e gli aggregati? Quanti join in una singola query? Che tipo di join? Quante righe sono state elaborate contemporaneamente? Certo, dire qualsiasi cosa su CRUD a riga singola (intendiamoci, questo significa una riga per query, non per richiesta web o altro.) È un po 'di iperbole, ma la strada verso quando l'ORM diventa più problemi di quanto valga è molto più breve di tu pensi. E i passaggi per eseguire correttamente una query sono molto specifici per il database.

— jpmc26,

4

"Il database delle tue app è agnostico? Se dovessi cambiare subito le basi di dati, vero? Il tuo linguaggio logico è agnostico. Se dovessi riscrivere l'app in una lingua completamente nuova in questo momento, vero?" - Questo è ASSOLUTAMENTE TERRIBILE consiglio! Non limitarti artificialmente a qualunque cosa tu pensi sia il più grande denominatore comune di linguaggi di programmazione o database: questo ti costringerà a reinventare costantemente la ruota. Invece, prova a trovare il modo NATURALE per esprimere il comportamento desiderato nel tuo linguaggio di programmazione e database di tua scelta.

— fgp,

12

Le risposte di @amon e di alcuni altri sono fantastiche, ma volevo suggerirti di guardarlo da un'altra prospettiva.

Ho lavorato con grandi produttori e agenzie governative che si affidavano a programmi o basi di codice che erano stati utilizzati per oltre 20 anni e avevano tutti una cosa in comune: la società controllava l'hardware. Avere qualcosa in esecuzione ed estendibile per oltre 20 anni non è difficile quando controlli ciò su cui funziona. I dipendenti di questi gruppi hanno sviluppato codice su macchine moderne centinaia di volte più veloce delle macchine di distribuzione ... ma le macchine di distribuzione sono state congelate nel tempo.

La tua situazione è complicata, perché un sito Web significa che devi pianificare due ambienti: il server e il browser.

Quando si tratta del server, hai due scelte generali:

Affidati al sistema operativo per varie funzioni di supporto che potrebbero essere molto più veloci, ma potrebbe essere necessario "bloccare il sistema operativo nel tempo". In tal caso, ti consigliamo di preparare alcuni backup dell'installazione del sistema operativo per il server. Se qualcosa si arresta in modo anomalo in 10 anni, non vuoi far impazzire qualcuno cercando di reinstallare il sistema operativo o riscrivere il codice per lavorare in un ambiente diverso.
Utilizzare librerie con versione all'interno di un determinato linguaggio / framework, che sono più lente, ma possono essere impacchettate in un ambiente virtuale e probabilmente eseguite su sistemi operativi o architetture differenti.

Quando si tratta del browser, è necessario ospitare tutto sul server (ovvero non è possibile utilizzare un CDN globale per ospitare i file). Possiamo presumere che i futuri browser eseguiranno comunque HTML e Javascript (almeno per compatibilità), ma è davvero una supposizione / ipotesi e non puoi controllarlo.

— Jonathan Vanasco
fonte

11

Devi considerare anche la sicurezza. Un sistema operativo non supportato di 20 anni sarà probabilmente pieno di falle nella sicurezza. Ho lavorato per un'azienda e ho ereditato questo problema. Agenzia governativa, antichi sistemi operativi (tutti a lungo virtualizzati, per fortuna), ma questo era un grosso problema e l'aggiornamento era quasi impossibile a causa della necessità di riscrivere completamente il software (centinaia di singoli script PHP spaghetti-code, ognuno dei quali aveva chiamate al database hardcoded, utilizzando funzioni deprecate che il nuovo driver non supportava / shudder).

Se segui il percorso del sistema operativo, nella migliore delle ipotesi puoi sperare che siano state applicate le patch di sicurezza e che i futuri manutentori saranno in grado di proteggere le cose a livello di rete. Per pianificare che le cose funzionino in questo modo a lungo termine (specialmente in assenza di un budget elevato, poiché l'OP è uno studente), in pratica è necessario accettare che l'applicazione e il server diventino insicuri. Ad esempio, tra 20 anni alla fine ci saranno exploit noti per la versione SSL sul server ... ma quel sistema operativo potrebbe non essere compatibile con le versioni di openssl in 10 anni. Si tratta solo di ridurre al minimo i compromessi.

— Jonathan Vanasco,

@FighterJet, puoi sempre eseguire un firewall su un sistema operativo supportato, quindi hai pochi rischi a parte gli iniezioni SQL ecc. Che dovresti comunque aver codificato.

— Ian,

@Ian: vorrei. C'era un firewall. Ma non ho scritto il codice, l'ho ereditato. E sì, ci sono state migliaia di vulnerabilità SQL che vorrei poter risolvere, ma il vero problema era che il codice dipendeva da una particolare versione di PHP4 (che è stata deprecata per sempre ed è piena zeppa di falle di sicurezza) e un una particolare versione del driver del database (che non funzionava su sistemi operativi più recenti), che ci impediva di passare a una versione più recente del database ... il punto è che fare affidamento su qualcosa che rimanga uguale non sempre funziona. Diciamo solo che sono contento di non lavorare più lì.

1

@FighterJet Questo è in realtà un ottimo esempio di ciò di cui avevo intenzione di parlare. Hai finito per ereditare il codice che funziona solo su una particolare versione di PHP4 e un driver che gira solo su un particolare sistema operativo ... quindi non puoi aggiornare il server. Non raccomanderei a nessuno di farlo, ma succede. -- Un sacco. FWIW, sono d'accordo con te, ma volevo che la mia risposta incoraggiasse a pensare a quel tipo di scenari, non a formulare una raccomandazione.

— Jonathan Vanasco,

6

Il cuore della maggior parte delle applicazioni sono i dati. I dati sono per sempre. Il codice è più sacrificabile , modificabile, malleabile. Tuttavia, i dati devono essere conservati. Quindi concentrati sulla creazione di un modello di dati davvero solido. Mantieni pulito lo schema e i dati. Anticipare che un'applicazione nuova potrebbe essere costruita sullo stesso database.

Scegli un database in grado di imporre vincoli di integrità. I vincoli non forzati tendono a essere violati con il passare del tempo. Nessuno se ne accorge. Sfruttate al massimo strutture come chiavi esterne, vincoli univoci, vincoli di verifica ed eventualmente trigger per la convalida. Esistono alcuni trucchi per abusare delle visualizzazioni indicizzate per imporre vincoli di unicità tra tabelle.

Quindi forse devi accettare che l'applicazione verrà riscritta in qualche momento. Se il database è pulito, ci sarà poco lavoro di migrazione. Le migrazioni sono estremamente costose in termini di manodopera e difetti causati.

Dal punto di vista tecnologico, potrebbe essere una buona idea inserire la maggior parte dell'applicazione sul server e non in un modulo JavaScript sul client. Probabilmente sarai in grado di eseguire la stessa applicazione nella stessa istanza del sistema operativo per un tempo estremamente lungo grazie alla virtualizzazione . Non è davvero bello, ma è una garanzia che l'app funzionerà tra 20 anni senza costosi costi di manutenzione e hardware. In questo modo hai almeno il fallback sicuro ed economico di continuare a eseguire il vecchio codice funzionante.

Inoltre, trovo che alcuni stack tecnologici siano più stabili di altri . Direi che .NET ha attualmente la migliore storia di compatibilità all'indietro possibile. Microsoft è seriamente intenzionata. Anche Java e C / C ++ sono davvero stabili. Python ha dimostrato di essere molto instabile con le modifiche di Python 3. JavaScript in realtà sembra abbastanza stabile per me perché rompere il web non è un'opzione per qualsiasi fornitore di browser. Tuttavia, probabilmente non dovresti fare affidamento su nulla di sperimentale o funky. ("Funky" viene definito come "Lo so quando lo vedo").

— usr
fonte

sulla storia di compatibilità con le versioni precedenti di .net - Non credo di aver visto un'app Java che chiedesse una versione precedente di Java, come al contrario. Ciò potrebbe cambiare con Java 9 o successivo, ma non l'ho ancora visto accadere.

— Eis,

È incredibilmente compatibile nella pratica e l'installazione di una versione precedente fianco a fianco non è un problema. Si noti inoltre che .NET BCL è, a mio avviso, 10-100x più grande delle classi integrate Java.

— usr

compatibilità con le versioni precedenti significa che non dovrebbe essere necessario installare anche una versione precedente. Ma stiamo divagando dalla domanda originale, questo non è realmente rilevante per OP.

— eis,

0

Le altre risposte hanno un senso. Tuttavia, ritengo che i commenti sulla tecnologia client stiano complicando le cose. Ho lavorato come sviluppatore negli ultimi 16 anni. Nella mia esperienza, fintanto che mantieni intuitivo il codice del tuo cliente, dovresti andare bene. Quindi niente "hack" con frame / iframe, ecc. Usa solo funzioni ben definite nei browser.

Puoi sempre utilizzare le modalità di compatibilità nei browser per farli funzionare.

Per dimostrare il mio punto, solo pochi mesi fa ho corretto un bug del millennio nel codice javascript per un cliente, che ha eseguito la sua app Web per 17 anni. Funziona ancora su macchine recenti, database recenti, sistema operativo recente.

Conclusione: mantienilo semplice e pulito e dovresti stare bene.

— Jonathan van de Veen
fonte

1

Frame e iframe sono molto ben definiti nelle specifiche HTML. Cosa li rende inadatti?

— curiousdannii,

3

@curiousdannii: Non è tanto l'uso di iframe (i frame non sono più supportati in HTML5), quanto l'uso di frame e iframe per caricare i contenuti in modo asincrono tramite script, ecc. Può funzionare benissimo in questo momento, ma funzionerà sempre essere soggetto a modifiche di sicurezza.

— Jonathan van de Veen,

-2

Alcuni assiomi:

La verità sopravvive. In questo contesto, si tratterebbe di algoritmi e modelli di dati - ciò che rappresenta veramente il "che cosa" e il "come" del tuo spazio problematico. Sebbene, ci sia sempre il potenziale per raffinamento e miglioramento, o un'evoluzione del problema stesso.
Le lingue si evolvono. Questo vale tanto per i linguaggi informatici quanto per i linguaggi naturali.
Tutta la tecnologia è vulnerabile all'obsolescenza. Potrebbe richiedere più tempo per alcune tecnologie rispetto ad altre

Le tecnologie e gli standard più stabili (quelli meno vulnerabili all'obsolescenza) tendono ad essere quelli che non sono proprietari e sono stati ampiamente adottati. Più ampia è l'adozione, maggiore è l'inerzia contro quasi ogni forma di cambiamento. Gli "standard" proprietari sono sempre vulnerabili alle fortune e ai capricci del loro proprietario e delle forze competitive.

Vent'anni è un periodo molto lungo nel settore informatico. Cinque anni sono un obiettivo più realistico. Tra cinque anni, l'intero problema che la tua applicazione dovrebbe risolvere potrebbe essere completamente ridefinito.

Alcuni esempi per illustrare:

C e C ++ sono in circolazione da molto tempo. Hanno implementazioni su quasi tutte le piattaforme. Il C ++ continua a evolversi, ma le funzionalità "universali" (quelle disponibili su tutte le piattaforme) sono praticamente garantite per non essere mai deprecate.

Flash è quasi diventato uno standard universale, ma è proprietario. Le decisioni aziendali di non supportarlo sulle piattaforme mobili più diffuse lo hanno praticamente condannato ovunque: se stai scrivendo per il Web, vuoi che i tuoi contenuti siano disponibili su tutte le piattaforme; non vuoi perderti il principale mercato mobile è diventato.

WinTel (Windows / x86) nonostante sia proprietario di Microsoft e Intel, avendo iniziato su una piattaforma non ottimale (16 bit interna / 8 bit esterna 8088 rispetto alla contemporanea Apple Macintosh 32 bit interna / 16 bit esterna 68000) ed erosione per Apple nel mercato consumer rimane di fatto una scelta per le piattaforme di business. In tutto quel tempo (25 anni), un impegno per la retrocompatibilità ha sia ostacolato lo sviluppo futuro sia ispirato una notevole fiducia che ciò che ha funzionato sulla vecchia scatola continuerà a funzionare su quella nuova.

Pensieri finali

JavaScript potrebbe non essere la scelta migliore per l'implementazione della logica aziendale. Per motivi di integrità e sicurezza dei dati, la logica aziendale deve essere eseguita sul server, pertanto JavaScript sul lato client deve essere limitato al comportamento dell'interfaccia utente. Anche sul server, JavaScript potrebbe non essere la scelta migliore. Sebbene sia più facile da lavorare rispetto ad altri stack (Java o C #) per piccoli progetti, manca della formalità che può aiutarti a scrivere soluzioni migliori e più organizzate quando le cose diventano più complesse.

— Zenilogix
fonte