Cosa dovrebbe sapere ogni programmatore sulla programmazione?

Per favore, rimani su questioni tecniche , evita comportamenti, problemi culturali, di carriera o politici.

1. Il bug è nel tuo codice, non nel compilatore o nelle librerie di runtime.

2. Se vedi un bug che non può accadere, controlla di aver compilato e distribuito correttamente il tuo programma. (Soprattutto se stai usando un IDE complicato o un framework di build che cerca di nasconderti i dettagli disordinati ... o se la tua build comporta molti passaggi manuali.)

3. I programmi simultanei / multi-thread sono difficili da scrivere e più difficili da testare correttamente. È meglio delegare il più possibile a librerie e framework concorrenti.

4. Scrivere la documentazione fa parte del tuo lavoro come programmatore. Non lasciarlo fare a "qualcun altro".

MODIFICARE

Sì, il mio punto n. 1 è sopravvalutato. Anche le migliori piattaforme applicative progettate hanno la loro parte di bug, e alcune di quelle meno ben progettate sono piene di loro. Tuttavia, dovresti sempre sospettare prima il tuo codice e iniziare a incolpare i bug del compilatore / libreria solo quando hai prove chiare che il tuo codice non è in errore.

Nei giorni in cui ho fatto lo sviluppo di C / C ++, ricordo casi in cui i presunti "bug" dell'ottimizzatore si sono rivelati essere dovuti a me / qualche altro programmatore che ha fatto cose che le specifiche del linguaggio dicono che hanno risultati indefiniti. Questo vale anche per linguaggi apparentemente sicuri come Java; ad es. dare una lunga occhiata al modello di memoria Java (JLS capitolo 17).

• Come leggere il codice di altre persone.
• Il codice non esiste se non è selezionato nel sistema di controllo versione.

I calcoli in virgola mobile non sono precisi.

Non smettere di imparare.

Che la cosa numero 1 che puoi fare per aumentare la qualità e la manutenibilità del tuo codice è RIDURRE LA DUPLICAZIONE.

Competenze di risoluzione dei problemi e debug

A malapena trascorrono del tempo su questo argomento in nessuno dei corsi di programmazione che ho seguito, e nella mia esperienza è uno dei principali fattori determinanti della produttività di un programmatore. Piaccia o no, trascorri molto più tempo nella fase di manutenzione della tua app rispetto alla nuova fase di sviluppo.

Ho lavorato con moltissimi programmatori che eseguono il debug cambiando casualmente le cose senza alcuna strategia per trovare il problema. Ho avuto questa conversazione dozzine di volte.

Altro programmatore: penso che dovremmo provare a vedere se lo risolve.
Io: Okay, supponendo che lo risolva. Cosa ti dice su dove si trova l'origine del problema?
Altro programmatore: non lo so, ma dobbiamo provare qualcosa .

1. Non essere intelligente; essere chiaro.
2. Utilizzare prima del riutilizzo.
3. I nomi contano.
4. Una funzione fa 1 cosa e lo fa bene.
5. Piccolo è meglio di grande.

Le basi. Attualmente i programmatori apprendono le tecnologie e non i concetti. È sbagliato.

Ogni programmatore dovrebbe sapere che inserisce sempre delle assunzioni nel codice, ad esempio "questo numero sarà positivo e limitato", "questo codice sarà in grado di connettersi al server in un batter d'occhio".

E dovrebbe sapere che dovrebbe prepararsi per quando quelle ipotesi si rompono.

Ogni programmatore dovrebbe conoscere i test.

Impara i concetti . Puoi Google la sintassi.

Pensiero critico e logico. non puoi fare nulla di buono senza di essa.

Test unitari. Questo è un ottimo modo per codificare i tuoi presupposti su come usare il codice.

Il minimo assoluto Ogni sviluppatore di software deve assolutamente conoscere positivamente Unicode e set di caratteri (senza scuse!) .

È più difficile di quanto pensi.

Sebbene sia facile (ish) mettere insieme qualcosa che funzioni quando usato normalmente, gestire input errati, tutti i casi limite e angolare, possibili modalità di errore ecc. Richiede tempo e probabilmente sarà la parte più difficile del lavoro.

