Sono uno sviluppatore alle prime armi.
Mentre lo sviluppo procede, ci imbattiamo in diversi problemi di errore. Tuttavia, per i principianti della programmazione, è sempre difficile comprenderli direttamente & risolvili.
Credo che gli errori siano in genere correlati all'errore di battitura o all'errore della struttura dei dati O all'errore della memoria di runtime - che è correlato all'hardware O altro.
Come elaborare e risolvere quegli errori molto velocemente?
I miei pensieri:
Non penso che molti errori siano correlati agli errori di battitura. Gli errori di battitura generalmente non producono roba che verrà compilata, quindi raramente produce qualcosa che arriva persino al test unitario, per non parlare di quello. Quei pochi che sono generalmente molto facili da individuare.
In 16 anni di sviluppo gli unici problemi che ho visto che sono stati causati da un guasto hardware sono stati così importanti (cioè sistema / sottosistema inattivo) che sono stati immediatamente evidenti e sono stati rilevati dagli amministratori di sistema. Una volta arrivato al programmatore, ti suggerisco di rimuovere dalla tua mente la possibilità di errori hardware finché non vedi alcune prove molto forti da suggerire che è così che generalmente è così improbabile che non dovresti perdere tempo a pensare a riguardo.
Gli errori si dividono in tre categorie:
1) Malintesi - il sistema funziona correttamente ma qualcuno ha frainteso ciò che è destinato a fare. Il modo migliore per scoprire se questo è il caso è ottenere più informazioni possibili, idealmente parlando con qualcuno che ha effettivamente visto l'errore e chiedendo cosa hanno visto e cosa si aspettavano di vedere.
2) Errori di configurazione - mentre ci sono pochissimi errori causati da errori hardware, ce ne sono molti causati dal fatto che le macchine vengono impostate in modo diverso per quanto riguarda la configurazione del software. Ciò è particolarmente probabile se non riesci a riprodurre l'errore nella configurazione di sviluppo che probabilmente non è standard a causa degli strumenti assortiti che hai installato e delle modifiche apportate per essere produttivi. La cosa migliore da fare qui è avere un ambiente di test di sviluppo che sia un clone di produzione e provare a riprodurre l'errore lì. Una volta che hai puoi iniziare a confrontare quell'ambiente con quelli in cui funziona e vedere quali sono le differenze.
3) Errori di codice: il codice è fuori e fuori sbagliato. Ci sono problemi comuni (non controllare i valori di ritorno o errori mal gestiti, loop e verifiche non corrette - per esempio non controllare il record finale in un array o collezione perché lo sviluppatore si è confuso sul fatto che sia finito a i o i-1) ma esattamente come sono comuni, variano da progetto a progetto e in ogni caso sono abbastanza facili da individuare camminando sul codice. Le cose principali che direi qui sono assicurarti di poter riprodurre l'errore (questo potrebbe comportare il recupero dei dettagli di un record specifico in cui l'errore si verifica dall'utente) e percorrere il codice riga per riga.
In generale, suggerirei i seguenti suggerimenti:
1) Possiedi il problema . È il tuo problema e devi risolverlo indipendentemente da cosa sia o chi lo abbia originariamente causato. Ciò potrebbe comportare l'esame di cose che non sono la tua area di specializzazione, ma è quello che serve, questo è quello che fai.
2) Parla all'utente . La cosa che rallenta maggiormente la risoluzione del problema nella mia esperienza è una cattiva informazione, quindi tagliala direttamente all'utente e scopri cosa sta succedendo. Invitali a guidarti, cosa hanno fatto, cosa hanno visto, cosa si aspettavano di vedere. Chiedi se succede sempre o solo una parte del tempo. Se è solo una parte del tempo, chiedi loro dei modelli, ottieni dettagli di record specifici dove si verifica. Metti in discussione tutto e non assumere nulla. E quando dico di parlare con loro, intendo parlare con loro - scoprirai qualcosa di più che attraverso alcune conversazioni via e-mail e lo farai molto più velocemente.
3) Riproduce il problema . Non indovinare la soluzione, riprodurla, è l'unico modo per sapere che hai davvero trovato ciò che sta accadendo. Cammina il codice passo dopo passo e guarda cosa sta realmente accadendo. Ciò può comportare la riproduzione dell'ambiente o il recupero di una copia del database - se necessario, è quello che fai.
4) Sii realistico . Non è un problema hardware e non hai riscontrato alcun problema con il compilatore. Una volta che hai risolto è un problema reale (cioè che l'utente non si sta sbagliando per quello che è destinato a fare) e lo hai riprodotto, il problema più probabile è che il codice sia sbagliato, quindi non farlo scherzi altrimenti.
5) Risolve il problema root, non il sintomo . Se dicono che tutto è in ordine di 1, non sottrarre solo 1 da tutto, scoprire PERCHÉ è uscito da 1 e risolverlo. Se risolvi il problema, vedrai nuovamente il problema.
Molto, piuttosto la maggior parte di ciò che fai come programmatore è il debug. Stai eseguendo il debug del tuo codice o di quello di qualcun altro. Come novizio, non vuoi concentrarti più velocemente. Devi concentrarti sui dettagli, sull'organizzazione e sulla correttezza:
Inoltre, fai domande ... chiedi, chiedi, chiedi. La velocità con cui esegui il debug non è tanto importante quanto la tua abilità nel risolvere il bug una volta trovato. La velocità arriverà nel tempo; tuttavia, l'accuratezza dovrebbe essere la tua preoccupazione principale.
Avere un IDE intelligente e imparare come usare un debugger, direi. Senza queste cose di base, probabilmente stai eseguendo il codice in modo irrimediabilmente nella tua testa e vedendo se funziona, o inserendo istruzioni di trace ovunque. Questo può rendere necessario il debug degli errori semplici per sempre, quando, in un ambiente migliore, ti verrà indicato in rosso acceso prima ancora di eseguire il progetto (o poco dopo).
Dato che questa è una domanda posta in termini generali, cercherò di rendere la mia risposta il più ampia possibile.
La risoluzione di un errore implica la risposta a due domande presumendo che tu abbia familiarità con il linguaggio / la piattaforma / la tecnologia di sviluppo
La risposta a questo può essere trovata sia dal primo in alto tramite la comprensione del codice (manualmente o usando gli strumenti) che dal basso con un buon vecchio debug. Ciò che è più importante è documentare religiosamente ogni conoscenza incrementale così acquisita in un formato facile da capire e costruire gradualmente un modello nella tua mente.
La risposta a questo può essere trovata dalla documentazione esistente del prodotto, nonché quella di tecnologia, piattaforma e linguaggio, discussione con i colleghi e gli utenti finali, e dalle conoscenze acquisite e dal modello costruito nel primo passaggio.
Risolvere l'errore è questione di allineare 1. con 2.
Non sono d'accordo con la necessità o l'utilità di un debugger. In qualsiasi ambiente multi-thread, un debugger è quasi inutile soprattutto in una piattaforma embedded. printf FTW !! Per un programmatore principiante il mio suggerimento sarebbe iniziare a tenere una lista di errori comuni che fai.
Ad esempio: Stai controllando tutti i tuoi valori di ritorno? Stai verificando le condizioni al contorno? Stai inizializzando tutte le tue variabili? Stai verificando il NULL prima di dereferenziare un puntatore? Stai convalidando tutti i parametri di input? Gli inserimenti e le eliminazioni delle liste collegate sono corretti? Disponi dei corretti meccanismi di protezione attorno a dati / risorse condivisi.
Dopo aver acquisito più esperienza, sapere dove iniziare a cercare i problemi diventa più intuitivo. Penso che la parte più difficile dell'essere un programma per principianti sia la mancanza di conoscenza / esperienza con la piattaforma su cui iniziano a lavorare. Ero stupito quando uno sviluppatore più anziano guardava un bug su cui stavo lavorando e lo risolveva 10 minuti dopo che ci avevo lavorato per 2 giorni. Non erano più intelligenti di me, ma la conoscenza di come funzionava il sistema, compreso il modo in cui i diversi sottosistemi interagivano, permetteva loro di formulare un'ipotesi istruita su cosa stava accadendo in base al comportamento del bug. Non posso sottolineare abbastanza quanto sia utile sapere tanto sulla piattaforma che stai lavorando come puoi. Conosci i tuoi limiti e non aver paura di chiedere aiuto alle persone più anziane. Inoltre, se ti capita di aiutarti a essere sicuro che tu abbia loro spiegare esattamente cosa stava succedendo e assicurarti di capire che cosa stava causando il bug. Ogni bug è un'altra opportunità per saperne di più sulla piattaforma su cui stai lavorando. Più conosci che è facile eseguire il debug.