Quando arrivi al mattino, scopri che il tuo software non funziona più, anche se è successo quando sei partito ieri sera.
Che cosa fai? Cosa controlli prima? Che cosa fai per smettere di essere arrabbiato 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:
Hai pensato che funzionasse ieri, ma dopo un'intera giornata di lavoro sei diventato troppo cieco per capire che non ha funzionato.
Questa mattina non puoi più fare riferimento a ciò che era nella memoria cache IDE ieri.
La workstation è stata riavviata ieri sera o un'operazione di manutenzione notturna cancellata / directory tmp.
Qualcosa è cambiato nella base di codice: controlla se qualcuno (forse tu stesso) ha commesso dei cambiamenti tra l'ultima compilazione di ieri e l'ultima compilazione 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 esterne se è stata distribuita una nuova versione di un pacchetto apparentemente indipendente.
Qualcosa è cambiato nell'ambiente di testing: nuova versione di una macchina virtuale, uno stub che è stato modificato, modifiche in un server di database remoto ...
Qualcosa è cambiato nella catena della compilation: cambiamenti nei Makefile, nuova versione di IDE, del compilatore, delle librerie standard ...
1) Se non funziona oggi, non funzionava neanche ieri.
hai pensato che funzionava, ma non lo era.
2) C'è un problema e deve essere risolto .
Non pensare a chi è responsabile di questo o di incolpare gli altri.
Se non è cambiato nulla tra ieri e oggi (come presumo leggendo la tua domanda), significa che dovresti fare un lavoro migliore a testare il tuo codice prima di dichiarare che funziona.
Per evitare questa situazione, devi eseguire Test e Debug appropriati
.Definisci "working" e verifica i limiti delle tue routine di codice.
Un modo per farlo è avere una serie automatizzata di test estesi eseguiti durante la notte, in modo che il giorno successivo sia possibile verificare se qualcosa è andato storto e risolvere i problemi.
Cercare di trovare qualcuno per passare la colpa è non costruttivo e non risolve i problemi. Non farlo.
Se qualcosa ha funzionato ieri e non funziona ora, o hai un comportamento non deterministico (come una condizione di competizione) e averlo funziona ieri era solo fortuna, o qualcosa è cambiato tra allora e ora, e devi trovare fuori di cosa si tratta.
Come esattamente scopri quale è 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 guardare se che aiuta - scopri quale specifica cosa ha causato il problema, e magari annotare come risolverlo in modo da poterlo consultare quando succede ancora tra 3 settimane a partire da ora.
Anche l'utilizzo degli strumenti diagnostici appropriati (debugger, profiler, strumenti di analisi della rete) può fare una grande differenza.
Ho lavorato con il codice che sembrava cambiare durante la notte e dopo un po 'sono arrivato alla conclusione che ciò era dovuto a folletti malevoli che strisciavano nella mia base di codice durante la notte e cambiano le cose in modo tale che nonostante abbia funzionato ieri , ora non funziona affatto. Infatti, nello stile classico Schroedinbug , non solo non funziona ora, è chiaramente chiaro che non c'è modo che potrebbe mai avere.
Nel corso del tempo mi sono reso conto che è possibile che in effetti i folletti non abbiano nulla a che fare con questo e che forse il mio "tempo di andare a casa, sarà abbastanza buono" l'ultima build non riceve i test dettagliati e l'attenzione che forse merita.
La mia prima ipotesi quando mi trovo di fronte al mattino è che probabilmente è colpa mia perché di solito sono io il responsabile delle mie funzioni o degli angoli del software su cui sto lavorando. La mia seconda ipotesi è che ora potrei prendere quel caffè. Se non è qualcosa di palesemente ovvio che una scimmia potrebbe capire (che a volte è), allora è probabile che io sia riuscito a trascinare in una vecchia versione di una libreria, erroneamente arrotolato un file che non ha bisogno di essere arrotolato indietro o avere qualcosa in cache da qualche parte che lo ha portato nella build senza controllarlo. Passare attraverso la mia recente attività di controllo del codice sorgente tende a rivelare le cose che ho fatto, la pulizia della build spesso rimuove le versioni errate della cache.
A volte non ha niente 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 sfondo, ma di solito è un caso di controllo e di accettare che, come la maggior parte delle persone, sono fondamentalmente un idiota.
Usa controllo versione. Fai una diff o usa la tua funzionalità di bias VCS:
diff : ogni VCS. Mostra le differenze tra, uhm, diverse versioni blame : ad esempio git. Ti mostra su base riga per riga chi ha cambiato cosa Se non c'è il controllo della versione, a parte il fatto che è colpa tua o del tuo capo, puoi controllare le date di modifica dei file ed eventualmente esaminare le strutture di registrazione del tuo sistema operativo.
A parte questo: ricompila tutto, assicurati di ricompilare anche le librerie ausiliarie.
Ovviamente: se hai trovato la fonte dell'errore, stai calmo, chiedi perché è stato fatto un cambiamento, spiega il tuo problema e proponi una soluzione che ti 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 sono stati aggiornati con una nuova versione di Apache che ha determinato alcune configurazioni non valide.
Bene, ecco un esempio di codice di vita reale che "ha funzionato ieri" e non oggi ... È di inizio mese.
L'applicazione in questione recupera informazioni da un database per data e il comportamento predefinito è quello di ottenere dati per il giorno corrente. Questo ha funzionato bene 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 è di ricontrollare come formatti le date, perché se mischi i campi del giorno e del mese funzionerà perfettamente, ma solo per 1 giorno al mese: - )
Correggi il bug (ma normalmente lo fai). Quindi, se trovi chi l'ha causato, invia loro un'e-mail educata per informarli di cosa è andato storto.
Ogni coder commette errori e se inizi a incolpare ti ritorcerai seriamente la prossima volta che fai la stessa cosa. (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 concentrati su quelli che non funzionano.
In realtà è quello che ti sei dimenticato di fare ieri prima di partire, succede.
Non ne hai? Ok .. cosa stai dicendo? Incolpare ? Bene ... che potrebbe funzionare, quindi
La prima cosa da fare quando qualcosa smette di funzionare è chiedersi: cosa c'è di diverso? Cosa è cambiato?
Quando qualcosa ha funzionato ieri sera ma fallisce questa mattina, l'unica cosa che è ovviamente cambiata è la data e l'ora :)
Vorrei provare 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 questa sia la causa di tali problemi.
Se ciò non dovesse funzionare, dovresti assolutamente seguire l'altro ottimo consiglio fornito qui.
Una sorta di risposta breve (per scrivere) ma piuttosto lunga per averne il succo: Perché i programmi falliscono: una guida per Debug Systematic di Andreas Zeller (che potrebbe sembrare un po 'troppo accademico ma non lo è)
Si guarda nella propria casella di posta dopo la posta inviata dal motore di Continuous Integration quando il test delle unità fallito (o la pagina di log se non si è visto quello specifico problema), e si vede chi ha fatto il check-in solo prima di quella build.
Poi 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 e non hai tenuto conto. Entrambi i dati non sono validati correttamente o non è stato rivelato un errore di logica fino a quando non si è verificata una condizione logica non prevista. Ciò significa che il bug era lì ieri, ma si stava nascondendo da te sotto dati validi.
Una volta ho avuto un codice d'ordine che funzionava bene per settimane. Sono andato a casa un giorno, ed è morto. Le indagini del giorno successivo hanno rivelato che avevo un bug nascosto in una catena di chiamate di funzione. In un linguaggio debolmente tipizzato, ho dichiarato un intero quando avrei dovuto usare un int lungo. Il linguaggio ha fatto la conversione tra i due automaticamente fino a quando non è stato possibile perché il numero ha superato quello che si sarebbe adattato a un numero intero. Il sistema non è riuscito con il numero ordine 32768.
Guarda cosa è cambiato
Guarda cosa è cambiato da quando ha funzionato. La sezione IT ha inviato un aggiornamento del sistema operativo? Un altro codificatore ha modificato il codice che utilizza il tuo programma? Il permesso dell'utente è cambiato? Spesso, se trovi ciò che è cambiato, troverai il bug.
funziona particolarmente bene per errori JavaScript difficili. In pratica, commenta metà del codice, vedi se ottieni l'errore, se lo fai è in quella metà del codice. Metà di nuovo e continua.
Se il tuo codice è ben incapsulato, questo è un fantastico strumento per ridurre lo stress.
Una volta trovato il codice di errore, è spesso utile isolare l'errore nella propria pagina di test.
And of course, what can be done to avoid being in such a situation?
Affrontando questa domanda, potresti voler esaminare Continuous Integration (CI) . In poche parole: CI è un processo in cui gli sviluppatori spesso (anche più volte al giorno) integrano e testano tutto il codice. L'idea è che le modifiche a un modulo che interrompono un altro modulo si trovino rapidamente.
In pratica, la maggior parte dei team che impiegano CI usano 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. Una volta completata la compilazione, eseguirà una serie di test automatici e pubblicherà i risultati via e-mail e / o pagina web della build e dei test, insieme a quali modifiche hanno causato la compilazione. Speriamo che quando qualcosa rompe la build o i test, hai solo un set di modifiche molto piccolo da esaminare, quindi viene risolto più rapidamente.
Qui ci sono altre domande su quale server CI usare, quindi ti permetterò di trovarle interessate. Personalmente, sono un grande fan di Jenkins.
[What should I do about things being broken.]
Come altri hanno già detto, scopri cosa ha rotto e prova a risolverlo. Trascorrere del tempo a cercare di dare la colpa è il tempo speso a non risolvere il problema.
La mia reazione naturale è sempre quella di incolpare gli altri, ma col tempo sono arrivato a rendermi conto che è di solito me che è in colpa. Oltre a tutti i commenti eccellenti di cui sopra, è importante registrare da solo quale sia stata la ragione finale. Non importa se usi un Wiki condiviso con altri membri del team, un privato Twiki, Evernote, un diario di bordo o una buona memoria. La cosa importante, al momento in cui trovi la risposta (e vuoi tornare al lavoro!) È di registrare il motivo.
Presumibilmente, se non funziona più, hai identificato i sintomi che non funzionano, cioè, si blocca, o restituisce all'utente una particolare finestra di errore.
Se la sola descrizione del problema è "non funziona", la prima cosa che devi fare è raccogliere più informazioni sui sintomi del problema.
Quindi inizi a cercare le possibili cause, tramite registri o tentativi di ricreazione del problema o una combinazione di entrambi, dipende dal modo in cui il tuo sistema è impostato, immagino.
Quindi inizi a escluderli.
È quello che succede di solito quando prendo le vacanze: -)
Più seriamente, prima gli dicevo:
cercherò in esso per vedere cosa c'è che non va e cosa potrebbe essere la radice
Toccherà la base tra 30-60 minuti una volta che ho avuto la possibilità di vedere cosa sta succedendo
Dopo quel tempo, posso azzardare una stima di cosa potrebbe essere successo e quanto tempo ci vorrà per risolverlo se non è già stato risolto e, se applicabile, quali dati potremmo aver perso (ma ho dei buoni backup, quindi quello non accade mai speranzoso).
Per quanto riguarda la parte incolpevole:
se è solo un errore di battitura di un collega, non c'è bisogno di menzionarlo: la merda accade e lo spavento del bug probabilmente gli ha insegnato una lezione e, si spera, non lo farà più.
se ha intenzionalmente fatto qualcosa che gli ho detto di non (ad esempio, fornire la password di root del server di produzione al nuovo ragazzo e dirgli di apportare una modifica direttamente senza supervisione) (sì, è già successo. ..), quindi devo menzionarlo.
Se i tuoi 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:00 alle 18:00:
rdiff-backup /path/to/mystuff /path/to/mybackup
Semplice, eh?
Se dovessi ripristinare qualcosa, usa
rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored
rdiff-backup memorizza solo i file che differiscono. Puoi usare rdiff-backup su Linux, mac e win.
Naturalmente, questo non dovrebbe essere il tuo unico backup. Ma è estremamente facile ed economico 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 da profondi problemi di sistema.
Questo è successo a me. Un bug sviluppato tra 2 build del nostro progetto. Letteralmente, il solo cambiamento che avevamo fatto era di aggiornare a una build più recente di una delle librerie sottostanti.
Naturalmente li abbiamo incolpati. Ma l'unica modifica loro era stata quella di ridefinire alcune intestazioni per una compilazione più rapida. Ho deciso che non avrebbe dovuto infrangere il sistema.
Dopo un lungo debug si è scoperto che il problema era un bug di puntatore canaglia che era stato latente nel mio codice per anni . In qualche modo non è mai stato attivato fino a quando il loro refactoring non ha modificato la disposizione dell'eseguibile.
funzionava ieri perché veniva usato correttamente.
scopri che le altre persone usano le cose in un modo che non suppone a quale sia un buon modo di rompere le cose.
è sempre buono per aggiornare il codice nelle prime ore del giorno in quanto ciò ti lascia con un buon ambiente di test.
Backup!
Trovo i breakpoint di impostazione da mettere in pausa e controllare i miei dati molto utili, per individuare esattamente dove e come va male.