È ragionevole insistere nel riprodurre ogni difetto prima di diagnosticare e ripararlo?

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?

Dovresti dare il massimo. So che a volte ci sono condizioni e ambienti così complessi che non possono essere riprodotti esattamente , ma dovresti sicuramente provare se puoi.

Se non hai mai riprodotto il bug e l'hai visto per te stesso, come puoi essere sicuro al 100% di averlo davvero corretto? Forse la tua correzione proposta introduce qualche altro bug sottile che non si manifesterà a meno che tu non provi per riprodurre il difetto originale.

If I am a senior developer, should I be able to read (multithreaded) code and create a mental picture of what it does in all use case scenarios rather than require to run the application, test different use case scenarios hands on, and step through the code line by line? Or am I a poor developer for demanding that kind of work environment? Is debugging for sissies?

Non mi fiderei di qualcuno che esegue il codice "nella loro testa", se questo è il loro approccio solo . È un buon posto per start . Riproducendo il bug, correggendolo e quindi dimostrando che la soluzione impedisce il ripetersi del bug, cioè dove dovrebbe end .

How should I talk with my team to convince them that my approach is reasonable, conservative and more bulletproof?

Perché se non hanno mai riprodotto il bug, non possono sapere per certo che è stato risolto. E se il cliente torna e si lamenta che il bug è ancora lì, questo è non una buona cosa. Dopotutto, ti stanno pagando un grande $$$ (presumo) per affrontare questo problema.

Se fallisci per risolvere il problema correttamente, hai infranto la fiducia del cliente (in una certa misura) e se ci sono concorrenti nel tuo mercato, potrebbero non rimanere tuoi clienti.

Come intendono verificare che il bug in questione sia stato corretto? Vogliono spedire il codice non testato all'utente e lasciare che lo scoprano? Qualsiasi configurazione di prova che non è mai stata mostrata per riprodurre l'errore non può essere invocata per mostrare l'assenza dell'errore. Di certo non è necessario riprodurre l'intero ambiente client, ma hai bisogno di abbastanza per riprodurre l'errore.

Non penso sia irragionevole tentare di riprodurre ogni bug prima di risolverlo. Tuttavia, se si tenta di riprodurlo e non è possibile, diventa più importante prendere una decisione sul fatto che le patch cieche siano o meno una buona idea.

Idealmente, vuoi essere in grado di riprodurre ogni bug in modo che, per lo meno, puoi verificare che sia stato corretto.

Ma ... Potrebbe non essere sempre fattibile o anche fisicamente possibile. Soprattutto con software di tipo "enterprise" in cui ogni installazione è unica. C'è anche la valutazione costi / benefici. Un paio di ore di analisi del codice e alcune ipotesi plausibili su un problema non critico potrebbero costare molto meno che avere un team di supporto tecnico che impiega settimane a provare a creare e duplicare l'ambiente di un cliente esattamente nella speranza di poter duplicare problema. Quando lavoravo nel mondo 'Enterprise', spesso volevamo solo i programmatori e facevamo correggere bug sul sito, perché non c'era modo di duplicare la configurazione del cliente.

Quindi, duplica quando puoi, ma se non puoi, sfrutta la tua conoscenza del sistema e prova a identificare il colpevole nel codice.

Non penso che dovresti fare un errore riproducendo il requisito di guardare il bug. Come hai già detto, ci sono diversi modi per eseguire il debug del problema - e dovresti usarli tutti. Dovresti considerarti fortunato che sono stati in grado di darti un file di registro! Se tu o qualcuno della tua azienda riesci a riprodurre il bug, bene! In caso contrario, si dovrebbe comunque tentare di analizzare i log e trovare le circostanze in cui si è verificato l'errore. Potrebbe essere possibile, come suggerito dai tuoi colleghi, leggere il codice, capire quali condizioni potrebbero verificarsi, quindi provare a ricreare tu stesso lo scenario.

Tuttavia, non rilasciare la correzione effettiva non testata. Qualsiasi modifica apportata dovrebbe passare attraverso lo standard di sviluppo, test del QA e routine di test di integrazione. Potrebbe rivelarsi difficile da testare - hai menzionato il codice multithreaded, che è notoriamente difficile da debugare. Questo è il punto in cui sono d'accordo con il tuo approccio per creare una configurazione di test o un ambiente. Se hai trovato un problema nel codice, dovresti trovare molto più semplice creare l'ambiente, riprodurre il problema e testare la correzione.

