Determinare se il linguaggio / quadro / tecnologia è "a prova di futuro"

Sono uno sviluppatore di PHP e di recente ho iniziato a lavorare con CodeIgniter. Sembra che ogni volta che cerco qualcosa di correlato a CodeIgniter, i post del blog e quelli che non sono di solito del '09 o '10, quindi mi viene in mente, CodeIgniter è ancora rilevante e lo sarà in futuro? C'è un altro quadro che sta prendendo posto?

Lo stesso vale per altre lingue e framework. A che punto abbandoni l'apprendimento di determinate lingue o framework? C'è un modo semplice per trovare quelli che stanno emergendo e che vale la pena raccogliere?

Non è una scienza esatta, quindi non aspettarti di essere in grado di prevedere con certezza le tendenze future nel panorama tecnologico più di 5 anni.

Ma vorrei cercare tutto quanto segue:

• Base installata : una base installata più grande significa che molte aziende continueranno a investire nella tecnologia e nella sua manutenzione, il che significa che gli sviluppatori dovranno lavorare con la tecnologia. Ne consegue un ciclo positivo. Ad esempio Java, come COBOL prima, non se ne andrà da molto tempo.
• Ampio supporto del settore - ci sono più attori del settore di grande nome che supportano la tecnologia? Solo un backer impegnato è un segnale di avvertimento: potrebbe essere eliminato o messo da parte in qualsiasi momento con un singolo cambio di strategia.
• Open source : i principali prodotti open source hanno dimostrato di essere scommesse a lungo termine estremamente buone (ad esempio Linux, Apache, Red Hat, JBoss, Eclipse ....). D'altra parte, i prodotti proprietari sono in qualche modo per capriccio di un singolo fornitore in cui sei a rischio di interruzione / aumento dei prezzi / tentativi di forzare a migrare verso la "prossima grande cosa".
• Qualità : i prodotti di alta qualità vivranno semplicemente più a lungo perché le persone vorranno usarli piuttosto che passare a qualcos'altro. Al contrario, i prodotti di bassa qualità verranno abbandonati non appena arriverà qualcosa di meglio.
• Innovazione : la tecnologia è all'avanguardia dell'innovazione? In tal caso, è probabile che ottenga l'adozione e il supporto tra le aziende e gli utenti più innovativi. Questo alla fine inizierà a diventare mainstream (direi che nuove lingue come Scala e Clojure per esempio sono in questa categoria)
• Comunità : esiste una comunità positiva, aperta, pragmatica, impegnata e disponibile attorno alla tecnologia? Queste sono le persone che alla fine garantiranno il suo futuro .....

Non c'è modo di sapere se qualcosa sarà una prova futura su cui preferirei concentrarmi se la tecnologia mi aiuta a risolvere il problema che ho oggi. Abbandoneresti l'apprendimento di una determinata lingua o framework quando non funziona più per risolvere i tuoi problemi.

Essere coinvolti nella comunità che rappresenta ciò che stai facendo e puoi avere un buon senso su ciò che va e viene, ma anche allora preferirei passare il mio tempo con lo strumento migliore per il lavoro che non è caldo o ciò che penso sarà caldo un anno o due da adesso.

Non c'è modo di determinare definitivamente se qualcosa è una prova futura. Il più vicino che puoi venire è determinare il livello di attività attorno a un particolare linguaggio o framework - se c'è molta attività di sviluppo, di solito è un buon segno che il linguaggio / framework sta diventando popolare e sarà praticabile per un po ' . L'inverso indica che c'è meno eccitazione e che il supporto (tramite i forum degli sviluppatori) potrebbe essere più difficile da trovare.

Finché il tuo linguaggio / quadro di scelta risolve il problema che stai cercando di risolvere, non dovresti preoccuparti di essere a prova di futuro, a meno che tu non stia chiaramente lavorando con una tecnologia morente. La tecnologia continua a cambiare: una cosa che puoi fare è tenere traccia delle tendenze del settore. L'apprendimento di nuovi linguaggi / framework di programmazione, come indicato in questo thread , può aiutarti a tenere il passo con le tendenze e ti dà l'opportunità di valutare continuamente nuovi strumenti.

"Futureproof-iness" riguarda tanto la forza di volontà e la testardaggine quanto le preoccupazioni più pragmatiche.

