Articles

Software framework

Questa sezione ha molteplici problemi. Per favore aiuta a migliorarla o discuti questi problemi nella pagina di discussione. (Impara come e quando rimuovere questi messaggi template)

Questa sezione necessita di ulteriori citazioni per la verifica. Per favore aiuta a migliorare questo articolo aggiungendo citazioni a fonti affidabili. Il materiale privo di fonti può essere contestato e rimosso.
Trova le fonti: “Software framework” – notizie – giornali – libri – scholar – JSTOR (Aprile 2011) (Impara come e quando rimuovere questo messaggio modello)

Questa sezione potrebbe essere troppo lunga ed eccessivamente dettagliata. Si prega di considerare la possibilità di riassumere il materiale citando le fonti come necessario. (Aprile 2020)

Questa sezione contiene parole ambigue: espressioni vaghe che spesso accompagnano informazioni parziali o non verificabili. Tali affermazioni dovrebbero essere chiarite o rimosse. (Aprile 2020)

Questa sezione è scritta come una riflessione personale, un saggio personale o un saggio argomentativo che afferma i sentimenti personali di un redattore di Wikipedia o presenta un argomento originale su un argomento. Per favore aiuta a migliorarla riscrivendola in uno stile enciclopedico. (Aprile 2020) (Impara come e quando rimuovere questo messaggio modello)

(Impara come e quando rimuovere questo messaggio modello)

I progettisti di software frameworks mirano a facilitare lo sviluppo del software permettendo a progettisti e programmatori di dedicare il loro tempo a soddisfare i requisiti del software piuttosto che occuparsi dei dettagli di basso livello più standard per fornire un sistema funzionante, riducendo così il tempo complessivo di sviluppo. Per esempio, un team che usa un web framework per sviluppare un sito web bancario può concentrarsi sulla scrittura di codice specifico per l’attività bancaria piuttosto che sulla meccanica della gestione delle richieste e dello stato.

I framework spesso aumentano la dimensione dei programmi, un fenomeno chiamato “code bloat”. A causa delle esigenze delle applicazioni dettate dalla domanda dei clienti, frameworks concorrenti e complementari a volte finiscono in un prodotto. Inoltre, a causa della complessità delle loro API, la prevista riduzione del tempo di sviluppo complessivo può non essere raggiunta a causa della necessità di spendere tempo aggiuntivo per imparare ad usare il framework; questa critica è chiaramente valida quando un framework speciale o nuovo viene incontrato per la prima volta dallo staff di sviluppo. Se un tale framework non viene usato nei successivi incarichi di lavoro, il tempo investito per imparare il framework può costare di più del codice scritto appositamente e familiare allo staff del progetto; molti programmatori conservano copie di boilerplate utili per i bisogni comuni.

Tuttavia, una volta che un framework viene imparato, i progetti futuri possono essere più veloci e facili da completare; il concetto di un framework è quello di fare un insieme di soluzioni a taglia unica, e con la familiarità, la produzione di codice dovrebbe logicamente aumentare. Non ci sono affermazioni simili sulla dimensione del codice che alla fine viene fornito in bundle con il prodotto di uscita, né sulla sua relativa efficienza e concisione. L’uso di qualsiasi soluzione di libreria necessariamente tira dentro extra e risorse estranee inutilizzate, a meno che il software non sia un compilatore-object linker che fa un modulo eseguibile stretto (piccolo, interamente controllato e specificato).

La questione continua, ma un decennio e più di esperienza industriale ha mostrato che i framework più efficaci risultano essere quelli che si evolvono dal rifattorizzare il codice comune dell’impresa, invece di usare un framework generico “one-size-fits-all” sviluppato da terze parti per scopi generali. Un esempio di ciò potrebbe essere il modo in cui l’interfaccia utente in un pacchetto di applicazioni come una suite per l’ufficio cresce per avere un aspetto, una sensazione e degli attributi e metodi comuni per la condivisione dei dati, man mano che le applicazioni in bundle, una volta disparate, crescono unificate in una suite che è più stretta e più piccola; la suite più nuova/evoluta può essere un prodotto che condivide librerie di utilità integrale e interfacce utente.

Questa tendenza nella controversia porta alla luce una questione importante sui framework. Creare un framework che sia elegante, piuttosto che uno che risolva semplicemente un problema, è ancora più un mestiere che una scienza. “L’eleganza del software” implica chiarezza, concisione e poco spreco (funzionalità extra o estranee, molte delle quali sono definite dall’utente). Per quei framework che generano codice, per esempio, “eleganza” implicherebbe la creazione di codice che sia pulito e comprensibile per un programmatore ragionevolmente esperto (e che sia quindi facilmente modificabile), rispetto a uno che genera semplicemente codice corretto. Il problema dell’eleganza è il motivo per cui relativamente pochi framework software hanno superato la prova del tempo: i migliori framework sono stati in grado di evolversi con grazia man mano che la tecnologia sottostante su cui erano costruiti progrediva. Anche lì, dopo essersi evoluti, molti di questi pacchetti manterranno capacità legacy che gonfiano il software finale poiché metodi altrimenti sostituiti sono stati mantenuti in parallelo con i metodi più nuovi.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *