Quando NON usare un framework [chiuso]

Oggi è possibile trovare un framework per quasi tutte le lingue, adatto a qualsiasi progetto. La maggior parte dei framework moderni è abbastanza robusta (in generale), con test di ora in ora, codice peer-reviewed e grande estensibilità.

Tuttavia, penso che ci sia un aspetto negativo di QUALSIASI framework in quanto i programmatori, come comunità, potrebbero diventare così dipendenti dai framework scelti che non comprendono più i meccanismi sottostanti, o nel caso di programmatori più recenti, non imparano mai i meccanismi sottostanti per iniziare con. È facile specializzarsi nella misura in cui non si è più un "programmatore PHP" (ad esempio), ma un "programmatore Drupal", ad esclusione di qualsiasi altra cosa.

A chi importa, vero? Abbiamo il quadro! Non abbiamo bisogno di sapere come "farlo a mano"! Destra?

Il risultato di questa perdita di competenze di base (a volte nella misura in cui i programmatori che non usano i framework sono visti come "obsoleti") è che diventa pratica comune utilizzare un framework in cui non è richiesto o appropriato. Le funzionalità che il framework facilita si confondono con ciò di cui è capace la lingua di base. Gli sviluppatori iniziano a utilizzare i framework per eseguire anche le attività più elementari, in modo che quello che una volta era considerato un processo rudimentale ora coinvolge grandi librerie con le proprie stranezze, bug e dipendenze. Ciò che una volta è stato realizzato in 20 righe è ora realizzato includendo un framework di 20.000 righe E scrivendo 20 righe per utilizzare il framework.

Al contrario, non si vuole reinventare la ruota. Se sto scrivendo codice per eseguire alcune piccole attività di base e comuni, potrei sentirmi come se stessi sprecando il mio tempo quando so che il framework XYZ offre tutte le funzionalità che sto cercando, e molto altro ancora. La parte "molto di più" mi preoccupa ancora, ma non sembra che molti lo considerino più.

Deve esserci una buona metrica per determinare quando è appropriato utilizzare un framework. Quello che non si considera la soglia di essere, come si fa si decide quando utilizzare un quadro, o, quando non è.

"Deve esserci una buona metrica per determinare quando è appropriato utilizzare un framework".

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

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

I frame sono solo strumenti. Non penso che sia un difetto del framework se è abusato, piuttosto quello della persona che lo abusa. Il vecchio detto "se hai un martello, tutto sembra un chiodo" mostra che questo modo di pensare esiste già da molto prima che anche i computer.

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

Per rispondere alla tua domanda specifica, non credo che ci sia una metrica per questo. Preferisco usare un framework quando semplifica la risoluzione dei problemi. Se l'utilizzo di un framework mi aiuta a risolvere un problema con 2 righe di codice anziché con 20, ovviamente lo userò. Ma anche se le sue 20 linee contro 20, potessi decidere di usare un framework se mi dà astrazioni migliori, più vicine 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 framework è solo uno strumento, sì. Un framework ti consente di far funzionare qualcosa molto rapidamente e come tale è un eccellente strumento di prototipazione.

Da qualche parte lungo la linea, quando l'applicazione raggiunge un certo livello di complessità, le restrizioni inerenti a un framework iniziano a soffocare un'ulteriore crescita, mi sembra. Il trucco è riconoscere quando hai riscontrato un tale punto critico e quindi decidere cosa farai al riguardo.

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

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

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

# 1. Il framework farà risparmiare tempo e fatica?

La risposta a questa domanda è quasi sempre sì . I frame tendono ad essere costruiti per risolvere problemi specifici e risolverli molto bene. Ad esempio, framework come EntityFramework possono salvarti completamente dalla scrittura di codice SQL. Il che può essere fantastico se il tuo team di programmazione non parla fluentemente SQL.

I frame sono costruiti per, a) aggiungere un'interfaccia intuitiva per i programmatori a componenti altrimenti complessi oppure b) aggiungere astrazione a componenti già noti (o consolidati).

Il secondo (o anche il primo in alcuni casi) può effettivamente ostacolare lo sviluppo. Ciò vale soprattutto quando voi o il vostro team di programmazione implementerà un nuovo framework, in cui non hanno mai lavorato prima.

Ciò potrebbe potenzialmente rallentare il processo di sviluppo, che potrebbe essere costoso.

# 2 La scala della tua applicazione