Un esempio estremo è questo . Sparkle Filters IS STILL RUNNING un computer IBM 402 della fine degli anni '40 come sistema di contabilità. Questa è una macchina che è programmata usando spine elettriche anziché "file".

Personalmente ho avuto esperienza con una società che mantiene ancora macchine basate su MS-DOS all'interno di strumenti specializzati progettati per funzionare per decenni. Ho persino demolito un PDP operativo nel 1997.

Direi che se la tua azienda ricevesse una visita dal museo di storia del computer, come ha fatto Sparkle Filters, ciò significherebbe che tu (o i tuoi antenati) avete "con successo" il sistema a prova di futuro!

Posso rispondere se una particolare tecnologia è a prova di futuro - la risposta è quasi certamente no, dal momento che non hai fissato un calendario su questo.

Per rendere rispondibile a questa domanda dovrai aggiungere ulteriori dettagli ai requisiti. Per esempio:

• Di che tempi stiamo parlando - 1 anno, 3 anni, 5+ anni?
• Quale sarebbe il costo di scegliere qualcosa che non esiste tra 5 anni?
• Quali benefici otterrai dalla scelta di un'opzione meno "sicura" e i benefici superano i rischi?

La scelta di un linguaggio / quadro / tecnologia fa davvero parte della gestione del rischio nel progetto. Come per tutti i rischi, dovrai prendere in considerazione una serie di fattori (sto cercando di mantenerlo breve) e quindi adottare delle misure per ridurlo a un livello adeguato alla situazione attuale.

Come con la maggior parte delle cose nella vita, l'attività che comporta il rischio più basso potrebbe in realtà non essere la scelta migliore.

In breve, con quanta incertezza sei disposto a convivere rispetto ai benefici che otterrai dal tempo di vita previsto del progetto.

Più a lungo vuoi guardare al futuro, meno certezza ci sarà. Se ad esempio sei soddisfatto solo di preoccuparti solo dei prossimi 2 anni, la tua scelta sarà molto più facile da fare (e ti lascerà molte più opzioni aperte) rispetto a scegliere qualcosa che deve essere in giro per i prossimi 10 anni.

Ci sono così tanti fattori che direi che è impossibile. Tra le cose che potrebbero andare male sono: -

• Moda. Le persone perdono interesse e rivolgono l'attenzione su una nuova piattaforma più carina. Perl aveva quasi il monopolio delle applicazioni web intorno al 2000. Ora è appena menzionato.
• Quota di mercato dei venditori. circa 2000 avresti pensato che C ++ / Sun Solaris fosse buono fino all'anno 3000.
• Shenanigans corporativi. Un paio di anni fa avrei scelto Java come piattaforma a prova di futuro. Con ORACLE il copyright dell'API ecc. Penso che vedrò un passaggio ad un altro framework linguistico, vorrei solo sapere quale.
• Fine della strada. Sto pensando a cose come Visual Basic che dopo una lunga e onorevole storia non può più essere allungata per adattarsi alle ultime idee nello sviluppo del software.
• Il perdente vince. PHP (che mi piace) non avrebbe vinto e non avrebbe mai vinto concorsi di bellezza tra gli sviluppatori, ma è emerso come il re indiscusso del web. Quando ho scritto per la prima volta un po 'di php nel 2004, non l'avrei mai sostenuto come la lingua francese dello sviluppo web.
• I brutti anatroccoli. Javascript senza cambiare un singolo pezzo di sintassi o aggiungere una singola API, improvvisamente è passato da un linguaggio di scripting hokey che banner fastidiosi animati aggiungono al pezzo centrale di WEB 2.0.

Alla fine non importa molto. CodeIgniter funziona per te e offre ciò che desideri. Niente di ciò che farai smetterà di funzionare perché i post sul blog sono vecchi o il tasso di rilascio è rallentato. Quindi il mio consiglio sarebbe di usare ciò che funziona ora e di affrontare il futuro quando arriverà.

Un framework PHP, Symfony, lo ha spiegato perfettamente sul loro sito .

10 criteri per la scelta del framework corretto

Stai facendo progressi e questa è una buona cosa! Sai già che utilizzerai un framework per sviluppare il tuo sito o la tua applicazione. Ma quale? Ecco una lista di controllo che puoi usare per evitare di fare un errore:

1.Popolarità e dimensione della comunità

