I framework mettono troppa astrazione? [chiuso]

Sto programmando da poco meno di un anno e ho una certa esperienza nella scrittura di applicazioni di sistemi, app Web e script per aziende / organizzazioni. Tuttavia, una cosa che non ho mai veramente fatto è lavorare con un framework come Django, Rails o Zend.

Osservando il framework Django, sono un po 'frustrato da quanto viene sottratto ai framework. Comprendo gli obiettivi principali di DRY e il codice minimo, ma alcuni di questo eccessivo affidamento su moduli diversi e pesante astrazione delle funzioni core sembra:

1. Rende i programmi molto datati a causa della natura mutevole di moduli / framework,

2. Rende il codice difficile da capire a causa della pletora di framework e moduli disponibili e di tutte le loro idiosincrasie,

3. Rende il codice meno logico se non hai letto tutta la documentazione; ad esempio, posso leggere alcune comprensioni dell'elenco e la logica condizionale e capire cosa sta facendo un programma, ma quando vedi funzioni che richiedono il passaggio in stringhe e dizionari arbitrari, le cose diventano un po 'difficili da capire a meno che tu non sia già un guru in un dato modulo; e:

4. Rende difficile e noioso passare da un framework all'altro. Passare da una lingua all'altra è già una sfida, ma è gestibile se si ha una comprensione abbastanza forte della loro funzionalità / filosofia di base. Il passaggio da un framework all'altro sembra essere più una questione di memorizzazione automatica, che in qualche modo sembra incoraggiare l'inefficienza che questi framework sono stati progettati per eliminare.

Dobbiamo davvero mettere come 50 strati di astrazione su qualcosa di semplice come una query MySQL? Perché non usare qualcosa come l'interfaccia PDO di PHP, in cui vengono gestite istruzioni preparate / test di input ma la query SQL universalmente comprensibile fa ancora parte della funzione?

Queste astrazioni sono davvero utili? La caratteristica gonfia non li rende inutili, rendendo le applicazioni più difficili rispetto ad applicazioni simili scritte senza utilizzare un framework?

I frame possono essere davvero complicati. I problemi possono sorgere facilmente quando un framework è troppo "supponente", cioè quando preferisce davvero un particolare stile di applicazione e tutte le parti sono orientate a supportare questo particolare stile.

Ad esempio, se il framework astrae completamente il processo di autenticazione di un utente consentendo di aggiungere solo un componente, aggiungere un modello di accesso da qualche parte e voilà, si ottiene l'autenticazione utente gratuitamente. Ciò ti ha risparmiato un sacco di lavoro ripetitivo preoccupandoti di cookie, memorizzazione delle sessioni, hashing delle password e quant'altro.

I problemi iniziano quando ti rendi conto che il comportamento predefinito del codice di autenticazione del framework non è quello che ti serve. Forse non sta seguendo le ultime migliori pratiche di sicurezza. Forse hai bisogno di un hook personalizzato nel processo per innescare qualche azione, ma il framework non offre uno. Forse è necessario modificare i dettagli del cookie che viene impostato, ma il framework non offre alcun modo per personalizzarlo.

L'astrazione offerta dal framework ti ha permesso di aggiungere una funzionalità importante al tuo sito in pochi minuti anziché giorni inizialmente, ma alla fine potresti dover combattere contro il framework per farlo fare quello che ti serve, oppure reinventare la funzionalità da zero comunque per soddisfare le tue esigenze.

Questo non vuol dire che le astrazioni del quadro siano cattive, intendiamoci. È per dire che questa è sempre una possibilità che devi tenere a mente. Alcuni framework sono esplicitamente orientati a questo, offrono un modo per ottenere qualcosa molto rapidamente come prototipo o persino framework di produzione per un tipo di app molto specifico e limitato. Altri framework sono più simili a raccolte libere di componenti che è possibile utilizzare, ma che consentono comunque molta flessibilità per modificarlo in un secondo momento.

Quando usi un'astrazione, dovresti sempre capire almeno all'incirca ciò che si sta allontanando. Se non capisci i cookie e i sistemi di autenticazione, partire da un'astrazione non è una buona idea. Se capisci cosa stai cercando di fare e hai solo bisogno di un codice che lo faccia già invece di dover scrivere noiosamente le tue, le astrazioni fanno risparmiare molto tempo. Tuttavia, astrazioni scritte male possono metterti nei guai in seguito, quindi è un'arma a doppio taglio.