Quindi devi anche rendere l'applicazione buona.

Conoscenza del dominio. Le specifiche non sono mai al 100%; conoscere il dominio effettivo con cui si sta sviluppando aumenterà SEMPRE la qualità del prodotto.

Notazione O grande e sue implicazioni.

Alcuni riferimenti utili

• http://www.perlmonks.org/?node_id=227909
• http://www.programmerinterview.com/datastruct/big-o-notation-example.php
• http://en.wikipedia.org/wiki/Big_O_notation

Puntatori, ovviamente. :)

Codice completo 2 - da copertina a copertina

I dati sono più importanti del codice.

Se i tuoi dati sono intelligenti, il codice può essere stupido.

Il codice stupido è facile da capire. Anche i dati intelligenti.

Quasi ogni dolore algoritmico che io abbia mai avuto è stato dovuto al fatto che i dati si trovavano nel posto sbagliato o abusavano del suo vero significato. Se i tuoi dati hanno un significato, inseriscilo nel sistema dei tipi .

Quale lingua e ambiente è più adatto per il lavoro. E non è sempre il tuo preferito.

Dividere e conquistare. Di solito è il modo migliore per risolvere qualsiasi tipo di problema pratico dalla pianificazione al debug.

La vera abilità si riflette nella capacità di eseguire bene un progetto semplice, non nella capacità di far funzionare un progetto complicato.

Questa abilità deriva da una maggiore padronanza dei fondamenti, non dalla padronanza degli arcani. Un programmatore di alto livello non è definito dalla sua capacità di codificare ciò che gli altri non possono (utilizzando funzioni di livello superiore, programmazione funzionale avanzata, what-have-you) ma piuttosto dalla loro capacità di affinare la codifica perfettamente banale. Scelta della decomposizione appropriata della funzionalità tra le classi; costruzione robusta; utilizzando tecniche di programmazione difensiva; e usando schemi e nomi che portano ad una maggiore autocertificazione, questi sono il pane e il burro della programmazione di alto livello.

Scrivere un buon codice a cui tu, o qualcun altro, potete tornare in una settimana al mese o un anno e capire come usare, modificare, migliorare o estendere quel codice è cruciale. Ti fa risparmiare tempo e fatica mentale. Unge le ruote della produttività rimuovendo i blocchi stradali su cui ti saresti imbattuto prima (forse interrompendo il tuo treno di pensieri, o forse prendendo ore o giorni di sforzo lontano da altri lavori, ecc.) Semplifica la concentrazione sui problemi difficili e a volte risolve i problemi.

In una parola: eleganza. Ogni classe, ogni metodo, ogni condizione, ogni blocco, ogni nome di variabile: ricerca dell'eleganza.

Non incolpare mai l'utente di ciò che potrebbe essere risolto con un'esperienza utente più pulita o una migliore documentazione. Spesso, i programmatori presumono automaticamente che l'utente sia un idiota che non può fare nulla di buono, quando il problema è una scarsa esperienza generale o mancanza di comunicazione. I programmi sono pensati per essere utilizzati e trattare l'utente con disprezzo significa in primo luogo perdere il punto della programmazione.

Ogni programmatore dovrebbe sapere come usare il debugger e saperlo usare bene .

Strutture dati

Come usare Google

Valutazione del corto circuito, sebbene sia una delle prime cose che ti insegnano sugli operatori booleani.

Come stimare con precisione il tempo impiegato da una funzionalità per implementare. Ancora più importante, come comunicare che non stai cagando quando invii quella stima.

Lo stile di programmazione è importante:

• rientri coerenti
• uso coerente delle questioni relative agli spazi bianchi (ad esempio intorno agli operatori),
• collocamento coerente di {} questioni,
• gli identificatori ben scelti contano,
• eccetera.

... e il buon design conta.

Idealmente, il programmatore impara queste cose prima (o durante) la sua prima revisione del codice. Nel peggiore dei casi, il programmatore li impara quando il capo gli dice di apportare in fretta alcune modifiche non banali a un codice orribile.