Si basa molto sull'intelligenza e sulla documentazione mentre la codifica ti rende un programmatore cattivo? [duplicare]

È completamente normale. Quasi nessuno può dire di conoscere la sintassi di ogni classe, funzione o framework PHP o Java.

Il tuo cervello è meglio utilizzato per risolvere i problemi che per memorizzare le cose.

Ovviamente tendi a memorizzare le cose che usi quotidianamente, ma non appena passano diversi mesi senza fare quella cosa specifica, dimentichi la sintassi.

Se ricordare la sintassi era fondamentale nello sviluppo, i computer avrebbero già sostituito gli umani in quel campo.

Usare il cervello per l'astrazione, l'immaginazione, la risoluzione dei problemi e il riconoscimento dei pattern non ha prezzo. Per tutto il resto, c'è Master Card. (1)

(1) O in questo caso documentazione, completamento automatico ecc.

Ciò che non dovresti fare in modo definitivo è chiedere ai tuoi collaboratori ogni volta che non ricordi la sintassi di qualcosa. Sarebbe pigrizia.

In termini di memorizzazione, penso che sia piuttosto cruciale avere una solida conoscenza della sintassi di base della tua lingua. Ciò significa non significa, tuttavia, che è necessario memorizzare le librerie principali. Per Java è il JSCL, per C # / VB che è .NET, per PHP è, beh ... quello.

Ad ogni modo, il punto è, conosci la tua sintassi, ma non necessariamente ogni classe, funzione e / o metodo. Conoscere la sintassi è come conoscere la grammatica in inglese: sai come dovrebbe essere formata una frase. Conoscere le biblioteche è più simile al vocabolario. Se non conosci una parola, puoi cercarla abbastanza facilmente; potresti non trovare la parola perfetta, ma troverai qualcosa di adatto. Se non conosci la grammatica, avrai molto più difficile ottenere un messaggio in modo chiaro e corretto e sarà molto più difficile cercare ciò di cui hai bisogno quando ne hai bisogno.

Sto per raccontarti una storia.

Fino al 30 maggio 1999, John Carmack non sapeva che il test delle forbici non era abilitato di default in OpenGL .

The next thing is sort of funny. I had been suspecting that a lot of the OpenGL drivers were clearing the entire depth buffer for each of the 3D icons on the status bar, instead of limiting it to the scissor region. I added code to the g200 driver to explicitly crop the clear region in the driver, but it never got executed. A little more investigation showed that I had been making an improper assumption for years -- scissor is not enabled by default. Doh.

L'averlo scoperto per errore, nel contesto di fare qualcos'altro, e ha dato al suo codice un incremento di prestazioni abbastanza buono (dato che lavora in un'area in cui la performance è estremamente importante, vale la pena notare):

Now I know that I was just being an idiot about that for the last three years... With scissor enabled, most of the cards got a few percent faster.

Vale anche la pena di notare la sua auto-consapevolezza qui: "Ero solo un idiota per quello negli ultimi tre anni".

Ora, se avesse letto la documentazione ("Il test è inizialmente disabilitato "), lui sarebbe stato consapevole del fatto che il test delle forbici era disabilitato di default e non avrebbe commesso quell'errore.

Questo è un caso in cui la documentazione di lettura avrebbe reso John Carmack un programmatore malvagio? E 'un caso in cui non leggere la documentazione ha reso John Carmack un programmatore migliore? Non credo di dover rispondere a queste domande.

Per quanto riguarda l'intellisense, è importante rendersi conto che l'intellisense è uno strumento di produttività, progettato per risparmiare tempo. Tu digiti "." o "- >" e su pop un elenco di membri, si digita i primi caratteri di quello che si desidera, e hey-presto! Questo è il tuo tempo prezioso che è stato salvato, potrebbe anche averti salvato una build a causa di quel supino errore che hai fatto perché non avevi ancora il tuo caffè, e ora hai più tempo per andare avanti con facendo produttivi roba invece di estrarre semplicemente il codice.

Intellisense è non progettato come stampella per i programmatori cattivi, è un esempio di ciò che Fred Brooks chiama uno "Strumento Sharp".

Seguendo la stessa logica con cui si può licenziare l'intellisense, si giunge alla ovvia conclusione finale che qualsiasi strumento progettato per aumentare la produttività del programmatore è anche qualcosa che può rendere un programmatore cattivo. Questa è una linea di pensiero pericolosa perché la prossima cosa che rifiuterà i compilatori e i debugger.

Quando ero al college del secolo scorso, uno dei miei docenti ci disse che "i migliori programmatori sono pigri". Questo è molto ironico, e ciò che intendeva era che i migliori programmatori trovavano il modo di massimizzare il tempo produttivo e minimizzare il tempo speso a fare il lavoro degli asini. Penso ancora che sia un buon consiglio oggi.

Is a programmer required to learn and memorize all syntax, or is it ok to keep handy some documentation?

No e sì. I programmatori che non possono apprendere cose nuove dalla documentazione sono paralizzati. Non possono risolvere nuovi problemi. Tutto quello che possono fare è il codice taglia e incolla che qualcun altro ha scritto. Preferisco i programmatori che leggono la documentazione, perché sanno abbastanza da non reinventare le funzioni di libreria esistenti. Assumendo, raramente mi interessa se il candidato ha esperienza con il nostro attuale linguaggio di implementazione. Potremmo iniziare a utilizzare una nuova lingua da un giorno all'altro, quindi voglio che le persone siano felici di lavorare in più lingue.

Would it affect the way that managers look at coders?

No, ad eccezione di un sottoinsieme di misura zero.

Assolutamente no; al contrario, ti rende un programmatore migliore dal momento che sono strumenti di produttività, e i programmatori che li utilizzano rendono un programma più veloce / migliore. Lo scopo del programmatore è di fare in modo che un programma non sappia come una libreria o un framework ha alcuni metodi o classi chiamati.

Un programmatore non ha necessariamente bisogno di conoscere la sintassi di una lingua; ma in qualche modo è obbligato a conoscerlo dal momento che il moderno IDE lo avverte immediatamente se qualcosa non va, quindi lo imparerà sicuramente solo per fermare l'IDE che richiede messaggi di errore. Davvero non riesco a immaginare nessuno che programmi con sottolineatura rossa sotto alcune parole, prima di risolvere il problema. Per quanto riguarda l'utilità di una biblioteca, deve sapere solo che una libreria può eseguire determinate funzionalità e alla fine troverà un modo per usarla.

Posso dire che il completamento del codice aiuta davvero un programmatore a trovare nuove funzionalità di una determinata libreria. Qualsiasi buona libreria si basa sull'astrazione - interfacce. Supponiamo di avere un'interfaccia Sort che dovrebbe eseguire una logica di ordinamento; ora questa logica può essere eseguita in vari modi, ma io come programmatore non so cosa possa fare veramente la libreria data. Così scrivo Sort sort = Ctrl + Spazio e immediatamente appaiono tutte le possibili implementazioni (ho davvero scoperto nuove cose su molte librerie in questo modo). Tra le implementazioni appare QuickSort , ma in realtà non ne so molto (nel mio IDE - Intellij) premo Ctrl + Q e vedo subito la documentazione della classe, e vedo come può essere usata. Le cose vanno oltre visto che potrei essere interessato a come QuickSort è implementato, quindi premo Ctrl + B e scelgo di scaricare l'implementazione dal repository Maven e vedo immediatamente il codice di implementazione.