Quando arrivi la mattina, scopri che il tuo software non funziona più, anche se è successo quando sei partito ieri sera.

cosa fai? Cosa controlli prima? Cosa fai per smettere di arrabbiarti e iniziare a lavorare sul tuo problema? Dai la colpa ai tuoi colleghi e vai direttamente da loro? Cosa si può fare per evitare di trovarsi in una situazione del genere?

I soliti sospetti sono:

• Pensavi che funzionasse ieri, ma dopo un'intera giornata di lavoro eri troppo cieco per capire che non funzionava.

• Questa mattina non è più possibile fare riferimento a ciò che era nella memoria cache IDE ieri.

• La workstation è stata riavviata ieri sera o un'operazione di manutenzione notturna ha cancellato le directory / tmp.

• Qualcosa è cambiato nella base di codice: controlla se qualcuno (possibilmente te stesso) ha commesso delle modifiche tra l'ultima compilazione di ieri e l'ultima compilata di oggi.

• Qualcosa è cambiato nelle librerie di supporto: controlla se tali librerie sono state ricompilate o aggiornate. La causa potrebbe essere all'interno del progetto per librerie specifiche o all'esterno se è stata distribuita una nuova versione di un pacchetto apparentemente indipendente.

• Qualcosa è cambiato nell'ambiente di test: nuova versione di una macchina virtuale, uno stub che è stato modificato, modifiche in un server di database remoto ...

• Qualcosa è cambiato nella catena di compilazione: cambiamenti in Makefile, nuova versione di IDE, di compilatore, di librerie standard ...

1) Se oggi non funziona, non funzionava neanche ieri.

Si pensava che stava lavorando, ma non lo era.

2) C'è un problema e deve essere risolto .

Non pensare a chi è responsabile di questo o alla colpa degli altri.

Se non è cambiato nulla tra ieri e oggi (come presumo leggendo la tua domanda), significa che dovresti fare un lavoro migliore nel testare il tuo codice prima di dichiarare che funziona davvero.

Per evitare questa situazione, è necessario eseguire correttamente test e debug .

Definisci "funzionante" e testa i limiti delle tue routine di codice.

• Prova a diventare uno degli utenti che utilizzerà le funzionalità del tuo programma o codice.
• Spingi il codice ai limiti consentiti e oltre, e controlla effettivamente se si rompe.

Un modo per farlo è avere una serie automatizzata di test approfonditi eseguiti durante la notte, in modo che il giorno dopo sia possibile verificare se qualcosa è andato storto e risolvere i problemi.

Cercare di trovare qualcuno a cui dare la colpa non è costruttivo e non risolve i problemi. Non farlo

Se qualcosa ha funzionato ieri e non funziona ora, allora hai un comportamento non deterministico (come una condizione di gara) e farlo funzionare ieri è stata solo fortuna, o qualcosa è cambiato tra allora e adesso, e devi scoprire di cosa si tratta è.

Come esattamente scopri qual è il caso e come può essere risolto dipende dalle specifiche della situazione, ma aiuta sempre ad essere metodico nell'eliminare le cause, cioè non cambiare 5 cose alla volta e smettere di cercare se questo aiuta - scopri quale cosa specifica ha causato il problema e forse annota come risolverlo in modo da poterlo cercare quando si ripete tra 3 settimane da adesso.

L'uso degli strumenti diagnostici appropriati (debugger, profiler, strumenti di analisi della rete) può anche fare una grande differenza.

Ho lavorato con un codice che sembrava cambiare da un giorno all'altro e dopo un po 'sono giunto alla conclusione che ciò era dovuto ai folletti malevoli che strisciavano nella mia base di codice di notte e cambiavano le cose in modo tale che, nonostante il fatto che abbia funzionato ieri, ora non funziona affatto. In effetti nel classico stile Schroedinbug , non solo non funziona ora, è chiaramente chiaro che non c'è modo che possa mai avere.

Nel corso del tempo mi sono reso conto che è possibile che in effetti i folletti non abbiano nulla a che fare con esso e che forse il mio "tempo di tornare a casa, sarà abbastanza buono" l'ultima build non ottenga i test dettagliati e l'attenzione che forse merita .

La mia prima ipotesi quando lo incontro la mattina è che probabilmente è colpa mia, dato che di solito sono il responsabile delle mie caratteristiche o angoli del software su cui sto lavorando. La mia seconda ipotesi è che ora potrei anche prendere quel caffè. Se non è qualcosa di palesemente ovvio che una scimmia potrebbe capire (cosa che a volte lo è), allora è probabile che io sia riuscito a trascinare in una vecchia versione di una libreria, erroneamente eseguito il rollback di un file che non aveva bisogno di essere lanciato indietro o avere qualcosa nella cache da qualche parte che lo ha portato nella build senza controllarlo. Passando attraverso la mia recente attività di controllo del codice sorgente tende a rivelare cose che ho fatto, la pulizia della build spesso rimuove le versioni errate memorizzate nella cache.

A volte non ha nulla a che fare con me: qualcuno ha aggiornato una dipendenza senza menzionarla, WindowsUpdate ha installato qualcosa che ha cambiato l'ambiente in modo che il mio codice non funzionasse; ci sono molte possibilità di fondo, ma di solito è un caso di inventare e accettare che, come la maggior parte delle persone, sono fondamentalmente un idiota.

Usa il controllo versione. Fai un diff o usa la funzionalità di colpa del tuo VCS .:

• diff: Ogni VCS. Ti mostra le differenze tra diverse versioni
• blame: ad esempio git. Ti mostra, riga per riga, chi ha cambiato cosa

Se non c'è controllo della versione, a parte il fatto che è colpa tua o del tuo capo, puoi guardare le date di modifica dei file e possibilmente esaminare le funzionalità di registrazione del tuo sistema operativo.

A parte questo: ricompila tutto, assicurati di ricompilare anche le librerie ausiliarie.

Naturalmente: se hai trovato la fonte dell'errore, mantieni la calma, chiedi perché è stata apportata una modifica, spiega il tuo problema e proponi una soluzione che renda entrambi felici. Non urlare contro di lui, sarebbe un veleno per la tua produttività.

Se non ci sono cambiamenti, è tempo di vedere cosa è cambiato nel sistema. Ad esempio, recentemente i computer Mac OS hanno aggiornato una nuova versione di Apache che ha reso non valide alcune configurazioni.

Bene, ecco un vero esempio di codice che "ha funzionato ieri" e non oggi ... È di inizio mese.

L'applicazione in questione estrae le informazioni da un database per data e il comportamento predefinito è quello di ottenere dati per il giorno corrente. Questo ha funzionato benissimo l'8 agosto, ma non è riuscito il 9. Non è stato testato prima di questo. Avrebbe funzionato anche il 9 settembre e il 10 ottobre ...

Un altro indizio è che siamo nel Regno Unito, il database in questione era negli Stati Uniti ...

Quindi, la mia risposta alla tua domanda su cosa controllare prima è ricontrollare come formattare le date, perché se mescoli i campi del giorno e del mese funzionerà perfettamente, ma solo in 1 giorno al mese :-)

Correggi il bug (comunque normalmente). Quindi, se trovi chi l'ha causato, invia loro un'e-mail educata per far loro sapere cosa è andato storto.

Ogni programmatore commette errori e se inizi a incolpare, la prossima volta che fai la stessa cosa si ritorcerà contro. (forse anche questo bug era tuo)

È solo se sospetti che siano regolarmente disattenti se dovessi fare un grosso problema con un paio di bug.

... esegui test di regressione e ti concentri su quelli che falliscono.

In realtà è quello che ti sei dimenticato di fare ieri prima di partire, succede.

Non ne hai? Ok .. cosa stai dicendo? Incolpare ? Beh ... allora potrebbe funzionare

La prima cosa da fare quando qualcosa smette di funzionare è chiedersi: cosa c'è di diverso? Cosa è cambiato?

Quando qualcosa ha funzionato ieri sera ma questa mattina non ha funzionato, l'unica cosa che ovviamente è cambiata è la data e l'ora :)

