Quando NON usare un framework [chiuso]

"There has to be a good metric to determine when it is appropriate to use a framework."

Non proprio. Se esistessero buone metriche per determinare l'uso appropriato di qualsiasi tecnologia, non vedresti linguaggio, editor e metodologia di guerre sante.

I gruppi con cui ho lavorato fanno tutti la stessa cosa: fai un'ipotesi su costi e benefici, scegli il percorso più produttivo e spera che abbiano ragione. Non è terribilmente scientifico - una parte intuizione, tre parti di esperienza, una parte suscettibilità al marketing, una parte astuzia e cinque parti di opinione.

I quadri sono solo strumenti. Non penso sia colpa di un quadro se è abusato, piuttosto che della persona che lo abusa. Il vecchio detto "se hai un martello, tutto sembra un chiodo" mostra che questo modo di pensare è esistito molto prima persino dei computer.

Diventare troppo specializzati può davvero trasformarsi in un problema a lungo termine, sia per uno sviluppatore che per le specie biologiche. Per la sopravvivenza a lungo termine, è necessario bilanciare attentamente lo sforzo per sviluppare le proprie capacità in più aree.

Per rispondere alla tua domanda specifica, non penso ci sia una metrica per questo. Preferisco usare un framework quando semplifica la risoluzione dei problemi. Se usare un framework mi aiuta a risolvere un problema con 2 linee di codice anziché 20, lo userò ovviamente. Ma anche se le sue 20 righe contro 20, potrei decidere di utilizzare un framework se mi fornisce astrazioni migliori, più vicino al dominio del problema, rendendo il codice più facile da capire e mantenere.

Penso che i framework possano essere abusati in alcuni contesti, sì. Un quadro è solo uno strumento, sì. Un framework ti permette di ottenere qualcosa in esecuzione molto rapidamente, e in quanto tale è uno strumento di prototipazione eccellente.

Da qualche parte lungo la linea, quando la tua applicazione raggiunge un certo livello di complessità, le restrizioni inerenti a un quadro cominciano a soffocare un'ulteriore crescita, mi sembra. Il trucco è riconoscere quando hai riscontrato un tale punto di svolta e poi decidere cosa intendi fare al riguardo.

Tendo a lavorare di più con le applicazioni web e anche se sto cercando di essere generale, la mia risposta potrebbe non applicare alla tua area di programmazione.

Userò anche "framework" sinonimo di "library".

Prima di implementare un framework, è necessario considerare alcune cose, ecco alcuni esempi generali.

# 1. Il framework risparmierà tempo e sforzi?

La risposta a questa domanda è quasi sempre si . I framework tendono a essere costruiti per risolvere problemi specifici e risolverli molto bene. Ad esempio, framework come EntityFramework possono salvarti interamente dalla scrittura del codice SQL. Che può essere fantastico se il tuo team di programmazione non parla correntemente SQL.

I framework sono costruiti per entrambi, a) aggiungono un'interfaccia programmabile per componenti altrimenti complessi o b) per aggiungere astrazione a componenti già noti (o stabiliti).

Quest'ultimo (o anche il primo in alcuni casi) può effettivamente intralciare di sviluppo. Questo vale specialmente quando tu o il tuo team di programmazione implementerete un nuovo framework, in cui non hanno mai funzionato prima.

Questo potrebbe potenzialmente rallentare il tuo processo di sviluppo, che potrebbe potenzialmente essere costoso.

# 2 La scala della tua applicazione

Si dice che "qualsiasi cosa vale la pena di fare vale la pena" , ma di solito non è così. Probabilmente non ci sono buone ragioni per implementare un framework di grandi dimensioni se il punto della tua applicazione è quello di stampare "potato" .

Quando sviluppi un'applicazione (sia essa web, desktop, mobile o qualsiasi altro tipo di applicazione concepibile) - se ritieni che la dimensione del tuo framework "nani" la tua (forse futura) implementazione di esso, allora questo potrebbe essere un grande segnale di avvertimento che il tuo framework potrebbe semplicemente gonfiare la tua applicazione. Un buon aneddoto sarebbe se includessi jQuery, solo per aggiungere una "carica" del tuo body tag quando il documento è pronto. Fare ciò con il solo JavaScript nativo potrebbe essere un po 'più difficile , ma non gonfiare la tua applicazione.

