Sono incompetente; come posso ripararlo? [duplicare]

Il diavolo è nei dettagli

Non sei incompetente. Ti manca solo un po 'di attenzione ai dettagli e non sei abbastanza esigente.

Consenti al compilatore di essere la tua guida

Dici di essere un programmatore C. Lascia che il compilatore ti chieda e compili (per gcc) almeno con: -Wall -Werror -ansi -pendantic -Wstrict-prototypes .

... e invita i suoi aiutanti alla festa!

Assicurati di eseguire alcuni strumenti di qualità del codice sul tuo codice. Usa la pletora di linters , analizzatori di codici statici e altri che hai a portata di mano per cercare di rilevare possibili errori. Utilizza Valgrind .

Aggiungi vincoli al mix

Impegnati a scrivere codice che si rivolge a diversi sistemi operativi e architetture. Alcuni sono meno indulgenti di altri quando si tratta di rovinare le allocazioni di memoria, e vedrai vari risultati nel modo in cui gestiscono i loro modelli di threading. Mentre lavorerai attraverso queste differenze, imparerai a appianare i punti problematici.

Sviluppa un occhio attento per i test

Tuttavia non è tutto, e non possono indovinare cosa stai cercando di fare. Quindi prendi l'abitudine di pensare a casi limite e buoni test per il tuo codice. Alla fine, queste cose verranno per te in modo naturale e scrivere un codice più robusto diventa un'abitudine. Non hai ancora l'abitudine.

Fail Early e Fail Hard

Scrivi un codice che fallisce davvero. Significa che quando qualcuno sbagliato , dovrebbe davvero fallire difficile e andare in crash, quindi il problema è notevole e deve essere affrontato, invece di cercare la via d'uscita cercando di gestire gli errori e rimanere in vita il più a lungo possibile.

Ci sono diverse scuole di pensiero, ed entrambi hanno vantaggi. Programmazione difensiva è ottimo per scrivere software che è alquanto tollerante agli errori e non si arresta in modo anomalo compromettendo la sicurezza della piattaforma. Tuttavia a volte si desidera utilizzare un approccio design-by-contract e applicare questi contratti (e gli sviluppatori sanno quando andranno le cose sbagliato all'inizio del ciclo di sviluppo).

Pratica, pratica, pratica

Naturalmente, tutto quanto sopra è già in merito. Ma forse quello che ti manca è un incentivo per farlo e fare qualcosa di grande. Parli di avere problemi non appena le cose si complicano. Quindi esci dalla tua zona di comfort e costruisci qualcosa di complesso. Cosa ti manca nella tua vita virtuale, su base regolare? Se riesci a pensare a qualcosa, puoi costruirlo? Inizia semplice e crea qualcosa di più grande e più grande man mano che vai. Guardalo e migliora il suo design generale mentre vai. Poi magari buttalo fuori e fai una riscrittura completa: ora che hai una visione migliore, dovresti essere in grado di ricostruire questo sistema complesso più velocemente e con un design migliore che non soffre dei suoi difetti iniziali.

Allenati.

Sono stato un dev e ho fatto un sacco di supporto agli sviluppatori per anni e mi piacerebbe condividere tre buoni consigli che mi hanno aiutato nel mio tempo.

1. Scrivi il codice per fallire prima

Smetti di scrivere il codice con l'intenzione di farlo funzionare, facendo questo è per amatori e studenti. Il codice che funziona è sotto molti aspetti un caso monouso con errore sempre un'opzione. Invece scrivere codice con l'aspettativa che tutte le azioni che possono fallire saranno a un certo punto. Solo quando tutte le possibili condizioni di errore sono state esaurite puoi essere ragionevolmente sicuro che il tuo codice funzionerà. Cosa succede se la memoria non viene allocata, il file non è disponibile, i dati sono danneggiati o lo stack si sovrappone / esce?

2. Accetta che come programmatore non sei bravo come pensi di essere

... e non lo sarai mai. Quando i programmatori accettano che faremo tutti degli errori, allora applicheremo noi stessi per essere accurati. Ogni errore è un'opportunità di apprendimento e ogni bug non è un bug, è una classe di bug - se non convalidi l'input in un posto e il codice barfs, correggilo e poi considera in quale altro caso potrebbe essere il tuo codice.

3. Utilizza le risorse disponibili per te

Ora ci sono molte risorse aperte agli sviluppatori, correggi gli avvisi del compilatore se puoi. Strumenti di qualità del codice disponibili, alcuni gratuitamente - in C # Mi piace prendere il codice e lanciare Pex e vedere quali punti di errore ha rilevato che mi ero perso ... un esercizio del genere è un vero occhio opener! Rifatta il vecchio codice come esercizio mentale, stabilisci un limite di tempo per non passare tutto il giorno. Ci sono persone intorno a te che possono fare valutazioni peer usarle. Impara una lingua diversa - non perché lo desideri in particolare, ma perché eserciterà i tuoi percorsi mentali e i tuoi modi di pensare alle cose nella lingua scelta.

Usa un linguaggio strongmente tipizzato con alcune cerimonie, come C #. C # ti costringerà a scrivere il tuo codice in un modo più strutturato e orientato agli oggetti, ma assomiglia ancora a C. La tipizzazione strong eliminerà alcuni degli errori che hai descritto, in fase di compilazione.

In alternativa, puoi imparare C nel modo più duro .

Autodisciplina.

L'unico modo per raggiungerlo è imparare dai tuoi errori e prendere provvedimenti per non farli. È un peccato che tu non l'abbia imparato dopo alcuni anni. Attiva tutti gli avvisi del compilatore, tratta gli avvisi come errori del compilatore e guarda cosa succede.

L'analisi statica può anche essere di aiuto qui per mostrarti percorsi di codice imperfetti.