Quali sono * i * concetti di programmazione che dovrei padroneggiare per avere una profonda comprensione del mio mestiere (programmazione)? [chiuso]

In ordine di importanza, se è possibile farlo e potrebbe non esserlo, quali sono le basi più importanti del saper programmare. Algoritmi, iterazione, ricorsione, ecc.?

Nota che dove ho messo ecc. È dove sta la mia domanda. Di recente ho letto un post su Internet in cui dicevano che 9 programmatori su 10 non potevano ansimare !

http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

Voglio avere una profonda conoscenza di ciò che sto effettivamente cercando di realizzare durante la programmazione e una comprensione esaustiva degli strumenti di base a mia disposizione. Fondamentalmente voglio poter dipingere con tutti i colori del vento.

Questa lista è un inizio ... stai facendo una grande domanda!

• Come chiarire e scrivere ciò che i clienti vogliono ("requisiti"). Questa è un'arte in sé e per sé. Se puoi farlo, il tuo lavoro di programmazione sarà molto migliore.
• Come stimare e progettare il piano. Le persone ti chiederanno un preventivo, sii preparato.
• Come rivedere in modo costruttivo il codice di altre persone.
• Modelli di progettazione. Questo è grande. Ma non usarli eccessivamente per il gusto di farlo.
• Scopri la differenza tra richieste di bug, problemi e funzionalità
• Tieniti aggiornato con framework / librerie. Non devi usarli, ma devi sapere cosa fanno e i loro pro / contro. Se qualcosa sembra troppo difficile, probabilmente c'è (si spera) un modo molto più semplice di fare le cose.
• Come documentare algoritmi complicati in un diagramma di flusso o semplicemente scriverlo in inglese. Non aspettarti che qualcuno passi 2 giorni a provare a decodificare il tuo codice.
• Come organizzare la struttura del codice in modo che chiunque possa capirlo
• Come commentare il tuo codice
• Come scrivere test unitari
• Scopri cosa succede sotto il cofano. Ad esempio, chiamando un servizio Web: cosa sta realmente facendo?
• Come sottrarre la logica alle classi.
• Come refactificare il codice
• Impara l'essenza di parecchi linguaggi di programmazione. Saresti sorpreso di ciò che puoi imparare da altre aree
• Come dire agli altri programmatori cosa scrivere.
• Come spiegare al management cosa stai facendo e perché.
• Come ha detto Peter, come eseguire il debug. Sono d'accordo con tutto ciò che dice, debug veri programmatori, non solo indovinare.
• Come lavorare con i maniaci. Ce ne sono molti là fuori.
• Come ottenere STUFF FATTO. Tutta la teoria del mondo non ti aiuterà se non puoi fare cose.

Ho risposto a un'altra domanda seguendo linee simili (con contenuti simili) qui:

suggerimenti, linee guida, punti da ricordare per il rendering del codice professionale?

Sotto l'intestazione di " ecc. " Arriva qualcosa che può facilmente richiedere il 50% o più del tuo tempo.

Scopri come eseguire il debug.

Ciò significa apprendere il metodo scientifico . Intendo davvero impararlo. E poi applicandolo con brutale onestà . Impara come affermare esattamente ciò che sai essere vero, ciò che sai non è vero e quelle cose che non conosci. Ogni volta che assegni sciatto un oggetto alla categoria sbagliata, hai appena reso la tua vita molto più dura.

Impara a dire "Penso" invece di "Lo so". Devi solo dire "Lo so" quando "pensi" qualcosa di vero (o falso), e poi lo provi!

Molti bug sono banali, ma possono essere difficili da vedere perché "sai" quale dovrebbe essere il codice ... tranne che non lo è. Trova un amico a cui spiegarlo. Chiedi loro di essere un "esperto idiota": qualcuno che non conosce il tuo codice, ma che sai di non poter superare BS. Non sorprenderti se nel mezzo di una descrizione per loro improvvisamente ti fermi e dici "e così puoi ... vedere ... vedere che ... sh * t. Grazie."

I bug non banali richiedono un arsenale di tecniche. Un classico che può rapidamente mettere in luce la maggior parte dei bug relativi al non tempismo è Wolf Fence in Alaska. C'è un lupo da qualche parte in Alaska; costruire una recinzione tagliando lo stato a metà. Da che parte sta il lupo? Tagliare quel lato a metà. Raccogliere, sciacquare, ripetere. Fare questo 20 volte in punti ben scelti nel codice riduce l'area in cui il bug (lupo) può essere a 1/1048576. Uccidi quel lupo.

Suggerimento: cerca le onde manuali: fisiche, mentali o di altro tipo. Non appena tu (o il tuo collega) sussultate / deviate / minimizzate l'attenzione prestata a una parte del codice, diventate totalmente rabbiosi . Perché l'area in cui conosci solo il bug non può essere, anche se hai passato ore / giorni a cercare l'oggetto d * mn e non riesci ancora a trovarlo ... questa è la posizione con la probabilità più alta per il bug. Nessuno riceve un "ciao" , nessuno (incluso il computer, il sistema operativo, il compilatore o te ) ottiene alcun tipo di "dovuto rispetto". C'è un bug. Periodo. Fine della frase Ora vai a uccidere la cosa d * mn.