Più è noto e riconosciuto il framework, più sarà "vivo", in evoluzione e completo: nuove idee, il numero e la qualità dei plug-in, ecc.

2.Philosophy

Questa è la vera essenza del framework: è un criterio fondamentale per garantire che soddisfi le tue esigenze. Uno strumento sviluppato da professionisti per le proprie esigenze soddisferà ovviamente le esigenze di altri professionisti.

3.Sustainability

Prima di scegliere un framework, assicurati che sia in grado di tenerti aggiornato per tutta la durata. Ciò semplifica sia la manutenzione che l'aggiornamento delle applicazioni.

4.Support

Un altro criterio da non trascurare è la facilità di trovare risposte alle tue domande e ottenere aiuto. Identifica il supporto disponibile: dall'editore. Da una comunità (mailing list, IRC, ecc.)? Dalle società di servizi (sviluppo, supporto, formazione)?

5.Technique

Per evitare di rimanere intrappolati in un labirinto, è sempre preferibile scegliere una soluzione interoperabile; uno che rispetta le migliori pratiche in termini di sviluppo (modelli di progettazione)

6.Security

Qualsiasi applicazione è potenzialmente vulnerabile. Per ridurre al minimo il rischio, è sempre meglio selezionare un framework in grado di garantire funzioni di sicurezza (gestione XSS, ad esempio).

7.Documentation

È assolutamente necessario valutare la natura, il volume e la qualità della letteratura esistente su un quadro: uno strumento ben documentato è sia più facile da usare che più aggiornabile.

8.License

Le licenze sono importanti semplicemente perché possono avere un impatto significativo sulle tue applicazioni. Ad esempio, un'applicazione sviluppata utilizzando un framework con licenza GPL sarà necessariamente soggetta a GPL. D'altra parte, questo non è il caso di un framework con licenza MIT.

9.Disponibilità di risorse sul mercato

Forse vorresti avere un team tecnico che ti circonda durante la fase di sviluppo o nel lungo termine, sia per la manutenzione che per gli aggiornamenti. In altre parole, assicurarsi che le competenze richieste per lo strumento che si sta utilizzando siano disponibili sul mercato aperto.

10. Provalo!

Questa è la chiave! Non essere soddisfatto di leggere recensioni, commenti e voci, buone o cattive, su Internet. Provandolo, sarai in grado di prendere una decisione e assicurarti di essere completamente a tuo agio con lo strumento.

La chiave è la pazienza. Pazienza, pazienza, pazienza. Non c'è modo di prevedere il futuro. (devo anche scriverlo?) Ma se dai alla nuova tecnologia un paio d'anni e guardi come è adottata, avrai una buona idea se metterà radici o meno e sarà adatta per progetti a lungo termine / investimento nel tempo .

Quindi, quando NextNewThing (tm) arriva, sentiti libero di saltare sul carro ... solo per qualcosa di importante nei primi due anni.

La risposta di Mikeras è piuttosto carina. Aggiungerò che le soluzioni a prova di futuro sono davvero una sorta di sicurezza o gestione dei rischi. Spesso richiede di rinunciare a certi comfort ei vantaggi di costo / produttività ora ai problemi Evitare tardi. Da un po 'di tempo realizzo tecnologie a prova di futuro. Ci sono alcuni schemi che possono aiutare. Eccone alcuni.

1. I dati dovrebbero essere archiviati in un formato aperto che è facile da estrarre o trasformare in seguito. I formati di file dispari sono una grande tecnica di lockin e un'area trap in generale. Inoltre, preferisci approcci più semplici come CSV, ASN.1 o JSON piuttosto che schifezze complicate come XML o, diciamo, il formato Word 97;). L'idea è che è abbastanza semplice mettere insieme un parser e il parser di basso livello è riutilizzabile tra le tue app.

2. Idealmente, le applicazioni dovrebbero avere interfacce vendor e tecnicamente neutre integrate, oltre a una descrizione precisa di ciò che fanno. È necessario progettare elementi in cui è possibile modificare o eliminare l'implementazione senza interrompere nulla. Inoltre, passare a una nuova piattaforma è semplice se il metodo di chiamata delle procedure o di elaborazione dei dati funziona su più piattaforme. Quindi, le interfacce sono la cosa più importante da correggere. Più semplice, veloce e più apre il metodo di implementazione dell'interfaccia, meglio è.