Proverei a pensare se c'è qualche parte della logica su cui sto lavorando che dipende dalle date e potrebbe essere influenzata dal passare del tempo. È sorprendente quante volte sia la causa di tali problemi.

Se fallisce, dovresti assolutamente dare seguito agli altri ottimi consigli forniti qui.

Una risposta un po 'breve (da scrivere) ma un po' lunga per capire il perché: perché i programmi falliscono: una guida al debugging sistematico di Andreas Zeller (che potrebbe sembrare un po 'troppo accademico ma non lo è)

Cerca nella tua casella di posta dopo la posta inviata dal motore di integrazione continua quando i test unitari (o la pagina di registro se non hai visto quel problema specifico) e vedi chi ha effettuato il check-in appena prima di quella build .

Quindi vai a parlare con lui o lei.

Ci sono solo due possibili ragioni per cui il tuo codice fallisce oggi, ma ha funzionato ieri.

Guarda i dati

C'è qualcosa nei dati che non hai testato o per cui non hai tenuto conto. O i dati non sono stati validati correttamente o non è stato rivelato un errore nella logica fino a quando non si verifica una condizione logica che non avevi previsto. Ciò significa che il bug era lì ieri, ma si nascondeva sotto dati validi.

Una volta ho avuto un po 'di codice di inserimento dell'ordine funzionante per settimane. Sono tornato a casa un giorno ed è morto. L'indagine del giorno successivo rivelò che avevo nascosto un bug in una catena di chiamate di funzione. In un linguaggio debolmente tipizzato, ho dichiarato un numero intero quando avrei dovuto usare un int lungo. La lingua ha fatto automaticamente la conversione tra i due fino a quando non è stato possibile perché il numero ha superato ciò che si sarebbe inserito in un numero intero. Il sistema non è riuscito sul numero d'ordine 32768.

Guarda cosa è cambiato

Guarda cosa è cambiato da quando ha funzionato. La sezione IT ha inviato un aggiornamento del sistema operativo? Un altro programmatore ha modificato il codice utilizzato dal programma? L'autorizzazione dell'utente è cambiata? Spesso, se trovi cosa è cambiato, troverai il bug.

Taglio binario

funziona particolarmente bene per errori JavaScript difficili. Fondamentalmente commenta metà del codice, vedi se ricevi l'errore, se lo fai è in quella metà del codice. Metà di nuovo e vai avanti.

Se il tuo codice è ben incapsulato, questo è un fantastico strumento per ridurre lo stress e risparmiare tempo.

Una volta trovato il codice colpevole, spesso vale la pena isolare l'errore sulla sua pagina di test.

E, naturalmente, cosa si può fare per evitare di trovarsi in una situazione del genere?

Rispondendo a questa domanda, potresti voler esaminare l' integrazione continua (CI) . In poche parole: CI è un processo in cui gli sviluppatori (spesso più volte al giorno) si integrano e testano tutto il codice. L'idea è che le modifiche a un modulo che interrompono un altro modulo si trovano rapidamente.

In pratica, la maggior parte dei team che impiegano CI utilizzano un server CI (vedi: elenco di Wikipedia ). Il server CI è di solito configurato per monitorare il repository SCM e avviare una build quando vede le modifiche. Al termine della compilazione, eseguirà una serie di test automatici e pubblicherà i risultati via e-mail e / o pagina Web della build e dei test, insieme alle modifiche che hanno causato la build. Spero che, quando qualcosa rompe la build o i test, hai solo un piccolo cambiamento da guardare, quindi viene risolto più rapidamente.

Ci sono altre domande qui su quale server CI usare, quindi ti farò trovare interessanti. Personalmente, sono un grande fan di Jenkins.

[Cosa devo fare per le cose rotte.]

Come altri hanno già detto, scopri cosa si è rotto e prova a risolverlo. Trascorrere del tempo cercando di dare la colpa è il tempo speso per non risolvere il problema.

La mia reazione naturale è sempre quella di incolpare gli altri, ma col tempo ho capito che di solito sono io a essere colpevole. Oltre a tutti gli eccellenti commenti di cui sopra, è importante registrare da soli quale sia stata la ragione finale. Non importa se usi un Wiki condiviso con altri membri del team, un Twiki, un Evernote privato, un diario di bordo o un buon ricordo. L'importante, al momento, trovi la risposta (e vuoi tornare al lavoro!) È registrare il motivo.

Presumibilmente se non funziona più, hai identificato i sintomi del suo mancato funzionamento, ovvero si blocca o restituisce all'utente una particolare finestra di dialogo di errore.

Se la sola descrizione del problema è "non funziona", la prima cosa che devi fare è raccogliere maggiori informazioni sui sintomi del problema.

Quindi inizi a cercare possibili cause, tramite i registri o il tentativo di ricreare il problema o una combinazione di entrambi - dipende da come è configurato il tuo sistema.

Quindi inizi a escluderli.

Questo è ciò che accade di solito quando vado in vacanza :-)

