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

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

• Come chiarire e annotare ciò che vogliono i clienti ("requisiti"). Questa è un'arte in sé e per sé. Se puoi farlo, il tuo lavoro di programmazione sarà molto meglio.
• Come stimare e pianificare il progetto. Le persone ti chiederanno un preventivo, sii pronto.
• Come riesaminare costruttivamente il codice di altre persone.
• Modelli di design. Questo è un grande. Ma non usarli eccessivamente per il gusto di farlo.
• Scopri la differenza tra un bug, un problema e le richieste di funzioni
• 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 impieghi 2 giorni per provare a decodificare il tuo codice.
• Come organizzare la struttura del codice in modo che chiunque altro possa capirlo
• Come commentare il tuo codice
• Come scrivere test unitari
• Scopri cosa sta succedendo sotto il cofano. Ad esempio, chiamare un servizio Web: cosa sta facendo in realtà?
• Come astrarre la logica in classi.
• Come codice refactor
• Scopri il succo di alcuni linguaggi di programmazione. Saresti sorpreso di ciò che puoi imparare da altre aree
• Come dire agli altri programmatori cosa scrivere.
• Come spiegare alla direzione cosa stai facendo e perché.
• Come ha detto Peter, come eseguire il debug. Sono d'accordo con tutto ciò che dice, i veri programmatori eseguono il debug, non solo per indovinare.
• Come lavorare con i maniaci. Ce ne sono molti là fuori.
• Come OTTENERE FATTO FATTO. Tutta la teoria del mondo non ti aiuterà se non puoi fare le cose.

Ho risposto ad un'altra domanda lungo linee simili (con contenuti simili) qui:

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

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

Scopri come eseguire il debug.

Questo significa imparare il metodo scientifico . Intendo davvero per impararlo. E poi applicandolo con brutale auto-onestà . Impara come dichiarare esattamente ciò che sai è vero, ciò che sai è non vero, e quelle cose che non conosci. Ogni volta che assegni un articolo alla categoria sbagliata, hai reso la vita un lotto più difficile.

Impara a dire "I think" invece di "I know". Puoi solo dire "Lo so" quando "pensi" che qualcosa è vero (o falso), e poi lo dimostri!

Molti bug sono banali, ma possono essere difficili da vedere perché "sai" quale dovrebbe essere il codice ... tranne che non lo è. Trova un amico per spiegarlo. Chiedi loro di essere un "esperto idiota": qualcuno che non conosce il tuo codice, ma chi conosci non può ignorare BS. don essere sorpreso se nel bel mezzo di descriverlo a loro improvvisamente si fermano e dicono: "e così puoi ... vedere ... vedere ... 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 non correlati alla temporizzazione è Wolf Fence in Alaska. C'è un lupo da qualche parte in Alaska; costruire una recinzione che taglia lo stato a metà. Da che parte sta il lupo? Taglia quel lato a metà. Mescolare, sciacquare, ripetere. Facendo questo 20 volte in posti ben scelti nel codice si riduce l'area in cui il bug (lupo) può essere a 1/1048576. Uccidi quel lupo.

Suggerimento: cerca handwaves -physical, mental o qualsiasi altro tipo. Non appena tu (o il tuo collega) indietreggi / dividi / riduci l'attenzione su una parte del codice, vai totalmente rabbioso . Perché l'area in cui conosci non può essere il bug, anche se hai passato ore / giorni a cercare la cosa d * mn e ancora non riesci a trovarla ... è la più alta posizione di probabilità per l'errore. Nessuno riceve un 'ciao' , nessuno (compresi la macchina, il sistema operativo, il compilatore o tu ) ottiene ogni sorta 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 soggetto a se stesso. IMNSHO, questa potrebbe essere la prova più clamorosa che essi (università / professori) non ti stanno insegnando a diventare programmatori, invece, ti stanno insegnando ad essere ... come loro? Harsh? Forse. Vero? Fatti un'idea. Ora provalo.