Per me, questo è meno un problema di debug e più di un problema del servizio clienti. Hai ricevuto una segnalazione di bug da un cliente; hai la responsabilità di fare due diligence per trovare il loro problema e risolverlo.

Secondo me ... in quanto decisore, devi essere in grado di giustificare la tua posizione. Se l'obiettivo del reparto di supporto della terza linea è quello di correggere i bug nel più breve periodo di tempo con lo sforzo accettabile da parte del cliente, qualsiasi approccio deve essere conforme a tale obiettivo. Inoltre, se si riesce a dimostrare che l'approccio fornisce i risultati più rapidi, non ci dovrebbero essere problemi a convincere la squadra.

Avendo lavorato in supporto, ho sempre ragionevolmente aspettato che il client fosse in grado di dare qualche "script" di azioni che eseguivano per riprodurre coerentemente il bug e, se non coerentemente, esempi di candidati che hanno prodotto il bug.

Se fossi nuovo nel sistema e non avessi uno sfondo con il codice, i miei primi passi sarebbero tentare di identificare le possibili fonti dell'errore. È possibile che la registrazione non sia sufficiente per identificare un codice candidato. A seconda del cliente, potrei essere propenso a dare loro una versione di debug in modo che possano essere in grado di restituirti i file di registro che forniscono ulteriori indizi sulla posizione del codice incriminato.

Se sono in grado di identificare rapidamente il blocco di codice, la mappatura visiva del flusso potrebbe essere sufficiente per individuare il codice. In caso contrario, la simulazione basata sul test unitario potrebbe essere sufficiente. È possibile che l'impostazione di un ambiente di replica client richieda meno tempo, soprattutto se esiste una notevole quantità di replicabilità del problema.

Penso che potresti scoprire che il tuo approccio dovrebbe essere una combinazione delle soluzioni proposte e che sapere quando uscire e passare a quello successivo è la chiave per portare a termine il lavoro in modo efficiente.

Sono abbastanza sicuro che il team supporterà l'idea che, se esiste una possibilità, la loro soluzione troverà il bug più veloce, dando loro un periodo di tempo adeguato per dimostrare che non inciderà troppo sul tempo necessario per sistemare l'errore qualunque percorso tu faccia.

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?

Dico di si, con alcuni avvertimenti.

• Penso che sia lecito leggere il codice e cercare di trovare luoghi che sembrano problematici. Creare una patch e inviarla al client per vedere se questo risolve il problema. Se questo approccio continua a fallire, potrebbe essere necessario esaminare altre opzioni. Ricorda che mentre potresti indirizzare un bug a potrebbe non essere il bug segnalato
• Se non riesci a riprodurlo entro limiti ragionevoli e non riesci a trovare alcun contrassegno rosso nel codice, potrebbe essere necessario un coordinamento più stretto con il cliente. Sono volato su siti di clienti prima di fare il debug sul sito. Non è il miglior ambiente di sviluppo, ma a volte se il problema è ambientale, quindi trovare la causa esatta sarà più semplice quando è possibile riprodurlo in modo coerente.

Sono stato sul lato cliente della tabella in questo scenario. Stavo lavorando in un ufficio del governo degli Stati Uniti che utilizzava un cluster di database Oracle incredibilmente grande (diversi terabyte di dati ed elaborazione di milioni di record al giorno).

Ci siamo imbattuti in uno strano problema che è stato molto facile da riprodurre per noi. Abbiamo segnalato il bug a Oracle e siamo andati avanti e indietro con loro per settimane, inviando loro i log. Hanno detto che non erano in grado di riprodurre il problema, ma ci hanno inviato alcune patch che l'auspicato potrebbe risolvere il problema. Nessuno di loro ha fatto.

Alla fine hanno portato fuori un paio di sviluppatori nella nostra posizione per eseguire il debugging del problema sul sito. E questo è stato quando è stata trovata la causa principale del bug e una patch successiva ha risolto correttamente il problema.

