Diventare un bug-fixer migliore

Adoro fare il programmatore. Ecco, l'ho detto. Tuttavia, detto ciò, ultimamente mi sono reso conto che davvero non sopporto la correzione di bug. Affatto.

In effetti, mentre sto sviluppando qualcosa, la mia produttività è estremamente elevata. Anche quando scrivo unit-test e faccio autotest del mio sviluppo, sono generalmente molto produttivo. Sono in grado di concentrarmi bene e posso svolgere i compiti.

Tuttavia, quando arriva il momento del controllo qualità e sto lavorando per correggere i bug, la mia ispirazione prende un enorme successo. Devo forzarmi con misure piuttosto estreme (sai, musica ad alto BPM, quantità eccessive di caffeina, ecc.) Per fare qualsiasi cosa . Il mio lavoro di solito è coinvolto nell'entrare in un enorme progetto esistente e nell'aggiungere nuove funzionalità o correggere bug, quindi non posso dire esattamente al mio datore di lavoro che ho bisogno di un paio di settimane per scrivere test unitari per tutto il loro codice :) Inoltre, il la tecnologia server che usiamo spesso è molto proibitiva sia per i test unitari che per quelli di integrazione, poiché presenta alcuni problemi con il classloader Java. Non sono completamente contrario alla correzione dei bug, a volte può essere divertente, ma non è affatto divertente quando è necessario apportare modifiche minori e attendere da 30 secondi a 3 minuti per vedere se hanno funzionato o meno (a causa del modo in cui funziona il sistema).

Come posso migliorare la mia produttività e motivazione durante la correzione di bug? È qualcosa con cui la maggior parte dei programmatori si occupa?

non è affatto divertente quando devi apportare piccole modifiche e aspettare da 30 secondi a 3 minuti per vedere se hanno funzionato o meno

Questo è il vero problema qui. Ti senti improduttivo quando devi aspettare così tanto il feedback, conosco la sensazione. Forse è possibile falsificare più servizi e creare strumenti di test migliori in modo da ottenere un feedback immediato.

Il codice legacy di unit test è costoso o può comportare refactoring pericolosi. Tuttavia, la creazione di dispositivi di prova migliori può consentire di eseguire i test manuali in pochi secondi rispetto ai minuti e ottenere quasi la stessa produttività di lavorare con il nuovo codice testabile dell'unità.

Attendere così tanto il feedback è noioso e demotivante, non l'atto di correggere gli stessi bug.

La correzione dei bug è un'abilità estremamente importante che dovresti imparare. Ho letto da qualche parte che normalmente si spende l'80% del tempo a risolvere il 20% dei problemi in un'applicazione.

Credo nell'apprendere dagli errori e la correzione dei bug è un'opportunità per imparare dagli errori degli altri . Puoi prenderlo come un apprendimento e in futuro contribuirai a essere un programmatore migliore. Questa è la motivazione che ho avuto quando ho iniziato a correggere molti bug e ad andare avanti nel re-factoring del codice .

Personalmente, ho trovato utile smettere di pensare ai bug come a "piccole cose" ma piuttosto a grandi showtopper che sono importanti tanto quanto le enormi funzionalità anche se comportano solo la modifica di alcune righe di codice dopo ore di debug. In questo modo, avere trascorso un'intera giornata a uccidere 3 voci di bug tracker è molto meno deprimente (l'approccio dipende un po 'dalla tua capacità personale di convincerti a crederci :-).

Forse aiuta a renderlo un gioco, ad esempio insieme ai tuoi colleghi ( chi corregge il maggior numero di bug al giorno? O, peggio ancora, chi ha eseguito il minor numero di ricostruzioni al giorno? )

Sono stato nei tuoi panni. Costruisci test automatici quando e dove puoi. Non deve essere tutto in una volta. Quando trovi un bug, prenditi un minuto per provare a programmare un caso di test. Se non riesci a programmare un caso di prova, scrivi da qualche parte una rapida descrizione di come testarlo manualmente, ad esempio fai clic qui, digita questo, ecc. E inseriscilo in una sorta di Knowledge Base.

Il debug può essere molto noioso, specialmente con un codice complicato che non hai scritto. Vieni con un obiettivo, "Correggi bug 13533 entro venerdì". Quindi imposta una ricompensa se raggiungi l'obiettivo, "Prendi una pinta con i miei compagni venerdì sera". Ciò contribuirà a renderlo un po 'più gratificante.

A parte questo, a volte il lavoro è proprio quel ... lavoro.

In questo tipo di situazione, hai bisogno di una sorta di sfida creativa. Normalmente, sta scrivendo codice, ma qui non lo è.

Ma non tutto è perduto. Lavora per risolvere i tuoi meta-problemi e riversare la tua energia in quello. Perché ci vogliono dai 30 secondi ai 3 minuti per ottenere un feedback? Come puoi abbreviare quel tempo? (Forse puoi scrivere qualche tipo di script o app di utilità che non fai il check-in che ti aiuta a farlo). Questo è il tuo nuovo dominio problematico, la tua nuova sfida creativa.

Personalmente, ogni volta che mi trovo in una fase di correzione dei difetti, identifico le mie più grandi barriere per farlo in modo rapido e indolore e automatizzo ciò che devo automatizzare per rimuovere quelle barriere. Ciò comporta spesso una maggiore produttività e aggiunte al mio portafoglio personale per l'avvio.

Quindi, in breve, direi "essere sempre in sviluppo". :)

Il tuo problema è il debug o la correzione dei bug? Se riesci a eseguire il debug abbastanza per isolare il componente che sta causando il problema, allora guardalo come una nuova attività di sviluppo.

1. Scrivi alcuni test unitari solo per il pezzo di codice che si sta rompendo. Assicurati di avere dei test per convalidare tutte le funzionalità desiderate, oltre ad alcuni che isolano particolarmente il comportamento buggy.
2. Scrivi un nuovo codice che superi tutti i test che hai appena scritto.
3. Sostituisci il vecchio codice con il nuovo.
4. Esegui alcuni test di integrazione. Qui è dove ti imbatterai nei tuoi riavvii del server di tre minuti, ma dovrebbe essere ridotto al minimo se hai eseguito bene i passaggi 1-3.
5. Ecco!