Temo che questa sia una domanda abbastanza ampia per chiunque possa rispondere in modo definitivo o autorevole, soprattutto considerando che si desidera un elenco con priorità. Ci sono molti programmatori là fuori, e lavorano su cose molto diverse - certo, i fondamentali rimangono gli stessi, ma ciò che è necessario per rimanere attivi nella memoria può essere molto diverso, e in effetti ci sono molti compiti in cui puoi stare carino di alto livello senza approfondire.

Sembra però che tu sia sinceramente preoccupato di come diventare uno sviluppatore migliore, e non solo un mestiere di jack-of-one. Lo trovo ammirevole e posso condividere alcune delle cose che mi hanno aiutato a imparare come programmare.

Praticamente tutta la programmazione si riduce agli algoritmi e alle strutture dati. Essi, a loro volta, sono esempi della più ampia domanda: come modelliamo le cose e i processi dal mondo reale in una rappresentazione tale che un computer possa capire. Se sei appena agli inizi, potrebbe essere utile usare un linguaggio di programmazione di livello superiore (come Java, Python, qualsiasi cosa) per familiarizzare con l'implementazione di strutture dati e algoritmi.

A un certo punto, dopo aver giocato con le strutture e gli algoritmi dei dati, potresti iniziare a fare quella domanda rosicchiante "ma come andiamo dal dire al computer cosa fare, al computer che effettivamente lo fa?" Quindi puoi esaminare il modo in cui un computer calcola realmente - 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, ad esempio, apre un file, senza codifica per un particolare livello basso interfaccia del disco rigido.

Questo è probabilmente un buon punto di partenza: come gli algoritmi e le strutture dati modellano i problemi dal 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 meno fumo e specchi rispetto a OO e linguaggi di scripting :)

YAGNI : "Attua sempre le cose quando ne hai effettivamente bisogno, mai quando prevedi di averne bisogno ".

Secondo la mia esperienza, è normale che i "programmatori" prevedano molti casi in futuro e provino a "migliorare" il codice aggiungendo codici per anticiparli! Nella maggior parte dei casi, il codice aggiunto aggiunge semplicemente il codice e aumenta la complessità del codice.

La cosa più importante da sapere sull'essere un programmatore è che scrivere codice è un po 'duro, e un atteggiamento da "operaio" da operaio per produrre quello che ti viene pagato per produrre ti porterà più lontano di qualsiasi apprendimento esoterico.

Impara ad entrare nella zona. Con ciò intendo lo stato mentale quando ti concentri solo sul tuo compito e puoi iniziare a mantenere moltissime cose nella tua testa e in che modo interagiscono contemporaneamente. Una volta che hai l'abitudine di entrare nella zona a volontà, inizia a preoccuparti del resto. Fino a quando non riesci a digitare il codice come una sorta di codice che spacca qualcosa, il resto è praticamente inutile.

EDIT:

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

Una domanda recente, relativa in qualche modo a questo, e Risposta ha avuto un link a Questo blog che discute lo stesso problema da una diversa angolazione.

Probabilmente il concetto più importante per qualsiasi sviluppatore è "umiltà" .... Una volta accettato, non sai tutto, sei aperto a esplorare soluzioni. La maggior parte delle persone che scrivono blog sulla programmazione sono nella percentuale più alta, e il problema è che molti devono ancora controllare le loro tendenze narcisistiche ... ed è per questo che pubblicizzano blog ... Devi imparare a identificare questi blogger e ignora i lamenti

Il blog collegato non è altro che uno sproloquio - In ogni settore si lamenta che i neolaureati sono inutili sono comuni, che occorrono anni per renderli utili e produttivi. Forse il problema è che questi guru autoproclamati si aspettano davvero troppo e hanno dimenticato che una volta non avrebbero potuto risolvere FizzBuzz. Non tutti possono essere nel 10 percentile più alto, per definizione, metà dei programmatori sono al di sotto della media ......