Se non sei positivo riguardo al problema, non puoi essere positivo riguardo alla soluzione. Sapere come riprodurre il problema in modo affidabile in almeno una situazione del caso di test consente di dimostrare che si sa come causare l'errore, e quindi consente anche di dimostrare sul rovescio della medaglia che il problema è stato risolto, a causa della successiva mancanza di errore nello stesso caso di test dopo aver applicato la correzione.

Detto questo, le condizioni di gara, i problemi di concorrenza e altri bug "non deterministici" sono tra i più difficili da definire per uno sviluppatore in questo modo, perché si verificano raramente, su un sistema con carico maggiore e più complessità di qualsiasi altro copia dello sviluppatore del programma e scompaiono quando l'attività viene rieseguita sullo stesso sistema in un secondo momento.

Molto spesso, ciò che in origine sembra un errore casuale finisce con l'avere una causa deterministica che si traduce in un errore irreversibile deterministicamente una volta che sai come. Quelli che sfidano questo, i veri Heisenbugs (bug apparentemente casuali che scompaiono quando si tenta di testarli in un ambiente sterile e monitorato), sono legati al timing del 99,9% e, una volta compreso, la via da seguire diventa più chiara; cerca le cose che potrebbero fallire se qualcos'altro dovesse ottenere una parola in modo discontinuo durante l'esecuzione del codice, e quando trovi una tale vulnerabilità, prova a sfruttarla in un test per vedere se mostra il comportamento che stai cercando di riprodurre.

In queste situazioni è generalmente richiesta una notevole quantità di ispezione approfondita del codice; devi guardare il codice, abbandonare qualsiasi nozione preconcetta su come il codice è supposto comportarsi, e immaginare scenari in cui potrebbe fallire nel modo in cui il tuo cliente ha osservato . Per ogni scenario, prova a sviluppare un test che possa essere eseguito in modo efficiente all'interno del tuo attuale ambiente di test automatico (cioè senza la necessità di un nuovo stack VM solo per questo test), che provi o smentisca che il codice si comporta come previsto ( che, a seconda di quanto previsto, proverebbe o smentirebbe che questo codice è una possibile causa dei problemi dei clienti). Questo è il metodo scientifico per gli ingegneri del software; osservare, ipotizzare, testare, riflettere, ripetere.

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?

No, assolutamente non lo è. Sarebbe una politica stupida.

Il problema che vedo con la tua domanda e la tua proposta è che non riescono a fare una distinzione tra

• segnalazioni di errori
• errori ( errori )
• bug (anche a volte chiamati errori )

Un rapporto bug è una comunicazione su un bug. Ti dice che qualcuno pensa che qualcosa non va. Può o non può essere specifico su ciò che dovrebbe essere sbagliato.

Una segnalazione di bug è la prova di un errore.

Un errore è un incidente di qualcosa che sta andando storto. Un malfunzionamento specifico, ma non necessariamente con indizi su cosa possa averlo causato.

Un errore può essere causato da un bug.

Un bug è una causa di errori; qualcosa che può (in linea di principio) essere modificato al fine di prevenire i fallimenti che provoca nel futuro.

A volte, quando viene segnalato un bug, la causa è immediatamente chiara. In tal caso, la riproduzione del bug sarebbe priva di senso. Altre volte, la causa non è chiara: il bug report non descrive alcun particolare errore, o lo fa, ma l'errore è tale che non fornisce un indizio su quale potrebbe essere la causa. In questi casi, ritengo che il tuo consiglio sia giustificato, ma non sempre: uno non insiste a schiantare un secondo razzo spaziale da 370 milioni di dollari prima di accettare di indagare su che cosa ha causato l'arresto del primo (un bug particolare nel software di controllo).

E ci sono anche tutti i tipi di casi in mezzo; ad esempio, se una segnalazione di bug non dimostra, ma suggerisce solo che un potenziale problema di cui già sapevi giocare un ruolo, potrebbe essere un incentivo sufficiente per dargli un'occhiata più da vicino.

Quindi, mentre insistere sulla riproducibilità è saggio per i casi più difficili, non è saggio applicarlo come una politica rigorosa.

Come per tutto il resto dello sviluppo del software, la risposta corretta è un compromesso.