Dovresti anche distinguere tra astrazioni tecniche e astrazioni "regole aziendali" . La programmazione in un linguaggio di livello superiore è un'astrazione che probabilmente non vorrai perdere (Python, PHP, C # vs. C vs. Assembler; Less vs. CSS), mentre le "astrazioni delle regole di business" possono essere difficili se non lo fanno soddisfare esattamente le tue esigenze (autenticazione con un clic e cookie di codifica manuale).

Questo perché le astrazioni tecniche raramente "perdono", cioè non sarà necessario eseguire il debug del codice macchina quando si scrivono applicazioni in Python. Le astrazioni delle regole di business funzionano allo stesso livello tecnico e in realtà sono solo "bundle di codice". Probabilmente sarà necessario eseguire il debug del cookie che viene impostato o l'hash della password che si crea ad un certo punto, il che significa che sarete immersioni attraverso un sacco di codice di terze parti.

Mi sembra che fraintenda le astrazioni e riutilizzi il codice.

L'intero settore dello sviluppo software si basa su astrazioni. Solo perché non usarli, cioè evitare l'uso di framework, librerie e in generale codice che non è scritto internamente, aumenterebbe il costo necessario per produrre un pezzo di software di centomila, probabilmente anche di più.

Come se non creassi un jumbo-jet da zero, senza utilizzare le conoscenze ingegneristiche sviluppate per anni durante la costruzione di altri aeromobili, non scrivi software aziendale da zero.

Lo capisci usando PHP o Ruby in primo luogo, hai già un'enorme quantità di astrazioni, vero? I più ovvi:

1. Il sistema operativo, il linguaggio di programmazione e il compilatore forniscono un'enorme astrazione su assemblatore e hardware,

2. Il web server fornisce un'astrazione di socket, failover, protocollo HTTP, ecc.,

3. SQL fornisce un'astrazione sul modo in cui i dati vengono archiviati su un supporto di archiviazione permanente e mantenuti in memoria per un accesso più rapido, garantisce ACID, mirroring, ecc.

Puoi sempre provare a creare un'app Web senza utilizzare né un sistema operativo, né un server Web, un database o un linguaggio di programmazione di alto livello. Scoprirai rapidamente che hai passato anni a reinventare la ruota, ovvero a ricreare il tuo linguaggio di programmazione, il tuo server web e il tuo database, dato che la loro qualità sarebbe lontana dalla qualità dei prodotti che effettivamente utilizziamo.

I frame non sono diversi da quello. Puoi fare quello che fanno. Solo che perderai tempo a rifare la stessa funzionalità, con la differenza che quei framework lo faranno meglio e molto spesso il loro codice sarà testato e documentato meglio del tuo.

Prendi l'esempio di un carrello per un sito Web di e-commerce. Puoi inventare il tuo e passare alcune settimane a svilupparlo, oppure puoi prendere quello che è stato sviluppato per anni da un gruppo di persone all'interno di un framework. Ci si aspetta che vengano testati, senza contare il fatto che nel giro di pochi anni quegli sviluppatori hanno scoperto e corretto un sacco di bug che non immaginerai durante lo sviluppo del tuo carrello.

Puoi rispondere che il loro è più complicato perché ha più casi di utenti. Ad esempio, i loro dovrebbero occuparsi degli sconti, mentre non hai sconti sul tuo sito web e non hai bisogno di questa funzione nel carrello. Bene, non sei obbligato a utilizzare questa funzionalità e non è come se penalizzasse le prestazioni della tua app web.

Potresti avere uno scenario molto semplice quando è davvero più semplice sviluppare il tuo carrello invece di usare quello esistente. Allo stesso modo, se l'unica cosa di cui la tua app ha bisogno è memorizzare un elenco di numeri, niente di più, non è necessario un database: sarebbe sufficiente un semplice riempimento di testo. In questi casi, non progettare eccessivamente la tua app: scenari semplici richiedono soluzioni semplici.

Un altro fattore è la leggibilità del tuo codice. Immagina di aver creato un sito Web di e-commerce. Successivamente, hai lasciato il progetto e un altro sviluppatore dovrebbe mantenerlo.

• Se avessi usato un carrello fornito da un framework, il tuo collega sarebbe sollevato: deve mantenere un piccolo codice che si basa su un framework affidabile, ampiamente documentato. Ancora meglio: questo sviluppatore potrebbe essere stato utilizzato per lavorare con questo framework e gli è familiare. Altrimenti, può porre domande su Stack Overflow: sicuramente qualcuno ha già usato il framework.

• Se avessi il tuo carrello, il tuo collega dovrebbe mantenere un codice personalizzato, forse nemmeno documentato, senza poter ottenere aiuto ovunque.

Utilizzando un framework, fai affidamento su un codice che è:

• Scritto da sviluppatori esperti,

• Spesso rivisto in coppia,