Forse dovresti guardare Debugging Myself di Brian Hayes , un articolo apparso su American Scientist nel 1995. Potresti fare dei passi (come l'uso abituale delle condizioni di Yoda ) per ridurre o eliminare i tipi più odiati di bug che produci.

Sono dell'opinione che il debug sia un'abilità diversa dalla programmazione, sebbene correlata. In particolare, il debug di programmi multi-thread è quasi completamente diverso rispetto alla loro scrittura.

Se lo sviluppo del software è noioso, lo stai facendo male. In altre parole, non è un problema con te, ma un problema con la tua piattaforma e processo. Hai considerato di cercare una posizione utilizzando un linguaggio dinamico (ad esempio Python, Ruby, JavaScript), in cui non devi attendere il riavvio del server?

Fa parte del lavoro, sfortunatamente. Avrai progetti scadenti e datori di lavoro scadenti (non sto dicendo che sia il caso qui, solo generalizzando).

È possibile scrivere unit test contro il loro codice. Entra di soppiatto come puoi. Una volta che hai qualcosa che puoi mostrare ai capi, potresti essere in grado di invertire la tendenza.

Utilizzare gli strumenti di debug per correggere la lentezza, utilizzare i test unitari per testare il nuovo codice e utilizzarli per risolvere i problemi del codice esistente, nonché suddividere il codice esistente in parti più piccole.

Puoi renderlo una sfida e diventare un eroe per il miglioramento dei processi. E, se non funziona, avrai una buona esperienza da portare al prossimo datore di lavoro.

La maggior parte dei programmatori ha a che fare con la risoluzione di problemi personali a un certo punto della loro carriera.

Il giusto senso della distanza persona-lavoro è essenziale per la tua motivazione. Non identificarti in modo eccessivo o insufficiente con il tuo lavoro. Se ti identifichi eccessivamente con il tuo lavoro, possono emergere problemi come quelli che hai descritto: potresti essere molto riluttante a correggere i bug poiché sei metà del tempo incolpare te stesso. Prendi una certa distanza interiore e scopri come puoi razionalizzare il tuo problema.

Per quanto riguarda i problemi particolari sulla tua piattaforma, ci sono alcuni modi per mitigare i tempi lunghi di implementazione e test (e, a parte, i tuoi non sono particolarmente lunghi).

In primo luogo, più è lungo il tempo di prova, più si dovrebbe essere avversi al culto delle merci. Se apporti una modifica, pensaci finché non sei sicuro che risolverà il bug . Naturalmente, quanto la fiducia è soggetta alla durata del ciclo di prova. Ma se i tuoi cicli di test si allungano e i test lunghi non possono essere evitati, trascorri più tempo a pensare e sarai ricompensato e più felice nel debug perché è più veloce e ha l'effetto gratificante di un buon momento di "fiat lux ".

In secondo luogo, orientarsi maggiormente verso i test unitari e meno verso i test di integrazione. Rimuovi ogni punto di errore dalla piattaforma di cui è possibile eseguire il debug.

La correzione dei bug può essere "fantastica" o "noiosa". Ho alcuni crediti di gioco che sono interamente dovuti alla correzione di un singolo bug - il bug di crash che nessun altro potrebbe risolvere. Ma la cura quotidiana di bugzilla è paralizzante. I bug minori sono noiosi. I principali bug sono degni.

Ecco la realizzazione: il fatto che tu abbia una lista gigantesca di bug minori è di per sé un bug importante. Non è solo un bug di codice. È un bug di processo o di gestione.

Trova quel bug e correggilo.

Una cosa che ho trovato tra colleghi e acquisitori che sono buoni "debugger / correttori di bug / risolutori di problemi" è che generalmente amano risolvere enigmi. Ciò potrebbe significare cruciverba, giochi numerici (come il Sudoku) e puzzle logici, ecc ...

Quindi un modo in cui potresti diventare un migliore correttore di bug sarebbe quello di dedicare un po 'di tempo a lavorare sulle tue capacità di problem solving o puzzle solving.

Ecco un link Wikipedia che potrebbe essere un buon punto di partenza per le cose che ti aiuteranno a risolvere meglio i problemi.

Intendiamoci, alcune persone sono semplicemente più brave a risolvere i problemi, o semplicemente si divertono di più. Ad alcune persone non piace affatto, il che rende difficile forzare te stesso a fare - ma non commettere errori - se ti costringi ad imparare a essere un risolutore di puzzle, sarà più facile essere un buon riparatore di bug in futuro .

La correzione dei bug di solito sembra un lavoro ingrato perché può farti sentire come se i bug stessero occupando tutto il tuo tempo e ti tenessero lontano dalle nuove cose divertenti. La realtà è tuttavia che la correzione dei bug è una parte molto grande di ciò che facciamo, e inizia già scrivendo la prima riga di codice ed eseguendo il compilatore. Quando rilasci il codice per la prima volta, probabilmente hai già passato ore a correggere i bug, ma non sembra così perché li hai riparati come parte del processo di implementazione delle funzionalità. Realisticamente parlando, non importa quanto tu sia un programmatore, i bug si insinueranno nel tuo sistema.

Quindi, come lo fai divertente? Beh, non posso davvero rispondere a questa domanda, dato che non riesco davvero a immaginare cosa fa galleggiare la tua barca individuale. Per me, sono un po 'un drogato di strumenti, quindi la risposta è stata quella di avere una catena di strumenti molto affidabile e un processo di sviluppo flessibile che contribuiscono tutti a rendere meno problematica la correzione di errori e più semplicemente un problema da risolvere velocemente. Attualmente sto sviluppando principalmente in C #, e sono sempre alla ricerca di strumenti che rimuoveranno il noioso tempo sprecato parti del software di scrittura. Uso un primo approccio di sviluppo di test supportato da un'ottima API BDD chiamata StoryQ . Uso Resharper per automatizzare gran parte del mio refactoring e StyleCop per tenere sotto controllo cose come lo stile di programmazione. La mia ultima aggiunta alla catena degli strumenti è stata quella di includereNCrunch che esegue i miei test continuamente e contemporaneamente in background mentre scrivo codice, ed è stato davvero NCrunch che ha dimostrato di essere il punto di svolta .

La combinazione di tutti questi strumenti ha visto la mia produttività passare attraverso il tetto ultimamente, poiché spreco molto poco tempo in attesa che le cose vengano compilate o eseguite. Ricevo un feedback immediato visivamente all'interno del mio IDE per farmi sapere che ho dei problemi da risolvere e dispongo il mio codice di test in modo tale da poter individuare in poche righe di codice il luogo esatto in cui non solo il si verifica un errore, ma a dove si verifica la causa dell'errore a causa dell'adorabile reportage dettagliato che ottengo da StoryQche mi dice esattamente quali parti del mio test passano, quali falliscono e dove sono nel codice gli errori. Con tutte le perdite di tempo rimosse dal mio tempo di sviluppo, dedico pochissimo tempo al debug attivo e più tempo a risolvere problemi e scrivere test e codice. L'alto turnover delle questioni mi tiene occupato e comporta molte variazioni nei miei compiti. Mi ha anche dato molto tempo per perseguire altre aree di interesse durante la mia giornata di lavoro in modo da poter iniettare idee nuove e innovative nella nostra linea di prodotti e nei nostri processi.