{"id":29289,"date":"2024-09-02T10:00:00","date_gmt":"2024-09-02T08:00:00","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=29289"},"modified":"2024-09-02T13:19:55","modified_gmt":"2024-09-02T11:19:55","slug":"nuovi-framework","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/backend-it\/architettura-del-software\/nuovi-framework\/","title":{"rendered":"L’adozione di nuovi framework potrebbe far fallire il tuo progetto"},"content":{"rendered":"\n

Nel mondo dello sviluppo software, l’attrazione per le novit\u00e0 \u00e8 sempre forte. \u00c8 allettante mettere le mani su un nuovo prodotto, magari il primo a risolvere una serie di problemi che gli altri framework non riescono ad affrontare.<\/p>\n\n\n\n

Questi nuovi progetti spesso vantano una comunit\u00e0 piccola ma energica, promettono di accelerare i tempi di sviluppo<\/strong> e presentano innovazioni interessanti rispetto ai concorrenti. Tutto ci\u00f2 sembra molto promettente, ma \u00e8 davvero la scelta giusta per un progetto a lungo termine?<\/p>\n\n\n\n

Donald Knuth, uno dei padri dell’informatica moderna, commentava il proprio codice in questo modo:<\/p>\n\n\n\n

Fate attenzione ai bug nel codice soprastante; ho solo dimostrato che \u00e8 corretto, non l'ho testato.<\/em><\/pre>\n\n\n\n
Se fosse stata scritta da un programmatore junior, questa frase potrebbe sembrare una battuta. Ma detta da Knuth<\/strong>, oltre a essere umoristica, potrebbe anche segnalare che quella parte di codice non era testabile, ma solo sintatticamente corretta.<\/p>\n\n\n\n
A volte \u00e8 molto pi\u00f9 semplice dimostrare un concetto, descriverne il funzionamento e documentarlo, rispetto alla sua reale applicazione, che potrebbe coinvolgere una serie di aspetti non considerati dalla dimostrazione.<\/p>\n\n\n\n
Questo concetto si pu\u00f2 parafrasare cos\u00ec: “Non \u00e8 detto che un’idea brillante funzioni sempre nella realt\u00e0<\/em>“. Pensando a ci\u00f2, non posso non considerare il mondo delle blockchain: sulla carta strumenti eccellenti, ma nella pratica spesso criticati per prestazioni e utilizzo delle risorse.<\/p>\n\n\n\n
Uscendo dal mondo software, pensiamo a prodotti come Segway<\/a><\/strong> che, nonostante fosse un’idea brillante, non ha avuto il successo sperato. O a Google Glass, che nonostante fosse un prodotto innovativo, non \u00e8 mai decollato.<\/p>\n\n\n\n
E i framework?<\/h2>\n\n\n\n
I nuovi framework e, pi\u00f9 in generale, le tecnologie software, soffrono spesso di un hype iniziale che galvanizza i programmatori, distraendoli da una solida analisi della loro efficacia nel lungo termine. I concetti utilizzati in quel nuovo software sono applicabili a tutti i progetti? Sono facilmente integrabili con altre tecnologie?<\/strong> Ci sono solide aziende che investono in quella tecnologia? La comunit\u00e0 \u00e8 attiva e supporta il prodotto?<\/p>\n\n\n\n
I cosiddetti “early adopters” sono spesso attratti dalle novit\u00e0, ma frequentemente non si rendono conto dei rischi che questa scelta comporta. Se va tutto bene, hanno fatto una scelta fortunata che ha portato al successo il proprio software. Ma se il prodotto scelto non riesce a mantenere le promesse, si ritrovano con un software che non funziona come dovrebbe e che richiede un lavoro di manutenzione e refactoring molto pi\u00f9 pesante di quanto previsto.<\/p>\n\n\n\n
Per chi sviluppa software da oltre 30 anni, il nome Visual Objects far\u00e0 suonare qualche campanello<\/strong>: doveva essere il nuovo Clipper e portare milioni di programmatori DOS in ambiente Windows. Un’idea fantastica, ma che non ha funzionato: troppi problemi, troppi bug, troppi limiti. Ai tempi aveva alle spalle un’azienda come Computer Associates, che poteva permettersi di investire milioni di dollari in un prodotto, ma nonostante questo, non \u00e8 mai decollato.<\/p>\n\n\n\n
Ecco perch\u00e9, quando si tratta di scegliere un framework o una tecnologia per un progetto, \u00e8 importante considerare non solo le sue caratteristiche tecniche, ma anche la sua sostenibilit\u00e0<\/strong> a lungo termine.<\/p>\n\n\n\n
L’orizzonte temporale: una dimensione cruciale<\/h2>\n\n\n\n
Ogni volta che valuto un progetto, cerco di anticiparne il ciclo di vita, o almeno quello che dovrebbe essere, basandomi sull’esperienza e sulle informazioni a mia disposizione. La sfera di cristallo non esiste e il futuro non \u00e8 prevedibile, ma ci sono segnali che fanno capire se un progetto sar\u00e0 di breve, media o lunga durata.<\/p>\n\n\n\n
Per comprendere quanto un progetto possa durare, \u00e8 importante considerare vari aspetti:<\/p>\n\n\n\n