Non conosco nessuna scuola che insegna il debug come materia a se stessa. IMNSHO, questa potrebbe essere la singola prova più evidente che loro (università / professori) non ti stanno insegnando a essere un programmatore, ti stanno invece insegnando a essere ... come loro? Harsh? Forse. Vero? Fatti un'idea. Ora dimostralo.

Temo che questa sia una domanda abbastanza grande a cui chiunque può rispondere in modo conclusivo o autorevole, soprattutto se si desidera un elenco prioritario. Ci sono molti programmatori là fuori, e lavorano su cose molto diverse - certo, i fondamenti rimangono gli stessi, ma ciò che è necessario per rimanere attivi nella memoria può essere davvero diverso, e in effetti ci sono molte attività in cui puoi rimanere carina di alto livello senza andare più in profondità.

Sembra però che tu sia sinceramente preoccupato di come essere uno sviluppatore migliore e non solo un tuttofare. Lo trovo ammirevole e posso condividere alcune delle cose che mi hanno aiutato a imparare a programmare.

Praticamente tutta la programmazione si riduce a algoritmi e strutture dati. A loro volta, sono esempi della domanda più ampia: come modelliamo cose e processi dal mondo reale in una rappresentazione in modo che un computer possa capire. Se hai appena iniziato, potrebbe essere utile utilizzare un linguaggio di programmazione di livello superiore (come Java, Python, qualunque cosa) per acquisire familiarità con l'implementazione di strutture di dati e algoritmi.

A un certo punto, dopo aver giocato con le strutture dati e gli algoritmi, potresti iniziare a fare quella domanda mordace "ma come possiamo passare dal dire al computer cosa fare, al computer che lo sta effettivamente facendo?" Quindi puoi vedere come calcola effettivamente un computer: come la memoria e la CPU lavorano insieme per eseguire le istruzioni, come i sistemi operativi astraggono l'hardware in modo da poter scrivere un programma che, diciamo, apre un file, senza codificare su un particolare livello basso interfaccia del disco rigido.

Questo è probabilmente un buon punto di partenza: come algoritmi e strutture dati modellano i problemi del mondo reale e come un computer esegue effettivamente il calcolo. Conoscere quest'ultimo è molto utile per padroneggiare linguaggi di livello inferiore come C, che utilizzano molto meno fumo e mirror rispetto a OO e linguaggi di scripting :)

YAGNI : "Implementa sempre le cose quando ne hai veramente bisogno, mai quando prevedi che ne hai bisogno."

Nella mia esperienza, è comune per i "programmatori" prevedere molti casi in futuro e provare a "migliorare" il codice aggiungendo codici per anticiparli! Nella maggior parte dei casi il codice che hanno aggiunto non farà altro che gonfiare il codice e aggiungere complessità al codice.

La cosa più importante da sapere sull'essere un programmatore è che scrivere codice è una seccatura, e un atteggiamento da "colletti blu" simile a quello degli operai nei confronti della produzione di ciò che ti viene pagato per produrre ti porterà più lontano di qualsiasi apprendimento esoterico.

Impara a entrare nella zona. Con questo intendo lo stato mentale quando ti concentri solo sul tuo compito e puoi iniziare a mantenere molte cose nella tua testa e come interagiscono tutte in una volta. Una volta che hai l'abitudine di entrare nella zona a tuo piacimento, inizia a preoccuparti per il resto. Fino a quando non puoi sborsare il codice come una specie di codice che sbatte fuori qualcosa, il resto è praticamente inutile.

MODIFICARE:

Se non ci credi e mi hai sottovalutato, credo che non sai se hai la determinazione di farlo per 20 anni. So che lo faccio perché accetto questo. ;)

Una domanda recente, collegata in qualche modo a questa, e Answer aveva un link a questo blog che discute lo stesso problema da una prospettiva diversa.

Probabilmente il concetto più importante per qualsiasi sviluppatore è "umiltà" .... Una volta accettato non si conosce tutto, si è aperti per esplorare soluzioni. La maggior parte delle persone che scrivono blog sulla programmazione sono in alto percentile, e il problema è che molti devono ancora controllare le loro tendenze narcisistiche .... ed è per questo che blog ..... Devi imparare a identificare questi blogger e ignorare lì rant

Il blog collegato non è altro che un rant - In ogni settore lamentano che i neolaureati sono inutili sono comuni, che ci vogliono anni per renderli utili e produttivi. Forse il problema è che questi autoproclamati guru si aspettano davvero troppo e hanno dimenticato che una volta non sarebbero stati in grado di risolvere FizzBuzz. Non tutti possono essere tra i primi 10 percentili, per definizione metà dei programmatori sono al di sotto della media ......