In teoria, non dovresti mai provare a correggere un bug se non puoi provare che esiste. Ciò potrebbe comportare modifiche non necessarie al codice che in definitiva non risolvono nulla. E provarlo significa innanzitutto riprodurlo, quindi creare e applicare una correzione, quindi dimostrare che non succede più. Il tuo budello qui ti sta indirizzando nella giusta direzione: se vuoi essere sicuro di aver risolto il problema del tuo cliente, devi sapere cosa lo ha causato in primo luogo.

In pratica, non è sempre possibile. Forse il bug si verifica solo su grandi cluster con decine di utenti che accedono contemporaneamente al tuo codice. Forse esiste una combinazione specifica di operazioni sui dati su insiemi di dati specifici che attivano il bug e non hai idea di cosa sia. Forse il tuo cliente ha eseguito il programma ininterrottamente senza interruzioni per centinaia di ore prima che il bug si manifestasse.

In nessuno di questi casi, c'è una strong possibilità che il tuo dipartimento non abbia il tempo o i soldi per riprodurre il bug prima di iniziare a lavorare. In molti casi, è molto più ovvio per te, lo sviluppatore, che c'è un errore nel codice che ti indirizza alla situazione corretta. Una volta diagnosticato il problema, potresti essere in grado di tornare indietro e riprodurlo. Non è l'ideale, ma allo stesso tempo, parte del tuo lavoro come sviluppatore senior è sapere come leggere e interpretare il codice, in parte per individuare questi tipi di bug nascosti.

Secondo me, ti stai concentrando sulla parte sbagliata della domanda. Cosa succede se alla fine non puoi riprodurre il bug in questione? Nulla è più frustrante per un cliente che sentire "sì, sappiamo che hai bloccato il programma ma non possiamo riprodurlo, quindi non è un bug". Quando i tuoi clienti lo sentono, lo interpretano come "sappiamo che il nostro software è bacato, ma non possiamo preoccuparci di risolvere e correggere i bug, quindi basta incrociare le dita". Se è meglio chiudere un bug segnalato come "non riproducibile", o chiuderlo come "non riproducibile, ma abbiamo apportato alcune modifiche ragionevoli per cercare di migliorare la stabilità"?

A meno che l'errore sia evidente, ovvio e banale, con un messaggio di errore molto specifico, ecc., spesso è molto difficile correggere un bug se l'utente o il maintainer non sono in grado di replicarlo.

Inoltre, come dimostreresti che il bug è stato risolto se non riesci a replicare i passaggi?

Il problema con il tuo caso è che l'utente non sa come si è verificato l'errore, cioè in quale schermata di operazione. Hanno semplicemente il registro.

Penso che il tuo punto sia ragionevole. Se tu avessi poteri psichici , potresti non lavorare per uno stipendio.

Penso che dovresti dire ai tuoi capi che senza la possibilità di replicare l'errore ci vorrebbe un tempo noto per scoprirlo, e non c'è nessuna garanzia > quello che farai.

Il problema sarà quando alcuni tuoi colleghi troveranno il bug per pura fortuna e lo risolveranno.

Portiamolo all'estremo e supponiamo di aver trovato il bug molto prima: nel tuo codice, mentre lo stavi scrivendo. Quindi non avresti alcun problema a correggerlo proprio lì - vedi un difetto logico nel codice che hai appena scritto, non fa ciò che volevi che facesse. Non avresti bisogno di configurare un intero ambiente per dimostrare che si tratta di un bug.

Ora arriva una segnalazione di bug. Ci sono molte cose che puoi fare. Uno di questi è tornare al codice e rileggerlo. Supponiamo ora che in questa seconda lettura trovi immediatamente il bug nel codice - semplicemente non fa ciò che intendevi fare e non hai notato quando lo hai scritto. E , spiega perfettamente il bug appena arrivato! Tu fai la correzione. Ci sono voluti venti minuti.

È stato risolto il bug che causava il bug report? Non puoi essere sicuro al 100% (potrebbero esserci stati due bug che causano la stessa cosa), ma probabilmente lo ha fatto.

