Diventare un miglior bug-fixer

it's not fun at all when you have to make minor changes and wait 30 seconds to 3 minutes to be able to see if they worked or not

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

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

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

Il bug fixing è un'abilità estremamente importante che dovresti imparare. Ho letto da qualche parte che, normalmente uno spende l'80% del tempo a correggere il 20% dei problemi in un'applicazione.

Credo nell'apprendimento dagli errori e la risoluzione dei bug è un'opportunità per imparare dagli errori degli altri . Puoi imparare e sarà un programmatore migliore in futuro. Questa è la motivazione che ho avuto quando ho iniziato a correggere molti bug e andare avanti per ricodificare il codice .

Personalmente, ho trovato utile smettere di pensare ai bug come a "piccole cose", ma piuttosto come grandi showstop che sono altrettanto importanti delle enormi funzionalità anche se comportano semplicemente la modifica di alcune righe di codice dopo ore di debug. In questo modo, trascorrere un'intera giornata a uccidere 3 voci di tracker bug è decisamente meno deprimente (l'approccio dipende un po 'dalla tua capacità personale di convincerti a farlo: -).

Forse aiuta a renderlo un gioco, per esempio insieme ai tuoi colleghi ( chi corregge il maggior numero di bug al giorno? O, ancora peggio, chi ha fatto 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 test, scrivi una breve descrizione in merito a come testarlo manualmente, ad es. fai clic-qui, digita questo, ecc. e inseriscilo in una sorta di Knowledge Base.

Il debugging può essere molto faticoso, specialmente con un codice complicato che non hai scritto. Vieni con un obiettivo, "Fix Bug 13533 di venerdì". Quindi imposta una ricompensa se raggiungi l'obiettivo: "Prendi una pinta con i miei amici venerdì sera". Ciò contribuirà a renderlo un po 'più gratificante.

Oltre a questo, a volte il lavoro è solo ... lavoro.

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

Ma non tutto è perduto. Lavora per risolvere i tuoi meta-problemi e riversa la tua energia in ciò. Perché ci vogliono da 30 secondi a 3 minuti per ottenere un feedback? In che modo puoi abbreviare quella volta? (Magari puoi scrivere una specie di script o app di utilità che non esegui il check-in per aiutarti 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 i miei più grandi ostacoli a farlo in modo rapido e indolore, e automatizzo ciò che ho bisogno di automatizzare per rimuovere quelle barriere. Ciò si traduce spesso in una maggiore produttività e aggiunte al mio portafoglio personale per l'avvio.

Quindi, in breve, direi che "si sta sempre sviluppando". :)

Il tuo problema è il debug o il bug fixing? Se riesci a eseguire il debug in modo da isolare il componente che causa il problema, esaminalo come una nuova attività di sviluppo.

1. Scrivi alcuni test unitari solo per il pezzo di codice che si sta rompendo. Assicurati di avere test che convalidano tutto ciò che desideri funzionalità, oltre ad alcuni che isolano in particolare il buggy comportamento.
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 che eseguirai i tre minuti di reboot del tuo server, ma dovrebbe essere ridotto al minimo se esegui i passaggi 1-3 bene.
5. Voila!

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

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

Se lo sviluppo del software è noioso, stai sbagliando. In altre parole, non è un problema con te, ma un problema con la tua piattaforma e il tuo processo. Hai considerato la ricerca di 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 schifosi e datori di lavoro schifosi (non sto dicendo che sia il caso qui, solo generalizzando).

puoi scrivere test unitari contro il loro codice. Avvicinati il più possibile. Una volta che hai qualcosa da mostrare ai boss, potresti essere in grado di cambiare la situazione.

Usa gli strumenti di debug per correggere la lentezza, usa i test unitari per testare il nuovo codice e usarli per correggere i problemi del codice esistente e per suddividere il codice esistente in parti più piccole.

Puoi renderlo una sfida e diventare un eroe che migliora i 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 problemi personali di risoluzione dei bug ad un certo punto della loro carriera.

Il giusto senso della distanza tra le persone è essenziale per la tua motivazione. Non esagerare o ignorare il tuo lavoro. Se ti identifichi eccessivamente con il tuo lavoro, problemi come quelli che hai descritto possono emergere: potresti essere molto riluttante a sistemare i bug dato che sei la metà delle volte incolpare te stesso. Ottieni una distanza interiore e scopri come puoi lavorare razionalmente sul problema.

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

In primo luogo, più lungo è il tuo tempo di test, più avversi dovresti essere per il culto del carico. Se apporti una modifica, pensaci finché non sarai sicuro che risolverà il bug . Ovviamente, quanto è sicuro la durata del ciclo di test. Ma se i tuoi cicli di test si allungano e non si riescono a evitare lunghi test, dedica 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, il pregiudizio è maggiore verso i test unitari e meno verso i test di integrazione. Rimuovi tutti i point-of-failure dalla piattaforma hard-to-debug possibile.

Il bug fixing può essere "fantastico" o "noioso". Ho alcuni crediti di gioco che sono interamente dovuti alla correzione di un singolo bug - il bug di crash che nessun altro poteva risolvere. Ma la cura quotidiana di bugzilla è sconvolgente. I bug minori sono noiosi. I principali bug sono degni.

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

Trova quel bug e risolvilo.

Una cosa che ho trovato tra colleghi e acquantenni che sono buoni "debugger / bug fixer / risolutori di problemi" è che in genere preferiscono risolvere i puzzle. Ciò potrebbe significare cruciverba, giochi numerici (come il Sudoku) e puzzle logici, ecc ...

Quindi un modo in cui potresti diventare un bug fixer migliore sarebbe passare del tempo a lavorare sulle tue capacità di problem solving o di risoluzione dei puzzle.

Ecco un link di Wikipedia che potrebbe essere un buon punto di partenza per le cose che ti aiutano a essere un risolutore di problemi migliore .

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 fare errori - se ti costringi a imparare ad essere un risolutore di rompicapi, sarà più facile essere un buon bug fixer in futuro .

Il bug fixing di solito sembra un lavoro ingrato perché può farti sentire come se i bug prendessero tutto il tuo tempo e ti tenessero lontano dalle cose nuove e divertenti. La realtà è che il bug fixing è una parte molto ampia 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, solo che non sembra così perché li hai sistemati come parte del processo di implementazione delle funzionalità. Realisticamente parlando, non importa quanto sei bravo come programmatore, i bug si insinuano nel tuo sistema.

Quindi, come lo rendi divertente? Beh, non posso davvero risponderti per te perché non riesco davvero a immaginare che cosa fa galleggiare la tua barca individuale. Per quanto mi riguarda, sono un po 'un drogato di strumenti, quindi la risposta è stata avere una catena di strumenti molto affidabile e un processo di sviluppo flessibile che contribuisce a rendere la correzione dei bug meno complicata 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 che sprecano parti del software di scrittura. Utilizzo un approccio di test di primo sviluppo supportato da un'eccellente API BDD denominata StoryQ . Io uso Resharper per automatizzare gran parte del mio refactoring e StyleCop per mantenere un coperchio su cose come lo stile di codifica. La mia ultima aggiunta alla catena di strumenti è stata quella di includere NCrunch che esegue i miei test continuamente e contemporaneamente in background mentre codice, ed è davvero stato NCrunch che ha dimostrato di essere il punto di svolta del gioco.

La combinazione di tutti questi strumenti ha visto la mia produttività superare il tetto ultimamente, dato che spreco pochissimo tempo in attesa che le cose vengano compilate o eseguite. Ricevo visivamente feedback visivi all'interno del mio IDE per farmi sapere che ho problemi da risolvere, e dispongo il mio codice di test in modo tale da poter individuare entro poche righe di codice il luogo esatto in cui non solo il si verifica un errore, ma al punto in cui si verifica la causa dell'errore a causa della bella segnalazione dettagliata che ottengo da StoryQ che mi dice esattamente quali parti del mio test pass, che falliscono, e dove nel codice sono presenti i guasti. Con tutti i perditempo rimossi dal mio tempo di sviluppo, spendo pochissimo tempo attivamente nel debugging e più tempo per risolvere problemi e scrivere test e codice. L'elevato turnover delle emissioni mi tiene impegnato e apporta molte variazioni nei miei compiti. Inoltre, mi ha dato molto tempo per dedicarmi ad altre aree di interesse durante la mia giornata di lavoro, in modo da poter inserire idee nuove e innovative nella nostra linea di prodotti e nei nostri processi.