Più seriamente, prima direi loro:

• Lo esaminerò per vedere cosa c'è che non va e quale potrebbe essere la radice

• Toccerò la base tra 30-60 minuti quando avrò la possibilità di vedere cosa sta succedendo

Dopo quel tempo, posso mettere in pericolo una stima di cosa potrebbe essere successo e quanto tempo ci vorrà per risolverlo se non è già stato riparato e, se applicabile, quali dati potremmo aver perso (ma ho buoni backup, in modo che non avvenga mai fiduciosamente).

Per quanto riguarda la parte responsabile:

• se è solo un errore di battitura di un collega, non è necessario menzionarlo: la merda accade e molto probabilmente la paura del bug gli ha insegnato una lezione e, si spera, non lo farà più.

• se ha intenzionalmente fatto qualcosa che gli ho detto di non fare (ad esempio dare la password di root del server di produzione al nuovo ragazzo e dirgli di modificarlo direttamente senza supervisione) (sì, che è già successo ...), allora io devo menzionarlo.

Se i soliti metodi di tracciamento dei bug non funzionano e tutto è un disastro totale, può essere meraviglioso avere un backup che puoi ripristinare facilmente.

Questo è ciò che eseguo localmente, automaticamente ogni ora dalle 8 alle 18:

rdiff-backup /path/to/mystuff /path/to/mybackup

Semplice eh?

Se devi mai ripristinare qualcosa, usa

rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored

rdiff-backup archivia solo i file che differiscono. Puoi usare rdiff-backup su Linux, mac e win.

Naturalmente, questo non dovrebbe essere il tuo unico backup. Ma è un modo estremamente semplice ed economico per avere un backup locale.

Ora, non lo consiglierei come un normale metodo di correzione dei bug, ma se tutto il resto fallisce, è un fallback.

Il bug potrebbe essere già esistito, ma è stato nascosto da fattori esterni o problemi di sistema profondi.

Questo mi è successo. Un bug sviluppato tra 2 build del nostro progetto. Letteralmente, l' unica modifica che abbiamo apportato è stata l'aggiornamento a una build più recente di quella delle librerie sottostanti.

Naturalmente li abbiamo incolpati. Ma l'unica modifica che avevano apportato era il refactoring di alcune intestazioni per una compilazione più rapida. Ho concordato che ciò non avrebbe dovuto rompere il sistema.

Dopo un lungo debug si è scoperto che il problema era un bug puntatore non autorizzato che era stato latente nel mio codice per anni . In qualche modo non è mai stato attivato fino a quando il loro refactoring non ha cambiato la disposizione dell'eseguibile.

ieri funzionava perché veniva usato correttamente.

scopri che altre persone usano le cose in un modo che non si suppone sia un buon modo per rompere le cose.

è sempre bene aggiornare il codice nelle prime ore del giorno poiché questo ti lascia con un buon ambiente di test.

! Backup

Trovo che sia utile impostare i punti di interruzione per mettere in pausa e controllare i miei dati, per individuare esattamente dove e come sta andando male.