Un'altra cosa che potresti fare è riprodurre la configurazione del cliente nel miglior modo possibile (alcuni giorni di lavoro) e infine riprodurre il bug. In molti casi, ci sono problemi di temporizzazione e concorrenza che significano che non è possibile riprodurre il bug, ma si può provare molto tempo e a volte vedere accadere la stessa cosa. Ora inizi il debug, trovi l'errore nel codice, lo metti nell'ambiente e provi molte volte ancora. Non vedi più il bug che si verifica più.

È stato risolto il bug che causava il bug report? Non puoi ancora essere sicuro al 100% - uno, potresti aver visto un bug completamente diverso che il cliente ha fatto, due, forse non hai provato abbastanza spesso, e tre, forse la configurazione è ancora leggermente diversa ed è risolto su questo sistema, ma non su quello del cliente.

Quindi la certezza è impossibile da ottenere in ogni caso. Ma il primo metodo è molto più veloce (puoi dare al cliente una patch più veloce), è molto più economico e, se trovi un bug di codifica chiaro che spiega il sintomo, è più probabile che trovi il problema anche.

Quindi dipende. Se è economico configurare un ambiente di test (o meglio: un test automatico che mostri il problema), allora fallo. Ma se è costoso e / o le circostanze in cui il bug mostra sono imprevedibili, allora è sempre meglio cercare di trovare il bug leggendo prima il codice.

Leggendo la domanda, non vedo alcuna opposizione fondamentale tra la tua posizione e quella della tua squadra.

• Sì, dovresti fare del tuo meglio per riprodurre il problema che si verifica nelle impostazioni del client. Ma lo sforzo migliore significa che è necessario definire un intervallo di tempo per quello e potrebbero non esserci abbastanza dati nel log per riprodurre effettivamente il problema.

  Se è così, tutto dipende dalla relazione con questo cliente. Può passare da te non avrà altro da lui, al tuo potrebbe inviare uno sviluppatore sul sito con strumenti di diagnosi e capacità di eseguirli sul sistema in errore. Di solito, siamo nel mezzo e se i dati iniziali non sono sufficienti ci sono modi per ottenerne altri.

• Sì, uno sviluppatore senior dovrebbe essere in grado di leggere il codice ed è probabile che trovi il motivo del problema seguendo il contenuto del registro. In realtà, è spesso possibile scrivere alcuni test unitari che mostrano il problema dopo aver letto attentamente il codice.

  La capacità di scrivere tali test unitari è quasi buona quanto riprodurre l'ambiente funzionale che si rompe. Naturalmente, questo metodo non è una garanzia o che troverai qualcosa. Capire l'esatta sequenza di eventi che portano al fallimento in alcuni software multi-thread può essere davvero difficile da trovare semplicemente leggendo il codice, e la possibilità di eseguire il debug dal vivo è probabile che diventi critica.

In sintesi, proverei simultaneamente per entrambi gli approcci e chiedo sia un sistema in tempo reale che mostri il problema (e che mostri che sia stato riparato in seguito) sia che il test di rottura di un'unità rompa il problema (e lo mostri anche dopo il fix).

Cercando di correggere il codice e inviarlo in libertà, sembra davvero molto rischioso. In alcuni casi simili che mi sono capitati (dove non riusciamo a riprodurre internamente il difetto), ho chiarito che se una correzione è andata in the wild e non è riuscita a risolvere il problema del cliente, o ha avuto altre conseguenze negative inaspettate, il ragazzo che ha proposto dovrebbe aiutare il team di supporto a trovare il problema reale. Compreso trattare con il cliente se necessario.

Mi sembra che tu abbia bisogno di una registrazione più dettagliata.

Anche se aggiungere più logging non può garantire che non sarà necessario eseguire il debug (o, in questo caso, riprodurre la situazione), ciò fornirà una visione molto migliore di ciò che effettivamente è andato storto.

Soprattutto in situazioni complicate / di threading, o qualsiasi cosa in cui non si possa usare un debugger, ricorrere a "debug by printf ()" potrebbe essere l'unica risorsa. In tal caso, registrare il più possibile (più del previsto) e disporre di alcuni buoni strumenti per filtrare il grano dalla pula.

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?

Poiché nessuno lo ha ancora detto in termini chiari: Assolutamente no!