• Unità collaudata,

• Ampiamente documentato,

• Utilizzato da anni da migliaia di sviluppatori,

• Spesso supportato, quindi puoi segnalare un bug e vederlo effettivamente risolto,

• Conosciuto da molti sviluppatori che conoscono i possibili avvertimenti e problemi e possono aiutare su siti come StackTranslate.it.

• Disponibile per te adesso, gratuitamente.

Sono d'accordo - la maggior parte dei framework diventa dittatori gonfiati. Promettono la libertà ma finisci in servitù. quindi guarda un framework come uno strumento: lo strumento migliore è quello che ti toglie di mezzo. Se in PHP suggerirei di dare un'occhiata al framework Codeigniter, perché è un elegante equilibrio tra convenzioni e libertà e ha una grande comunità. E per il poster che ha usato l'esempio di un carrello di e-commerce - Vorrei tanto essere d'accordo con te. ma avendo esaminato il codice per molte soluzioni di e-commerce - e ne ho progettate alcune - non sarei d'accordo con il tuo esempio.

Hmmm Un aspetto di LedgerSMB su cui abbiamo lavorato molto è stato il nostro approccio al framework. Ci sono due problemi fondamentali che derivano da questo tipo di astrazione. Questi sono:

1. Esplosione di dipendenza, e

2. Astrazione sbagliata

Il primo è in realtà migliore dell'alternativa che reinventa la ruota. Il secondo è un po 'difficile da etichettare perché può derivare da un caso problematico mal definito o, più spesso, da persone che usano qualcosa al di fuori dell'uso previsto.

Diamo un'occhiata agli ORM per esempio. Evito di usare gli ORM perché molto spesso il db finisce progettato per il modello a oggetti dell'applicazione perché nella migliore delle ipotesi sono strati di astrazione che perdono. Questo non è necessariamente il caso. Ho incontrato sviluppatori che riescono a preservare una buona progettazione del DB e una buona app durante l'utilizzo degli ORM ma ricorrono a molte cose che l'hype hype dice che non dovrebbero essere richieste, come l'incapsulamento dell'API relazionale del db dietro viste aggiornabili.

