Ho programmato per 6 anni e sono al liceo (preferisco non rivelare la mia età). Mi sono dilettato in molte lingue diverse. Solo per elencarne alcuni: Java, PHP, C ++, Python, Autohotkey, Mathematica e molti altri. Ho un'ottima conoscenza delle basi della programmazione generale. L'unico problema è che io ancora creiamo bug tutto il tempo. Penso troppo spesso. Hai qualche suggerimento oltre a continuare per programmare che mi aiuterà a diventare un programmatore migliore e fare meno errori?
Fai qualche analisi sulla natura dei bug stessi. Sono più logici o sono errori di codifica?
Per i primi, un buon modo è quello di modellare i possibili scenari dei casi d'uso con UML o diagrammi di relazione e poi riprenderli da lì.
Se stai riscontrando più errori di codifica, esegui alcune cause alla radice: qual è la causa dell'errore? Variabili globali? Puntatori? Troppe dichiarazioni if-else? Mancanza di commenti nel codice? Devi prendere ognuno di questi problemi in modo frammentario e poi vedere come vuoi farlo.
Ultimo ma non meno importante, ti preghiamo di leggere il libro sui motivi di design di Gang of Four (google this).
Una delle cose che aiuta di più è l'utilizzo di asserzioni. Quante volte al giorno assumi qualcosa che può essere controllato con un semplice predicato "non può accadere"? Se, ogni volta che vi imbattete in qualcosa di simile, inserite un asserimento per dimostrare al runtime che avete ragione, il codice bacato fallirà velocemente e si chiuderà alla radice del problema. Inoltre, l'atto di affermare esplicitamente le tue ipotesi sullo stato attuale è di per sé un buon esercizio.
Gli asserimenti IMHO sono in realtà più preziosi dei test unitari. Alcune cose sono difficili da testare o perché hanno così tante dipendenze (dati o altro codice), perché l'algoritmo è così complesso che è praticamente impossibile capire quale sia la "risposta giusta" eccetto programmando un'implementazione e eseguendo il codice, o perché non sono deterministici. I test unitari verificano anche solo i casi specifici che si pensava di testare. Assertimenti, d'altra parte, non richiedono di presentare un caso di test specifico, rendendolo molto più facile da scrivere e quindi più probabile che venga effettivamente scritto anche quando è di fretta. Vedono anche input del mondo reale, inclusi casi a cui non hai mai pensato.
Tutti creiamo bug. Penso che l'esperienza tenda a ridurli. Dopo aver fatto un errore particolare, riconoscerai le situazioni in cui si verifica e svilupperai tecniche per evitarlo.
Una cosa che potresti fare fin da subito per limitare il numero di bug che ti manca è iniziare a fare più test - aggiungere test unitari alla tua metodologia, o andare fino in fondo e iniziare a fare lo sviluppo Test Driven.
Come altri hanno già detto, analizza gli errori che stai facendo e scopri cosa sono. Una volta che sai quali sono gli errori in genere risolti, puoi assicurarti di non commettere quegli errori.
Ma una volta che sai quali sono gli errori che stai facendo devi rendere la soluzione un'abitudine. Mentalmente fai colpo sulle nocche ogni volta che fai ciò che ha causato l'errore (o non fai il passo che ti assicura di non commettere l'errore), e mentalmente datti una pacca sulla schiena quando realizzi la soluzione, finché non diventa seconda natura.
Le tue abitudini determineranno cosa farai quando sei sotto pressione. Se non hai buone abitudini, farai errori che dovresti sapere di non.
Infine, ognuno scrive bug. Per citare Edgser Dijkstra ,
If debugging is the process of removing bugs from a program, then programming must be the process of putting them in.
Ci saranno sempre bug, ma il tentativo di evitarli è eccellente.
Hai abbastanza esperienza per cercare di evitarlo, piuttosto che pensare di essere bravo e farlo bene la prima volta ogni volta - solo rendertene conto è eccellente.
Ogni volta che trovi un errore, chiediti "avrei potuto evitarlo? come?"
Cerca le best practice su stackexchange e altrove, capisci perché sono così e seguile (supponendo che tu sia d'accordo).
Leggi il codice ben scritto, lavorando con qualcun altro, esaminando una base di codice esistente di alta qualità (difficile da trovare) o leggendo buoni libri di codice (guarda i programmatori o lo stackoverflow per molti suggerimenti decenti sui libri su come ottenere buoni risultati, non solo come iniziare).
Probabilmente lo sai già, ma attiva gli avvisi del compilatore e, se possibile, usa uno strumento per il controllo del codice statico (e per quello, un debugger decente). Per un programma breve, puoi ignorare gli avvisi. Per un programma di grandi dimensioni, hai bisogno di zero avvisi in modo che se uno si presenta puoi vedere se è importante.
In base alla tua esperienza e alla tua lettura, sviluppa un senso spettrale per gli odori del codice. Cioè, ogni volta che stai per fare qualcosa, riconosci se è rischioso se sei distratto, o se vai via dal codice per sei mesi e dimentica quello che stai facendo. Esempi banali:
Hai hard-coded la lunghezza di un array in più di un posto, anche implicitamente dandogli un elenco di inizializzazione? Non lasciarlo così neanche per un minuto, c'è una grande probabilità che un giorno cambierai uno ma non l'altro. Utilizzare una variabile const o utilizzare sizeof per calcolare la lunghezza. Se cambi qualcosa, dovresti poterlo fare cambiando una cosa e farlo funzionare ancora.
Hai fatto un'ipotesi temporanea? Hai pensato "Oh, per i test, sarà sempre meno di 1k?" Va bene, ma inserisci un asserzione, quindi se superi il limite, vedrai immediatamente che devi tornare indietro e renderlo opportunamente di dimensioni variabili, invece di ottenere errori strani devi eseguire il debug.
Stai scrivendo un codice che ti ha portato via più di un minuto per avere ragione? O preso in prestito una tecnica dal web? Metti un commento dicendo perché è così. Se non sei sicuro che il commento rimarrà aggiornato, inserisci una data. Puoi sempre cancellarlo in un secondo momento se decidi che l'uso è sufficientemente ovvio ed è ora una seconda natura per te, ma la possibilità è quasi certa che se dovessi fermarti a pensare ora, dovrai fermarti a pensare quando rileggi la codice.
Stai scrivendo un'istruzione if () basata su una variabile o una funzione bool? Cambia il suo nome - ora - per riflettere il senso del valore. Non scrivere "if (retval)", scrivere "if (success)" o "if (failure)". All'apparenza sembrerà ovvio, ma in seguito eviterai enormemente il rischio di sbagliare il percorso senza accorgertene.
Probabilmente lo fai già, ma usa SEMPRE il controllo del codice sorgente prima di modificare QUALSIASI COSA. Le possibilità sono infinite che cambierai qualcosa e pensi "aspetta, l'hai rotto?" Se puoi confrontare prima e dopo, sarà completamente trasparente dove si trova il problema.
E altro ancora in questa vena (inclusi esempi più sofisticati come antipattern in archetecture, non solo sintassi).
Lavori a progetti da solo? Potresti provare a essere coinvolto in un progetto su larga scala. Correggere i bug degli altri è un ottimo modo per essere esposti a tutti i tipi di errori che potreste non pensare fossero possibili.
Ognuno crea bug ogni giorno - l'obiettivo è solo trovarli e risolverli prima che diventino un grosso problema.
Ciò che mi aiuta è di elencare sempre i modi in cui ogni sezione, funzione può fallire nella mia testa.
Quindi lavoro più duramente su scope variabili, convalida dei form, injection anti-sql, scrittura sql migliore e corretta ecc.
Credo che nel tempo creeremo le nostre checklist mentali su cosa NON fare.
E nel tempo il nostro codice è migliore ...
Un modo pratico per migliorare la qualità del codice è imparare un linguaggio funzionale altamente astratto come Haskell / Caml / Lisp. Haskell sarebbe la mia raccomandazione, anche se altri suggeriscono che non è un buon primo linguaggio funzionale.
Non devi rendere quelle tue lingue primarie (a meno che tu lo voglia, ovviamente). Solo conoscerli è estremamente utile, anche se li trovi estremamente difficili.
Una volta che hai imparato a pensare a concetti come l'apolidia e le funzioni di ordine superiore, saprai quali tipi di errori tenere in considerazione quando scrivi il codice nelle tue solite lingue imperative.
Ovviamente i difetti di progettazione e gli errori di integrazione sono più difficili da evitare, ma da quando ho appreso F # e Haskell, ho quasi completamente smesso di fare bug su piccola scala.
Leggi altre domande sui tag bug programming-practices