L'abbondanza di quadri muta i programmatori? [chiuso]

D'accordo. Attualmente lavoro su un pacchetto software che è così ingombrato da framework che rende quasi impossibile capire il business. Una volta che i framework ti rimuovono dal risolvere davvero i problemi aziendali invece di risolvere solo MVC , è andato troppo lontano. Come dichiari, IMO molti programmatori provano e progettano / programmano per risolvere l'ORM e l'MVC e raramente chiedono se questo in realtà aiuti in qualche modo a risolvere il problema per cui il software è presente.

Sì, so che vedere alcuni SQL grezzi in una pagina JSP è un "no-no", ma se tu Sei un consulente di campo, dove si adatta a una soluzione specifica? E no, questo non significa che il framework non sia corretto, non tutti i clienti hanno 20.000 dollari seduti attorno ad ogni turno per garantire che un punto dati secondario sia proiettato sulla pagina.

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

La forma generale di questo argomento è:

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

Ad esempio:

• Il software CAD è destinato a ingegneri peggiori?
• I calcolatori delle superiori rendono gli studenti peggiori in matematica?
• Il software socializza le abilità sociali di persona delle persone?
• Il software di contabilità produce contabili peggiori?

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

Una comprensione più approfondita dei fondamenti con qualsiasi lavoro sarà di aiuto, indipendentemente da quello che fai, anche lavori considerati "correttivi". La conoscenza aiuta sempre.

L'astrazione è un concetto chiave di programmazione e framework per computer che aiuta i programmatori a raggiungere questo obiettivo. Questa è una buona cosa. Dubito che molti di noi vorrebbero sviluppare sistemi complessi in linguaggio assembly! Il problema viene, penso, quando i programmatori hanno poca idea di ciò che il livello di astrazione sta mascherando. In altre parole, devi avere un'idea di cosa succede sotto il cofano, anche se non interagisci o non ti interfaccia direttamente con esso.

Ricordo di aver sviluppato alcuni dei primi siti Web dinamici a metà degli anni '90, usando C e CGI (alla volta quando la maggior parte dei siti Web era ancora in HTML statico). Non c'erano in realtà linguaggi di scripting lato server maturi (come PHP o ASP) e poche librerie, quindi dovevi scrivere l'intero stream di risposta HTTP sul server con ogni pagina. L'analisi dei parametri GET e POST richiedeva la scrittura della propria libreria. Era noioso, lento, laborioso e molto incline agli errori. Non mi manca un po '!

Tuttavia, ritengo anche che framework come le forme web ASP.NET astraggono l'intera natura stateless del web fino al punto in cui molti nuovi sviluppatori web hanno poca idea di ciò che effettivamente sta succedendo sotto il cofano. Questo porta a un codice inefficiente e gonfio che funziona male perché lo sviluppatore sta assemblando i componenti insieme usando una metodologia "drag'n'drop" senza rendersi conto di cosa sta succedendo a livello HTTP.

Quindi, credo che i framework siano essenziali per lo sviluppo di software di alto livello, ma non assolvono gli sviluppatori di avere una certa comprensione di ciò che viene sottratto. Sì, i framework possono renderti stupido, ma solo se non riesci a capirli.

La trasmissione automatica o il tergicristallo per il rilevamento della pioggia ci rendono piloti peggiori?

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

Alla fine spetta allo sviluppatore imparare. Quelli buoni, quelli cattivi no.

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

Penso che il problema sia che i nuovi programmatori iniziano 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 fondamenti di base veramente fondamentali che sarebbero le prime cose imparate negli anni passati.

Scuoto la testa ogni volta qui quando un nuovo programmatore, ovviamente, sta chiedendo qualcosa su, ad esempio, memorizzando alcuni dati, e tutti immediatamente dicono loro di usare un ORM . No, no, no, no, no ... devono prima imparare a 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 le strutture a smorzare i programmatori. I programmatori stupidi saranno stupidi se usano framework o no.

È certamente vero che capire il lavoro di basso livello che uno strumento o una struttura ti aiuta a semplificare ti rende un utente migliore degli strumenti e dei framework. Puoi anche 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 a usare parser come lex e yacc. E '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 ogni programmatore debba faticare a cerare la macchina di Mr. Miyagi per anni e anni prima che gli venga permesso di lavorare ad alto livello. Un sacco di lavoro di programmazione è intellettuale, decide cosa il software deve fare , non il lavoro meccanico di codifica in un particolare linguaggio o strumento.

Quel lavoro intellettuale è dove l'intelligenza e la stupidità sono ancora più importanti.

Citando l'eccellente "Dending di spesa di Moore" di James Larus (enfasi aggiunta):

Thirty years ago, Bill Gates changed the prompt in Altair Basic from “READY” to “OK” to save 5 bytes of memory. Today, it is inconceivable that developers would be aware of this level of detail of their program, let alone concerned about it, and rightly so, since a change of this magnitude is today unnoticeable... There is no way we could produce today’s systems using the artisan, handcrafted practices that were possible (necessary) on machines with 4K of memory.

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

I quadri 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 un sacco di tempo usando MFC invece dell'API di Windows , ma senza la conoscenza dell'API (che significa avere uno sfondo di lavoro reale con l'API raw), sarebbero spesso bloccati. Non è quasi mai successo, perché un tipico programmatore MFC aveva conoscenze API di Windows.

Tuttavia, con Windows Form su . NET , grazie alla migliore incapsulamento e al migliore modello di oggetti, un programmatore può quasi ignorare che sta usando solo un altro wrapper API 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 le intelligenze 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 creare sull'ultimo e rimuovere il testo standard dalla costruzione di applicazioni utili.

Coloro che hanno bisogno o vogliono conoscere la "roba" dietro la struttura studieranno e indagheranno con un gancio o con un truffatore.

No, assolutamente no. I framework sono, al loro centro, una combinazione di una libreria di subroutine e un template, due strumenti programmatori collaudati. È un povero operaio che incolpa i suoi strumenti ...

... e ci sono molti di lavoratori poveri che usano e incolpano i quadri.

Quando si creano software, i framework risparmiano tempo. Quando si impara a costruire software, i framework si intromettono nella comprensione.

Penso che il problema sia principalmente uno dei computer diventato troppo potente. Per la maggior parte dei programmatori non c'è più ragione ragionevole per "scendere alle origini". Ci vuole solo più tempo per fare le stesse cose, e in fase di esecuzione non ci sono differenze significative. L'unico modo per risolverlo è introdurre restrizioni artificiali, il modo in cui competono le gare come js1k.

Forse le scuole dovrebbero avere un argomento dedicato "design ottimizzato" in cui devi creare programmi in condizioni di spazio e tempo limitate?

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 Framework avrà funzioni che i programmatori usano ancora e ancora.

Per apparentemente giocare l'avvocato del diavolo qui, penso che le strutture (quelle "buone", comunque) possono in realtà fare un lungo cammino verso promuovere l'educazione di un programmatore. Un framework ben progettato risolverà molti problemi e, utilizzando il framework, il programmatore può arrivare a capire quali problemi vengono risolti e come. Nella mia mente, un framework è (dovrebbe essere) una cristallizzazione della programmazione delle best practice e può insegnare ad un programmatore con l'esempio.