Un grosso problema ovviamente è che più il codice è altamente automatizzato, soprattutto quando è anche opaco, più è difficile vedere cosa non va. Questo è un punto sugli ORM che @jhewlett espone sopra (vedi /software//a/190807/63722 ).

Un buon parallelo potrebbe essere l'avionica avanzata come struttura per il pilotaggio di un aereo. Questi sono stati altamente progettati per l'affidabilità e sono un fattore nell'aumento della sicurezza del volo. Tuttavia, come molti articoli nell'IEEE Spectrum sottolineano ciò, ciò ha un costo di recuperabilità da errori al di fuori dei limiti di ciò che è considerato accettabile dal punto di vista dell'automazione. Lo stesso vale per il debug. Una cosa è il debug del codice SQL nel tuo programma. È molto diverso eseguire il debug di una parte del programma che scrive codice SQL da utilizzare per il programma.

Abbiamo scritto il framework LedgerSMB da zero perché al momento in cui abbiamo iniziato, non c'erano framework davvero buoni che facessero quello che volevamo. In realtà è una cosa di cui sono abbastanza contento e, secondo un nuovo sviluppatore del progetto, rende la personalizzazione dell'applicazione abbastanza semplice. (In realtà manteniamo al minimo la generazione del codice SQL e ci concentriamo invece su funzioni definite dall'utente scritte a mano, il che significa che le parti di scrittura sql sono colla molto sottile). Sì, fornisce molta astrazione in alcuni punti, più di quanto alcuni programmatori si sentano a proprio agio (in particolare "mappare le proprietà degli oggetti sugli argomenti in quella procedura memorizzata" ci fa tornare di tanto in tanto). Cerchiamo, tuttavia, di mantenere tutto semplice e coerente in modo che sia semplice determinare cosa è andato storto. Funziona abbastanza bene.

Alla fine "troppo" è un po 'soggettivo, ma a livello oggettivo dipende anche da cosa stai facendo. Se stai facendo esattamente ciò per cui è stato progettato il framework, un framework ben progettato fornirà una quantità perfetta di astrazione. Se stai facendo qualcosa che è un po 'meno adatto, l'astrazione diventerà sia troppo che troppo colante.

Sì, sono utili. Ti offrono il vantaggio di molti altri sviluppatori esperti che lavorano per risolvere un problema che devi risolvere, con l'ulteriore vantaggio di averlo testato, risolto molti bug e fornito soluzioni a problemi delicati di cui non devi preoccuparti te stesso usando il framework.

Possono essere gonfiati eccessivamente? Sicuro. Tutto dipende da ciò di cui hai bisogno e da ciò che il framework porta sul tavolo. Se hai una semplice app Web, forse Rails è eccessivo per te e dovresti considerare qualcosa di più semplice come Sinatra come soluzione.

C'è sicuramente una curva di apprendimento in tutti i framework, ed è più ripida con più lavoro che risparmia per te. Tuttavia, apprendere il framework significa che hai risparmiato tempo e puoi sfruttare tutta quella conoscenza sul prossimo progetto, invece di riscrivere l'applicazione da zero, una seconda volta.

Ma, dici, copierò il mio codice dal vecchio progetto e posso usarlo come punto di partenza per il mio nuovo progetto! Cambierò semplicemente ciò che è diverso, e forse renderò alcuni dei miei oggetti / funzioni più generali, e penserò a un modo migliore per risolvere quel difficile codice di codice! Congratulazioni, hai appena creato un framework. Fallo qualche altro migliaio di volte e hai qualcosa come Django, Rails o Zend.

I framework di solito comportano una maggiore produttività (forse dopo una leggera curva di apprendimento), ma spesso c'è un compromesso. In alcuni casi, ad esempio, si ottiene la produttività del programmatore a scapito della riduzione delle prestazioni.

Considerare Mapper oggetti-relazionali (ORM). Sono fantastici in quanto si occupano molto del noioso codice di mappatura per te. Potrebbero persino creare i tuoi oggetti per te. Tuttavia, nell'astrarre l'SQL, è molto più difficile ragionare sulle prestazioni e ottimizzare i colli di bottiglia.

Se stai creando un'applicazione che non avrà molti dati o query complesse, le prestazioni potrebbero non essere un problema per te. In effetti, il tempo del programmatore è il collo di bottiglia per molti progetti e quadri, librerie e linguaggi di alto livello aiutano ad alleviarlo.

Sono d'accordo che "usi le librerie, ma i framework ti usano". Questo è un modo molto semplice per dirlo. Non sono d'accordo sul fatto che non appena inizi a riutilizzare il codice, inizi a creare un framework, poiché di solito non è necessario fare molto di più di una copia e incolla rapida per utilizzare nuovamente il codice: è un biblioteca che stai costruendo; non c'è bisogno di diventare strani su come portare il codice nel tuo sito o nella tua app.

Per me, il punto cruciale è che devo ottenere di più da una risorsa di quanto mi richieda di investire. Oppure, da un altro punto di vista, direi che non appena i bisogni di un quadro sono superiori ai premi disponibili, tutti i vantaggi sono assenti. Quindi è 'Sì! Per favore! E grazie!' a tutti coloro che realizzano risorse che scenderanno dritte e funzioneranno secondo necessità all'interno del mio html / CSS / PHP e SQL.

Una cosa che trovo incomprensibile è che si dice che i framework facilitino la manutenzione? Se la complessa mesh di parti interworking non funziona come previsto, è meglio conoscere tutto ciò che c'è da sapere sul framework in questione. O essere pronto per un immenso input di nuova sintassi.

Alcuni dicono che questo è il Principio di Hollywood dei framework: "Non chiamarci, ti chiameremo". Al contrario, ogni volta che usi una libreria, il tuo codice chiama la libreria , non viceversa.

Come puoi vedere, il punto importante è chi ha il controllo - vale a dire, nel controllo del flusso di controllo. Chi decide quale affermazione viene eseguita dopo quale?

Ci sono argomenti a favore e contro, e ogni volta che vedo discussioni così infinite, tendo a pensare che questa debba essere una questione di gusti, piuttosto che una questione oggettivamente decidibile. Altrimenti, sarebbe già stato deciso.

Dal mio punto di vista, se preferisci usare framework o librerie, dice qualcosa sul tipo di sviluppatore che sei, e non se uno di entrambi gli approcci è superiore e alla fine prevarrà.

Se preferisci i framework, preferisci scambiare la libertà con la sicurezza: probabilmente sei più pragmatico e tendi a fidarti degli altri per svolgere correttamente il loro lavoro. Se preferisci le biblioteche, preferisci scambiare sicurezza con la libertà: probabilmente sei più un idealista e metti in discussione le idee e le affermazioni degli altri.

Non penso che sarebbe saggio decidere che è meglio essere come il primo o il secondo.

Rispondere alla tua domanda: i framework mettono troppa astrazione? Dipende da chi sei e in particolare da quale distanza dai primi principi ti senti a tuo agio.

...

E ancora più specificamente, se non ti piacciono i framework come Django, vai a cercare "microframeworks" come Flask :)