3. Lo stack dovrebbe essere interamente open source e libero di modificare. Le licenze GPL, LGPL, BSD, MIT, ecc. Vanno bene su questo punto di vista. L'idea è che, se la comunità inizia a scomparire, potrebbe essere necessario spostare lo stack nel nuovo [hardware / sistema operativo / protocollo / ecc.]. E hai bisogno del codice per farlo.

4. Il design dello stack dovrebbe essere estremamente modulare con ogni pezzo comprensibile da una persona. Questo rende più facile per un nuovo gruppo raccoglierlo e mantenerlo. Avere anche i livelli più bassi di runtime, le librerie e il compilatore elaborati correttamente può avere un enorme vantaggio se deve essere trasferito. Spesso, solo una parte può essere trasferita e tutto il tuo vecchio codice funzionerà.

5. La tua app dovrebbe essere realizzata in modo modulare che tenga conto dei dettagli della piattaforma per ridurre al minimo le rilavorazioni in quell'area. Aiuta a strutturare le funzioni in blocchi di input / elaborazione / output laddove possibile. Questo può aiutare un'analisi di ciò che sarà interessato da un porto (e l'analisi della correttezza in generale alla metodologia della camera bianca). La piattaforma di approccio più a basso rischio è saggia utilizzare le funzionalità di minimo comune denominatore che sono supportate universalmente con un'unica interfaccia che consente di utilizzarle, riducendo ulteriormente il porting. (Ho detto che avresti perso qualcosa ...)

6. La digitazione dinamica, l'inferenza di tipo o altri approcci di digitazione flessibili aiutano. Una porta su una nuova piattaforma potrebbe cambiare le definizioni dei tipi di base. Le lingue che fanno una forte battitura interna significano che ti preoccupi di meno di queste cose.

7. Mantieni semplice il modello di concorrenza. Guidato dagli eventi, il passaggio di messaggi attraverso interfacce chiare è portatile per ... praticamente tutto. Ci sono anche coroutine. Volete solo evitare percorsi soggetti a errori e problemi di portabilità.

8. Guarda i runtime portatili di Mozilla e Apache. Esse risolvono molti problemi specifici della piattaforma con determinate opzioni di interfaccia e implementazione. Possono darti un'idea di cosa preoccuparti, oltre a fornire buone soluzioni a molti problemi.

Esempio perfetto: Tcl. Lo so, molte persone lo odiano e lo uso raramente da solo. Tuttavia, Tcl è un linguaggio estremamente facile da capire, implementare (12 regole principali) e inserire codice. È piccolo, abbastanza veloce, si integra con i server Web, si integra in app native, è stato portato su tonnellate di roba, ha alcune caratteristiche di sicurezza , ed è stato aggiornato regolarmente dagli anni '80, quando è stato realizzato. Tu o io potremmo implementare un intero runtime TCL in pochissimo tempo per il linguaggio principale. Se dovessimo eseguire il porting della libreria standard, sarebbe più semplice del porting di .NET o Java. E c'è un bel po 'di codice utile scritto per questo. Ed è stato utilizzato nella tecnologia Web fin dalla mania degli "agenti mobili" a cui puntavano anche le applet Java. Ad esempio, il framework Web OpenACS risale al 1998 con server precedenti.

Altri esempi: BASIC, COBOL e LISP (Schema o CL). Tutte queste lingue risalgono agli anni '50 o '60. Sono abbastanza semplici da facilitare la comprensione, l'implementazione e la traduzione meccanica. Tuttavia, puoi costruire cose utili con loro. COBOL alimenta ancora la maggior parte dell'elaborazione delle transazioni mondiali, è stato aggiornato alcune volte e funziona anche su .NET. Le vecchie app QBasic / QuickBASIC funzionano ancora oggi con strumenti aperti / gratuiti su piattaforme moderne, insieme a possibilità di porting su strumenti migliori come GAMBAS o RealBASIC. I programmatori LISP rendono naturalmente i loro sistemi modulari e funzionali, facilitando il porting. C'è stato un flusso costante di implementazioni per decenni, aperto e commerciale.

Quindi, interfacce, apertura, semplicità, modularità e architettura / progettazione / codifica neutre dalla piattaforma. QUESTI ti forniranno le soluzioni per il futuro di cui hai bisogno. Il più delle volte, comunque.