Come ogni altra cosa nello sviluppo del software, bugfixing significa tenere a mente tempo, rischio e costi. Trovare un equilibrio tra questi è la metà della descrizione del lavoro di uno sviluppatore.

Alcuni bug non sono abbastanza importanti da passare 2 giorni, ma abbastanza importanti da spendere 10 minuti per risolverli. Altri bug non sono deterministici e sai già che un ambiente di test non può dimostrare che sono stati corretti. Se la configurazione dell'ambiente di test richiede 2 giorni, non lo fai per questi bug. Invece, trascorri del tempo su cose più intelligenti, come trovare modi per configurare un ambiente di test in 5 minuti invece di 2 giorni.

E naturalmente ci sono dei bug in cui se si sbagliano un cliente perderà $ 100'000 +. E bug in cui il cliente perderà $ 100'000 + per ogni ora il bug non è stato corretto. Devi dare un'occhiata al bug e prendere una decisione. Le istruzioni generali per trattare tutti i bug non funzionano.

Bellissima domanda! La mia opinione è che se non riesci a riprodurre il problema, non puoi dire al 100% che la correzione che hai fatto non sarà:

a) risolve effettivamente il problema. b) crea un altro bug

Ci sono volte in cui si verifica un bug e io lo aggiusto e non mi preoccupo di testarlo. So al 100% che funziona. Ma fino a quando il nostro dipartimento di controllo della qualità dice che funziona, ritengo che sia ancora possibile che ci sia ancora un bug ... o un nuovo bug creato dalla correzione.

Se non riesci a riprodurre il bug e quindi installare la nuova versione e confermare che è corretta, non puoi, con certezza al 100%, dire che il bug è sparito.

Ho provato per qualche minuto a pensare a un'analogia per aiutarti a spiegare agli altri, ma non mi è venuto in mente nulla. Una vasectomia è un esempio divertente ma non è la stessa situazione: -)

[bug related to] concurrent database access, clustered implementation, multithreaded

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?

Non impiegherei troppo tempo a cercare di riprodurlo. Sembra un problema di sincronizzazione e quelli sono più spesso trovati per il ragionamento (a partire da registri come quello che devi individuare il sottosistema in cui si verifica il problema) piuttosto che essere in grado di trovare un modo per riprodurlo e attaccarlo con un debugger . Nella mia esperienza, la riduzione del livello di ottimizzazione del codice o talvolta l'attivazione di strumentazione aggiuntiva può essere sufficiente per aggiungere un ritardo sufficiente o una primitiva di sincronizzazione mancante per impedire che il bug si manifesti.

Sì, se non hai un modo per riprodurre il bug, non sarai in grado di assicurarti di risolverlo. Ma se il tuo cliente non ti dà il modo di riprodurlo, potresti anche cercare qualcosa di simile con la stessa conseguenza ma una causa diversa.

Entrambe le attività (revisione del codice e test) sono necessarie, né sufficienti.

Potresti passare mesi a costruire esperimenti cercando di riprodurre il bug, e non arrivare mai da nessuna parte se non hai guardato il codice e formulato un'ipotesi per restringere lo spazio di ricerca. Potresti soffiare mesi guardando il tuo ombelico cercando di visualizzare un bug nel codice, potresti persino pensare di averlo trovato una volta, due, tre volte, solo per avere il cliente sempre più impaziente che dice "No, il bug è ancora lì. "

Alcuni sviluppatori sono relativamente migliori in una sola attività (revisione del codice rispetto alla costruzione di test) rispetto all'altra. Un manager perfetto pesa questi punti di forza quando assegni bug. Un approccio di squadra potrebbe essere ancora più fruttuoso.

In definitiva, potrebbero non esserci abbastanza informazioni per riprodurre il bug, e devi lasciarlo marinare per un po 'sperando che un altro cliente possa trovare un problema simile, dandoti più informazioni sul problema di configurazione. Se il cliente che ha visto il bug lo vuole davvero corretto, lavorerà con te per raccogliere ulteriori informazioni. Se questo problema si verifica solo una volta, probabilmente non è un bug ad alta priorità, anche se il cliente è importante. A volte non lavorare su un bug è più intelligente del soffiare di ore di uomo in giro alla ricerca di un difetto davvero oscuro con informazioni insufficienti.