Si dice che "vale la pena esagerare" , ma di solito non è così. Probabilmente non c'è alcun buon motivo per implementare un framework di grandi dimensioni se il punto della tua applicazione è stampare "patata" .

Quando stai sviluppando un'applicazione (sia essa web, desktop, mobile o qualsiasi altro tipo immaginabile di applicazione) - se ritieni che la dimensione del tuo framework "nani" la tua (forse futura) implementazione di essa, allora questo potrebbe essere un grande segnale di avvertimento che il framework potrebbe solo gonfiare l'applicazione. Un buon aneddoto sarebbe se includessi jQuery, solo per aggiungere una classe "caricata" al tuo body-tag quando il documento è pronto. Farlo con solo JavaScript nativo potrebbe essere un po 'più difficile , ma non gonfia la tua applicazione.

D'altra parte, se un framework fa un sacco di lavoro sporco all'interno (ad esempio framework di database), potrebbe essere fattibile implementarlo, anche se si sta solo "parzialmente" utilizzando il framework. Un buon aneddoto sarebbe di non provare a creare il proprio driver ADO.NET o MongoDB, solo perché non è necessario utilizzare l'intera libreria.

A volte i framework sono open-source (e con licenze "fai tutto quello che vuoi"). Questo 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.

# 3 Impatto.

Talvolta l'implementazione di un framework può avere un impatto diretto sull'utente finale. Ciò è particolarmente vero per le applicazioni Web, poiché avere grandi framework lato client potrebbe influire negativamente sull'esperienza dell'utente finale. Gli utenti con macchine più lente potrebbero riscontrare rendering lenti, problemi di prestazioni con javascript o problemi simili causati da macchine sotto-par. L'utente con connessioni lente potrebbe riscontrare tempi di caricamento lenti (almeno iniziali).

Anche in altri tipi di applicazioni, gli utenti finali potrebbero essere influenzati negativamente dalle dipendenze dell'applicazione. I frame occupano almeno sempre un po ' di spazio su disco e, se si sta sviluppando un'app mobile (o anche un'app desktop), potrebbe essere necessario tenerne conto.

I framework lato server (anche più specifici del Web) probabilmente non influenzeranno gli utenti finali, ma influenzeranno la vostra infrastruttura . Alcuni framework hanno dipendenze stesse che potrebbero richiedere il riavvio del server Web, solo del servizio o del server.

Alcuni framework potrebbero anche essere molto ricchi di risorse.

Questo ovviamente ricollega ai punti 1 e 2.

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

Corbin March lo ha riassunto molto bene:

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

È anche importante non essere elitari . I frame sono strumenti che devono essere utilizzati. Conosco persone di entrambi gli estremi; da un lato hai il ragazzo che rende la vita molto difficile per se stesso, dall'altro hai il ragazzo che costruisce applicazioni lente e gonfie.

Tutti i framework hanno casi d'uso, è solo una questione di implementarli per gli scopi giusti.

Gli altri sviluppatori conoscono il framework?

Se tutti gli sviluppatori conoscono il framework X, quindi dati tutti gli altri motivi per utilizzare il framework sono fattibili, provaci! Per me, non ha alcun 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 me! Sì, è un peccato, ma ho intenzione di passare il tempo a preoccuparmi dell'inettitudine di qualcun altro? Nup. (Basato sul presupposto che questi nuovi membri della comunità non lavorino immediatamente con te.)

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

È probabile che il framework sia supportato da tempo. Ho già fatto in modo che mi finissero prima, ed è DAVVERO fastidioso. Soprattutto quando hai 9 mesi di lavoro nel tuo progetto e il passaggio non è più un'opzione. E se il framework non è più supportato, pensaci tre volte prima di scrivere qualcosa di nuovo usando quel framework. Non importa quanto tu lo sappia già.

Il progetto corrisponde effettivamente al framework. Come un esempio piuttosto antico, hai visto le cose che l'MFC è stato creato per fare? Le persone non hanno mai smesso di fare cose strane per farlo funzionare per tipi di app in cui non aveva senso. Di solito passano più tempo a battere su MFC di quanto avrebbero speso solo scrivendo l'app che volevano subito.

Il team di progetto è in grado di lavorare nell'ambito. Alcune persone non riescono o non riescono a prendere il tempo per capire come un'app dovrebbe essere scritta in un determinato framework, e invece scrivono le cose come fanno di solito, invece che nel 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 fatica.