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

Il software di pianificazione 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 disponibile come estensione proprietaria per Internet Explorer 5, pubblicato nel 1999, 17 anni fa. Ci sono voluti circa 5 anni fino a quando non è diventato disponibile su tutti i principali browser. I 20 anni che stai cercando di guardare avanti sono solo le applicazioni web ricche di tempo sono persino esistite.

Da allora alcune cose sono sicuramente rimaste le stesse. C'è stato un strong sforzo di standardizzazione e la maggior parte dei browser è conforme ai vari standard coinvolti. Un sito web che ha funzionato su browser 15 anni fa funzionerà sempre allo stesso modo, a condizione che funzioni come target sottoinsieme comune di tutti i browser, non perché abbia utilizzato soluzioni alternative per ciascun browser.

Altre cose andavano e venivano, in particolare Flash. Flash ha avuto una serie di problemi che hanno portato alla sua scomparsa. Soprattutto, era controllato da una sola compagnia. 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:

• Semplifica: fai ciò che funziona adesso, senza dover ricorrere a soluzioni alternative. È probabile che questo comportamento rimanga disponibile a lungo nel futuro per motivi di compatibilità con le versioni precedenti.

• Evita di fare affidamento su tecnologie proprietarie e preferisci standard aperti.

Il mondo JavaScript oggi è relativamente instabile con un alto flusso di librerie e framework. Tuttavia, quasi nessuno di loro avrà importanza in 20 anni: l'unico "framework" che sono sicuro che sarà ancora usato da allora è Vanilla JS .

Se vuoi utilizzare una libreria o uno strumento perché rende lo sviluppo molto più semplice, assicurati 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 tuo repository di codice dovrebbe includere tutto il necessario per far funzionare il sistema. Qualunque cosa esterna è una dipendenza che potrebbe rompersi in futuro. Un modo interessante per testare questo è copiare il codice su una chiavetta, andare in un nuovo computer con un sistema operativo diverso, disconnetterlo da internet e vedere se è possibile far funzionare il frontend. Finché il tuo progetto è costituito da semplici HTML + CSS + JavaScript e forse anche da alcune librerie, probabilmente passerai.

Ciò che è ancora più importante del tuo codice che sopravvive 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 utilizzare, creare un sistema alternativo su di esso con una nuova tecnologia 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.
• Utilizza le funzionalità di base, non provare a spremere in quelle nuove e appariscenti.
• Preferisci semplice su intelligente .
• Accetta che la manutenibilità futura può andare a scapito di aspetti come le prestazioni. Ad esempio, potresti essere tentato di utilizzare stored procedure, ma queste potrebbero limitare la futura manutenibilità se impediscono a qualcuno di migrare il sistema a una soluzione di archiviazione più semplice.

Una volta ottenuto ciò, l'applicazione stessa a prova di futuro è più semplice, perché è un involucro attorno al modello di dati e può essere sostituita se, in 10 anni, nessuno usa più Javascript, per esempio, e devi migrare l'app per 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 ferma contro l'utilizzo di Oracle per un DB, citando un sacco di motivi perfettamente legittimi per cui Oracle è un problema con cui lavorare, ha una curva di apprendimento ripida e l'installazione in testa. Queste sono considerazioni valide per la scelta di Oracle come DB, ma nel nostro caso non stiamo cercando un DB di uso generale, ma uno di quelli in cui la preoccupazione principale è manutenibilità . Oracle è in giro dalla fine degli anni '70 e sarà probabilmente 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 costoso per molte aziende? Sicuro. Ma manterrà il tuo database in esecuzione per 20 anni ? Molto probabile.

La risposta precedente 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 funzionava attraverso i browser 15 anni fa funzionerà ancora lo stesso ", che è vero. Tuttavia, guarda i siti Web creati non quindici, ma dieci anni fa, che, una volta creati, hanno funzionato nella maggior parte dei browser per la maggior parte degli utenti. Oggi, gran parte degli utenti non sarà in grado di utilizzare tali siti Web, non perché i browser sono cambiati, ma perché i dispositivi hanno fatto. Questi siti apparirebbero terribili su piccoli schermi di dispositivi mobili e alla fine non funzionano affatto se gli sviluppatori decidessero di fare affidamento sull'evento click JavaScript, senza sapere che anche tap è importante.

