L'abbondanza di framework sta stupendo i programmatori? [chiuso]

Con tutti i framework disponibili in questi giorni, ORM , iniezione di dipendenza (DI), Inversion of control (IoC), ecc., Trovo che molti programmatori stanno perdendo o non hanno le capacità di problem solving necessarie per risolvere problemi difficili. Molte volte, ho visto comportamenti imprevisti insinuarsi nelle applicazioni e gli sviluppatori non sono stati in grado di scavare davvero e trovare i problemi. Mi sembra che la profonda comprensione di ciò che sta accadendo sotto il cofano si sta perdendo.

Non fraintendetemi , non sto suggerendo che questi framework non siano validi e non abbiano fatto avanzare il settore, chiedendo solo se, come conseguenza involontaria, gli sviluppatori non stanno acquisendo le conoscenze e le competenze necessarie per una profonda comprensione di sistemi.

Concordato. Attualmente lavoro su un pacchetto software che è così gravato da framework che rende quasi impossibile capire il business. Una volta che i framework ti rimuovono dalla risoluzione dei problemi di business anziché dalla semplice risoluzione di MVC , è andato troppo lontano. Come hai affermato, molti programmatori IMO cercano di progettare / progettare / risolvere l'ORM e l'MVC e raramente chiedono se ciò aiuti effettivamente in qualche modo a risolvere il problema per cui il software è presente.

Sì, so che vedere un SQL grezzo in una pagina JSP è un "no-no", ma se sei un consulente sul campo, dove si adatta una soluzione specifica? E no, ciò non significa che il framework non sia corretto, non tutti i clienti hanno $ 20k seduti ad ogni turno per garantire che un punto dati minore sia proiettato sulla pagina.

Questo è un argomento che si apre regolarmente, in molti campi e in molte forme.

La forma generale di questo argomento è:

Avere [x: strumento / tecnologia] peggiora le persone in [y: funzione influenzata da x]?

Per esempio:

• Il software CAD peggiora gli ingegneri?
• Le calcolatrici al liceo peggiorano gli studenti in matematica?
• Il social software mette in difficoltà le abilità sociali di persona?
• Il software di contabilità produce ragionieri peggiori?

Dalla memoria, la risposta onnipresente è quasi sempre: non proprio. Avrai sempre persone buone e cattive nel fare [y] ma ora sono cattive in un aspetto diverso dell'abilità.

Una comprensione più approfondita dei fondamenti di qualsiasi lavoro aiuterà, indipendentemente da ciò che fai, anche i lavori che sono considerati "correttivi". La conoscenza aiuta sempre.

L'astrazione è un concetto chiave della programmazione per computer e le strutture aiutano i programmatori a raggiungere questo obiettivo. Questa è una buona cosa. Dubito che molti di noi vorrebbero sviluppare sistemi complessi in linguaggio assembly! Il problema si presenta, penso, quando i programmatori hanno la minima idea di ciò che lo strato di astrazione sta mascherando. In altre parole, devi avere un'idea di ciò che accade sotto il cofano, anche se non interagisci direttamente con l'interfaccia.

Ricordo di aver sviluppato alcuni dei primi siti Web dinamici a metà degli anni '90, usando C e CGI (in un momento in cui la maggior parte dei siti Web era ancora HTML statico). In realtà non esistevano linguaggi di scripting lato server maturi (come PHP o ASP) e pochissime librerie, quindi è stato necessario scrivere l'intero flusso di risposta HTTP sul server con ogni pagina. L'analisi dei parametri GET e POST richiede la scrittura della propria libreria. Era noioso, lento, laborioso e molto soggetto a errori. Non mi manca neanche un po!

Tuttavia, sento anche quadri come i moduli web ASP.NET astrarre l'intera natura apolide del web a un punto in cui molti nuovi sviluppatori web hanno la minima idea di cosa stia realmente accadendo sotto il cofano. Ciò porta a un codice inefficiente e gonfio che funziona male perché lo sviluppatore sta installando i componenti insieme usando una metodologia "drag'n'drop" senza rendersi conto di ciò che sta accadendo a livello HTTP.

Quindi, credo che i framework siano essenziali per lo sviluppo di software di alto livello, ma non assolvono gli sviluppatori dall'aver capito qualcosa di ciò che viene sottratto. Sì, i framework possono renderti stupido, ma solo se non li capisci.

I tergicristalli con cambio automatico o con rilevamento della pioggia ci fanno peggiorare i conducenti?

Non credo che la codifica senza framework implichi necessariamente una migliore comprensione dei sistemi sottostanti. Ciò è dimostrato dai datori di lavoro che devono fare semplici domande di codifica durante le interviste solo per assicurarsi che il candidato possa mettere insieme un metodo coerente.

Alla fine spetta allo sviluppatore imparare. I buoni lo fanno, i cattivi no.

E allo stesso modo, scegliere un framework solo perché è lì senza effettivamente analizzarne le capacità e i pro / contro è anche un segno di cattive pratiche di sviluppo.

Penso che il problema sia che i nuovi programmatori stanno iniziando a livelli sempre più alti di astrazione, e quindi non vengono esposti ai bit e ai byte delle cose "sotto il cofano". Quindi non stanno imparando alcuni dei fondamentali di programmazione di base che sarebbero le prime cose apprese negli anni passati.

Scuoto la testa ogni volta qui quando un programmatore ovviamente nuovo chiede qualcosa su, diciamo, archiviando alcuni dati, e tutti immediatamente dicono loro di usare uno strumento ORM . No, no, no, no, no ... devono prima imparare come farlo da soli.

Forse la distribuzione di "stupidità" non è davvero cambiata, e invece stiamo semplicemente distribuendo modi più grandi e più complicati per gli sviluppatori di spararsi ai piedi?