D'altra parte se un framework fa molto di lavoro sporco all'interno (cioè framework di database), allora potrebbe essere fattibile implementarlo, anche se tu sei solo "parzialmente" usando la struttura. Un buon aneddoto sarebbe quello di non provare a creare il proprio driver ADO.NET o MongoDB, solo perché non è necessario utilizzare l'intera libreria.

A volte i framework vengono open-source (e con licenze "do-whatever-you-want"). Ciò apre una nuova possibilità in cui un team di programmazione potrebbe optare solo per parti di un framework.

Questo alla fine si ricollega alla domanda n. 1 e n. 3.

Impatto n. 3

A volte l'implementazione di un framework può avere un impatto diretto per l'utente finale. Questo è particolarmente vero per le applicazioni Web, dal momento che i grandi framework lato client potrebbero influire negativamente sull'esperienza dell'utente finale. Gli utenti con macchine più lente potrebbero riscontrare problemi di rendering lento, problemi di prestazioni con javascript o problemi simili causati da macchine parziali. L'utente con connessioni lente potrebbe avere tempi di caricamento lenti (almeno iniziali).

Anche in altri tipi di applicazioni, gli utenti finali potrebbero essere influenzati negativamente dalle dipendenze dell'applicazione. I framework occupano almeno sempre alcuni di spazio su disco e, se stai sviluppando un'applicazione per dispositivi mobili (o anche un'applicazione per desktop), potrebbe essere necessario tenerne conto.

I framework lato server (anche più specifici per il web) molto probabilmente non influenzeranno gli utenti finali, ma influenzeranno la tua infrastruttura . Alcuni framework hanno dipendenze se stessi che potrebbero richiedere il riavvio completo del server Web, solo il servizio o il server.

Alcuni framework potrebbero anche essere molto pesanti in termini di risorse.

Questo ovviamente si ricollega ai punti 1 e 2

È solo una grande "cerchia di considerazioni" e non esiste un vero metodo scientifico per decidere se implementare o meno un framework.

Corbin March lo ha riassunto molto bene:

The groups I've worked with all do the same thing - make a guess at costs and benefits, choose the most productive route, and hope they're right. It's not terribly scientific - one part intuition, three parts experience, one part susceptibility to marketing, one part cunning, and five parts rank opinion.

È anche importante non essere elitario . I quadri sono strumenti che devono essere utilizzati. Conosco persone di entrambi gli estremi; da una parte hai il ragazzo che rende la vita molto dura per se stesso, dall'altra parte c'è il ragazzo che costruisce applicazioni lente e gonfie.

Tutti i framework hanno casi d'uso, si tratta solo di implementarli per gli scopi giusti.

Gli altri sviluppatori conoscono il framework?

Se tutti gli sviluppatori conoscono il framework X, allora tutti gli altri motivi per usare il framework sono fattibili, provaci! Per me, non ha senso imporre l'apprendimento di un quadro specifico quando la maggior parte del tempo di sviluppo sarà dedicato all'apprendimento delle complessità del quadro.

Per quanto riguarda la tua affermazione sui nuovi programmatori che non conoscono le basi, sei molto più compassionevole di quanto lo sia io! Sì, è un peccato, ma ho intenzione di passare il mio tempo a preoccuparmi dell'inettitudine di qualcun altro? Nup. (Partendo dal presupposto che questi nuovi membri della comunità non lavorano immediatamente con te.)

Vorrei usare un framework se (e SOLO se) le seguenti condizioni sono vere:

Il framework sembra essere supportato per qualche tempo. Li ho fatti andare su End-of-life su di me prima, ed è DAVVERO fastidioso. Soprattutto quando hai 9 mesi nel tuo progetto, e il passaggio non è più un'opzione. E se il framework è GIÀ non più supportato, pensa tre volte prima di scrivere qualcosa di nuovo usando quel framework. Non importa quanto bene lo sai già.

Il progetto corrisponde effettivamente al framework. Come un esempio piuttosto vecchio, hai visto le cose che MFC è stato fatto per fare? La gente non ha mai finito di fare cose strane per farlo funzionare per tipi di app in cui semplicemente non aveva senso. Di solito trascorrono più tempo a battere su MFC di quanto avrebbero speso solo scrivendo l'app che volevano direttamente.

Il team di progetto è in grado di lavorare all'interno del framework. Alcune persone non hanno o non possono prendersi il tempo per capire come un'app dovrebbe essere scritta in un dato framework, e invece scrivono le cose come fanno di solito, invece del modo in cui il framework ha bisogno. Questa errata corrispondenza tra codice e framework di solito finisce per costare a tutti un sacco di tempo e impegno.