I quadri mettono troppa astrazione? [chiuso]

I quadri possono essere davvero difficili. I problemi possono facilmente sorgere quando un framework è troppo "supponente", cioè quando preferisce davvero uno stile di applicazione particolare 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 login da qualche parte e voilà, si ottiene l'autenticazione dell'utente gratuitamente. Questo ti ha fatto risparmiare un sacco di lavoro ripetitivo preoccupandoti dei cookie, dell'archiviazione delle sessioni, dell'hashing delle password e di tutto il resto.

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 attivare un'azione, ma il framework non ne offre uno. Forse hai bisogno di modificare i dettagli del cookie che viene impostato, ma il framework non offre alcun modo per personalizzarlo.

L'astrazione consentita dal framework ti ha permesso di aggiungere una funzionalità importante al tuo sito in pochi minuti anziché inizialmente, ma alla fine potresti dover combattere contro il framework per fargli fare ciò che ti serve, o dovrai reinventare nuovamente la funzionalità da zero in ogni caso, in base alle tue esigenze.

Questo non vuol dire che le astrazioni 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 addirittura framework di produzione per un tipo di app molto specifico e limitato. Altri framework sono più simili a collezioni di componenti liberi che puoi utilizzare, ma che ti consentono comunque una grande flessibilità per cambiarlo più tardi.

Quando usi un'astrazione, dovresti sempre capire almeno approssimativamente cosa sta distruggendo. Se non comprendi 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 codice che lo faccia già, invece di dover scrivere noiosamente te stesso, le astrazioni sono un ottimo risparmio di tempo. Le astrazioni scritte male possono metterti nei guai più tardi, quindi è una spada a doppio taglio.

Dovresti anche distinguere tra astrazioni tecniche e "regole aziendali" . Programmare in un linguaggio di livello superiore è un'astrazione che probabilmente non vuoi perdere (Python, PHP, C # rispetto a C vs Assembler, Less vs. CSS), mentre le "astrazioni delle regole aziendali" 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 è necessario eseguire il debug del codice macchina durante la scrittura di applicazioni in Python. Le astrazioni delle regole aziendali funzionano allo stesso livello tecnico e sono davvero solo "pacchetti di codice". Probabilmente sarà necessario eseguire il debug del cookie impostato o dell'hash della password che viene creato in un determinato momento, il che significa che ti immergerai attraverso un sacco di codice di terze parti.

Mi sembra che tu abbia frainteso le astrazioni e il riutilizzo del codice.

L'intero settore dello sviluppo del software è basato su astrazioni. Solo perché non li utilizza, evitando l'uso di framework, librerie e codice generale che non è scritto in-house, aumenterebbe il costo necessario per produrre un software di centinaia, forse anche di più.

Come se non avessi creato un jumbo jet da zero, senza utilizzare alcuna conoscenza ingegneristica sviluppata per anni quando costruisci altri velivoli, non scrivi software aziendale da zero.

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

1. Il sistema operativo, il linguaggio di programmazione e il compilatore forniscono un'enorme astrazione su Assembler 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 conservati in memoria per un accesso più rapido, garantisce ACID, mirroring, ecc.

Si può 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 tuo database, dato che la qualità sarebbe lontana dalla qualità dei prodotti che effettivamente usiamo.

I quadri non sono diversi da quello. Puoi fare quello che fanno. Solo che perderai tempo a rifare la stessa funzionalità, con la differenza che quelle strutture lo faranno meglio e molto spesso il loro codice verrà 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 qualche settimana a svilupparlo, oppure puoi prendere quello che è stato sviluppato per anni da un gruppo di persone all'interno di un quadro. Ci si aspetta che il loro test venga testato, senza contare il fatto che durante alcuni anni, quegli sviluppatori hanno scoperto e patchato un sacco di bug che non immaginereste quando svilupperete il vostro carrello.

Potresti rispondere che la loro è più complicata perché ha più casi utente. Ad esempio i loro dovrebbero occuparsi dei rimborsi, mentre non si hanno sconti sul tuo sito web e non hanno bisogno di questa funzionalità nel carrello. Beh, non sei obbligato a usare questa funzione e non è che penalizzerà le prestazioni della tua app web.

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

Un altro fattore è la leggibilità del tuo codice. Immagina di aver creato un sito di e-commerce. In seguito, 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 pezzo di codice che si basa su un framework affidabile e strongmente documentato. Ancora meglio: questo sviluppatore potrebbe essere stato utilizzato per lavorare con questo framework ed è familiare ad esso. In caso contrario, può porre domande su Stack Overflow: certo, qualcuno ha già utilizzato il framework.

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

Usando un framework, ci si basa su un codice che è:

• Scritto da sviluppatori esperti,

• Spesso recensito da coppie,

• Unità testata,

• Estensivamente documentato,

• Usato per 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 può aiutare su siti come Stack Overflow.

• Disponibile per te in questo momento, gratuitamente.