Non sono i framework che stupiscono i programmatori. I programmatori stupidi saranno stupidi se usano i framework o no.

È certamente vero che comprendere il lavoro di basso livello che uno strumento o un framework ti aiuta a semplificare ti rende un utente migliore degli strumenti e dei framework. È inoltre possibile eseguire il debug dei problemi più facilmente e aggirare le inevitabili lacune nella funzionalità degli strumenti.

Ad esempio, ho preso una lezione in Compiler Design al college, dove abbiamo codificato un parser LR da zero in C, prima di imparare ad usare generatori di parser come lex e yacc. È stato molto istruttivo e da allora ho avuto una migliore comprensione e apprezzamento per tutti i linguaggi di programmazione che ho usato.

Ma non sto dicendo che tutti i programmatori sono tenuti a dilaniare la ceretta dell'auto del signor Miyagi per anni e anni prima che possano essere autorizzati a lavorare ad alto livello. Un sacco di lavoro di programmazione è intellettuale, decide ciò che il software deve fare , non il lavoro meccanico di codifica in un particolare linguaggio o strumento.

Quel lavoro intellettuale è dove intelligenza contro stupidità è ancora più importante.

Citando l'eccellente "Spending Moore's Dividend" (enfasi aggiunta):

Trenta anni fa, Bill Gates ha cambiato il prompt in Altair Basic da "READY" a "OK" per risparmiare 5 byte di memoria. Oggi è inconcepibile che gli sviluppatori siano consapevoli di questo livello di dettaglio del loro programma, figuriamoci preoccupati, e giustamente, dal momento che un cambiamento di questa portata è oggi impercettibile ... Non c'è modo di produrre i sistemi di oggi usando le tecniche artigianali e artigianali possibili (necessarie) su macchine con 4K di memoria.

Penso che probabilmente sia fuorviante affermare che i framework ti consentono di evitare le competenze necessarie per risolvere problemi difficili o di evitare una profonda comprensione. Invece, l' unica ragione per cui siamo in grado di costruire i sistemi complessi di oggi (la cui complessità può generare problemi difficili e sfidare la comprensione profonda) è perché abbiamo framework (e linguaggi OO di alto livello raccolti con immondizia e IDE con guida sensibile al contesto e controllo della sintassi al volo e tutti gli altri progressi nello sviluppo del software che a volte vengono criticati come programmatori stupidi).

I frame sono fantastici. Ma devi sapere cosa c'è sotto il cofano. Quindi il problema è che i programmatori fanno troppo affidamento sui framework, senza avere una conoscenza sufficiente del sistema sottostante.

Un esempio un po 'obsoleto è MFC : un programmatore potrebbe risparmiare molto tempo utilizzando MFC anziché l'API di Windows, ma senza la conoscenza dell'API (il che significa avere uno sfondo di lavoro reale con l'API non elaborata), sarebbero spesso bloccati . Non è quasi mai successo, perché un tipico programmatore MFC aveva una conoscenza delle API di Windows.

Tuttavia, con Windows Form su .NET , grazie al migliore incapsulamento e al miglior modello di oggetti, un programmatore può quasi ignorare che sta usando solo un altro wrapper API di Windows. Quindi ci sono meno possibilità di rimanere bloccati, ma quando succede, può far male.

Sfortunatamente, il time to market è sempre più breve ei progetti sono sempre più complessi, quindi i programmatori non hanno il tempo di approfondire. Questo è il triste stato dell'industria del software ...

Mette gli intelligenti dove deve essere. Non è necessario comprendere la meccanica quantistica e la fisica newtoniana per creare un meccanismo che fa cadere una palla dalla cima di un edificio. Ogni nuovo livello nel software dovrebbe basarsi sull'ultimo e rimuovere la piastra di caldaia dalla costruzione di utili applicazioni.

Coloro che hanno bisogno o vogliono conoscere le "cose" dietro il framework studieranno e indagheranno con il gancio o il truffatore.

No, assolutamente no. I framework sono, in sostanza, una combinazione di una libreria di subroutine e un modello, due strumenti di programmazione collaudati. È un povero operaio che incolpa i suoi strumenti ...

... e ci sono molti poveri operai che usano e incolpano i framework.

Durante la creazione di software, i framework risparmiano tempo. Quando si impara a costruire software, i framework ostacolano la comprensione.

Penso che il problema sia principalmente uno dei computer che sono diventati troppo potenti. Per la maggior parte dei programmatori non c'è più ragione ragionevole di "arrivare alle basi". Ci vuole solo più tempo per fare le stesse cose, e in fase di esecuzione non c'è differenza significativa. L'unico modo per risolverlo è introdurre restrizioni artificiali, come fanno le competizioni come js1k.

Forse le scuole dovrebbero avere una materia dedicata "design ottimizzato" in cui devi costruire programmi con forti limiti di spazio e di tempo?

No, l'apprendimento dei framework migliora le capacità di un programmatore. Framework è l'estensione di un linguaggio di programmazione. Alcune lingue sono già basate su framework. Lavoro con PHP e Java. PHP ha bisogno di un framework come template engine (a volte). Java non ha bisogno di un framework (la maggior parte delle volte), ha già molti metodi e librerie.

La maggior parte dei Frameworks avrà funzioni che i programmatori usano ancora e ancora.

Per interpretare apparentemente l'avvocato del diavolo qui, penso che i quadri ("buoni", comunque) possano effettivamente fare molto per promuovere l'educazione di un programmatore. Un framework ben progettato risolverà molti problemi e, usando il framework, il programmatore può capire quali problemi vengono risolti e come. Nella mia mente, un framework è (/ dovrebbe essere) una cristallizzazione delle migliori pratiche di programmazione e può insegnare un programmatore con l'esempio.