• Ti stai concentrando su un argomento sbagliato.

  I cambiamenti tecnologici sono una cosa, ma una più importante è la modifica dei requisiti . Potrebbe essere necessario ridimensionare il prodotto, o potrebbe essere necessario disporre di funzionalità aggiuntive, oppure potrebbe essere necessario modificare le sue caratteristiche attuali.

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

  Se scrivi il tuo codice in un modo che può 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 porterà comunque la tua applicazione verso il basso, come una migrazione a un sistema operativo diverso, o anche una cosa semplice come crescita naturale dei dati.

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

Non hai intenzione di durare 20 anni. Chiaro e semplice. Invece tu sposti i tuoi obiettivi in compartimentalizzazione.

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

Ho avuto progetti live per 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 rendere conto per CORS.

Quindi quello che fai è assicurarsi che la tua logica sia ben separata e che tu eviti di utilizzare QUALSIASI tecnologia che ti blocchi in un fornitore specifico.

Questo può essere molto difficile a volte. .NET ad esempio è eccezionale nell'esporre la logica e il metodo per la sua scheda di database MSSQL che non ha equivalenti in altri adattatori. 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 completamente separato dalle altre parti dell'applicazione. Quindi, nel peggiore dei casi, devi solo riscrivere l'intero livello dati, il resto dell'applicazione rimane inalterato.

In altre parole, pensalo come una macchina. La tua macchina non arriverà a 20 anni. Ma con nuove gomme, nuovo motore, nuova trasmissione, nuove finestre, nuova elettronica, ecc. Quella stessa auto può essere sulla strada da molto tempo.

Le risposte di @amon e altre sono ottime, ma volevo suggerirti di guardare da un'altra prospettiva.

Ho lavorato con grandi produttori e agenzie governative che si affidavano a programmi o basi di codice utilizzati da oltre 20 anni e avevano tutti una cosa in comune: la società controllava l'hardware. Avere qualcosa in esecuzione ed estendibile per più di 20 anni non è difficile quando controlli ciò su cui gira. I dipendenti di questi gruppi hanno sviluppato codice su macchine moderne centinaia di volte più veloci 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:

• Affidatevi al sistema operativo per varie funzioni di supporto che possono essere molto più veloci, ma significa che il sistema operativo potrebbe aver bisogno di essere "congelato nel tempo". Se questo è il caso, ti consigliamo di preparare alcuni backup dell'installazione del sistema operativo per il server. Se qualcosa si blocca in 10 anni, non vuoi far impazzire qualcuno cercando di reinstallare il sistema operativo o riscrivere il codice per lavorare in un ambiente diverso.

• Utilizza le librerie versionate all'interno di un determinato linguaggio / framework, che sono più lente, ma possono essere impacchettate in un ambiente virtuale e probabilmente eseguite su diversi sistemi operativi o architetture.

Quando si tratta del browser, è necessario ospitare tutto sul server (ad esempio, non è possibile utilizzare una CDN globale per ospitare file). Possiamo supporre che i futuri browser continueranno a eseguire HTML e Javascript (almeno per compatibilità), ma è davvero un'ipotesi / ipotesi e non puoi controllarlo.

Il nucleo della maggior parte delle applicazioni sono i dati. I dati sono per sempre. Il codice è più spendibile , modificabile, malleabile. I dati devono essere preservati, però. Quindi concentrati sulla creazione di un modello di dati davvero solido. Mantieni lo schema e i dati puliti. Anticipa, che una nuova applicazione possa essere costruita sullo stesso database.

Scegli un database in grado di imporre vincoli di integrità. I vincoli non forzati tendono a essere violati col passare del tempo. Nessuno nota. Sfrutta al massimo le strutture come chiavi esterne, vincoli univoci, limiti di controllo e possibili trigger per la convalida. Ci sono alcuni trucchi per abusare delle viste indicizzate per far rispettare i vincoli di unicità delle tabelle incrociate.

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