Sono d'accordo: la maggior parte delle strutture diventano dittatori gonfiati. Promettono la libertà ma finisci in servitù. quindi guarda un quadro come uno strumento: lo strumento migliore è quello che ti tiene lontano. Se in PHP suggerirei di verificare il framework Codeigniter, perché è un elegante equilibrio tra convenzioni e libertà e ha una grande comunità. E al poster che ha usato l'esempio di un carrello di e-commerce - Vorrei tanto poter essere d'accordo con te. ma avendo esaminato il codice per molte soluzioni di e-commerce - e ne ho progettato alcuni - non sarei rispettosamente in disaccordo con il vostro esempio.

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

1. Esplosione di dipendenza e

2. Astrazione errata

Il primo è in realtà migliore dell'alternativa che sta reinventando la ruota. Il secondo è un po 'difficile da etichettare perché può provenire da un caso problematico scarsamente definito o, più spesso, da persone che usano qualcosa al di fuori della sua destinazione d'uso.

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

Un grosso problema, naturalmente, è che più il codice è altamente automatizzato, in particolare quando è opaco, più difficile è vedere cosa sta andando male. Questo è un punto sugli ORM che @jhewlett fa sopra (vedi link ).

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

Abbiamo scritto il framework LedgerSMB da zero perché al momento in cui abbiamo iniziato, non c'erano framework davvero validi che facessero ciò che volevamo. In realtà sono una cosa di cui sono abbastanza soddisfatto e, secondo uno sviluppatore più recente del progetto, rende la personalizzazione dell'applicazione abbastanza semplice. (Manteniamo effettivamente la generazione del codice SQL al minimo e ci concentriamo invece su funzioni definite dall'utente scritte a mano, il che significa che le porzioni di scrittura sql sono molto sottili). Sì, fornisce molte astrazioni in alcuni punti, più di quanto alcuni programmatori stiano a proprio agio (in particolare "le proprietà degli oggetti della mappa per gli argomenti in quella stored procedure" ci fa tornare indietro di tanto in tanto). Cerchiamo, tuttavia, di mantenere tutto semplice e coerente in modo che sia facile determinare cosa è andato storto. Funziona piuttosto bene.

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

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

Possono essere overkill gonfiati? Sicuro. Tutto dipende da ciò che ti serve e da ciò che la struttura porta in tavola. Se hai una semplice web app, forse Rails è eccessivo per te, e dovresti guardare a qualcosa di più semplice come Sinatra come soluzione.

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

Ma, tu dici, mi limiterò a copiare 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 penso a un modo migliore per risolvere quel bit di codice complicato! Congratulazioni, hai appena creato un framework. Fatelo qualche migliaio di volte in più e avete qualcosa come Django, Rails o Zend.

I quadri di solito producono più produttività (forse dopo una leggera curva di apprendimento), ma spesso c'è un compromesso. In alcuni casi, ad esempio, si guadagna la produttività del programmatore al costo di prestazioni ridotte.

Considera gli ORM (Object-Relational Mappers). Sono fantastici in quanto si prendono cura di un sacco di noioso codice di mappatura per te. Potrebbero persino creare i tuoi oggetti per te. Tuttavia, con l'astrazione di SQL, è molto più difficile ragionare sulle prestazioni e ottimizzare i colli di bottiglia.

Se stai creando un'applicazione che non ha 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 framework, librerie e linguaggi di alto livello aiutano ad alleggerirlo.

Sono d'accordo che "Tu usi le librerie, ma i framework ti usano". Questo è un modo molto carino per dirlo. Non sono d'accordo sul fatto che non appena inizi a riutilizzare il codice stai iniziando a costruire un framework, dato che di solito non devi fare molto più di una copia e incolla veloce per riutilizzare il tuo codice - questo è un libreria che stai sviluppando; Non c'è bisogno di essere 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 quella che mi richiede di investire. Oppure, da un altro punto di vista, direi che non appena il bisogno di un quadro è maggiore della ricompensa disponibile, tutti i vantaggi sono assenti. Quindi è "Sì! Per favore! E grazie!' a tutti coloro che creano risorse che andranno dritte e funzioneranno come necessario all'interno del mio html / CSS / PHP e SQL.

Una cosa che trovo incomprensibile è che si dice che le strutture semplificano la manutenzione? Se la complessa trama di parti di interworking non funziona come previsto, è meglio sapere tutto ciò che c'è da sapere sul framework in questione. O essere pronto per un enorme 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 il contrario.

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

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

A mio avviso, se preferisci usare framework o librerie, devi dire qualcosa su che tipo di sviluppatore sei, e non se uno di questi due approcci sia superiore e alla fine prevarrà.

Se preferisci i framework, preferisci scambiare la libertà per la sicurezza: probabilmente sei più pragmatico e tendi a fidarti degli altri per fare il loro lavoro correttamente. Se preferisci le biblioteche, preferisci scambiare la 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: le strutture mettono troppa astrazione? Dipende da chi sei, e in particolare da quale distanza dai primi principi ti senti a tuo agio.

...

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