Da un punto di vista della tecnologia potrebbe essere una buona idea mettere 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 a virtualizzazione . Questo non è bello ma è una garanzia che l'app funzionerà tra 20 anni senza costi di manutenzione e hardware costosi. Facendo questo hai almeno il sicuro ed economico ripiego di continuare a eseguire codice vecchio e funzionante.

Inoltre, trovo che alcuni stack tecnologici siano più stabili di altri . Direi che .NET ha attualmente la migliore storia di compatibilità con le versioni precedenti. Microsoft è morto sul serio. Anche Java e C / C ++ sono veramente stabili. Python ha dimostrato che è molto instabile con i cambiamenti di rottura di Python 3. JavaScript sembra effettivamente abbastanza stabile per me perché rompere il web non è un'opzione per qualsiasi venditore di browser. Probabilmente non dovresti affidarti a qualcosa di sperimentale o funky, comunque. ("Funky" viene definito come "lo so quando lo vedo").

Le altre risposte hanno senso. Tuttavia, ritengo che i commenti sulla tecnologia del cliente siano troppo complicati. Ho lavorato come sviluppatore negli ultimi 16 anni. Nella mia esperienza, finché si mantiene il codice client intuitivo, si dovrebbe andare bene. Quindi niente "hack" con frame / iframe, ecc. Utilizza solo funzioni ben definite nei browser.

Puoi sempre utilizzare le modalità di compatibilità nei browser per mantenerli funzionanti.

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: mantieni la semplicità e la pulizia e dovresti stare bene.

Alcuni assiomi:

• La verità sopravvive. In questo contesto, sarebbero algoritmi e modelli di dati, ciò che rappresenta in realtà il "cosa" e il "come" del tuo spazio problematico. Sebbene, ci sia sempre il potenziale per il perfezionamento e il miglioramento, o un'evoluzione del problema stesso.
• Le lingue evolvono. Questo vale per i linguaggi del computer come per le lingue naturali.
• Tutta la tecnologia è vulnerabile all'obsolescenza. Potrebbe richiedere più tempo per alcune tecnologie rispetto ad altri

Le tecnologie e gli standard più stabili (quelli meno vulnerabili all'obsolescenza) tendono ad essere quelli non proprietari e sono stati adottati più ampiamente. 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 della concorrenza.

Vent'anni sono molto tempo nell'industria dei computer. Cinque anni sono un obiettivo più realistico. Tra cinque anni, l'intero problema che la tua applicazione è destinata a 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 ad evolversi, ma le funzionalità "universali" (quelle disponibili su tutte le piattaforme) sono praticamente garantite per non essere mai deprecate.

Flash è diventato quasi uno standard universale, ma è proprietario. Le decisioni aziendali di non supportarlo su piattaforme mobili popolari lo hanno praticamente condannato ovunque: se sei autore del web, vuoi che i tuoi contenuti siano disponibili su tutte le piattaforme; non vuoi perdere il mercato principale in cui è diventato mobile.

WinTel (Windows / x86) nonostante sia proprietario di Microsoft e Intel, dopo aver iniziato su una piattaforma non ottimale (16 bit interni / 8 bit esterni 8088 vs Apple Macintosh contemporanei 32 bit interni / 16 bit esterni 68000) e l'erosione verso Apple nel mercato consumer rimane una scelta di fatto per le piattaforme di business. In tutto questo tempo (25 anni), l'impegno per la compatibilità con le versioni precedenti ha ostacolato lo sviluppo futuro e ha ispirato una notevole sicurezza sul fatto che ciò che ha funzionato sulla vecchia scatola continuerà a funzionare su quello nuovo.

Considerazioni finali

JavaScript potrebbe non essere la scelta migliore per implementare la logica di business. Per motivi di integrità e sicurezza dei dati, la logica di business 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ù semplice da utilizzare rispetto ad altri stack (Java o C #) per piccoli progetti, manca la formalità che può aiutarti a scrivere soluzioni migliori e più organizzate quando le cose diventano più complesse.