Responsabilità di riprodurre bug

Sto sviluppando un programma usando una libreria creata da un altro programmatore (lavora nella stessa azienda). Di recente ho scoperto una perdita nella libreria, che si verifica in determinate condizioni di rete dopo alcune ore di funzionamento. Ho presentato un bug con la descrizione delle condizioni per far accadere questa perdita. Lo sviluppatore ha risposto che "questo non è abbastanza", "non è sua responsabilità riprodurre i bug" e devo creare un test unitario per riprodurre questo bug, altrimenti non fa nulla.

1. Ha ragione?
2. Cosa posso fare in questa situazione? La creazione di unit test è impossibile, perché dipende da alcuni tempi di rete casuali.

Ha ragione è probabilmente una domanda a cui non si può veramente rispondere senza conoscere la propria azienda. Tuttavia, certamente non è molto utile.

Vorrei sollevare il bug con lui (cosa che hai fatto), se sta causando un problema con il tuo progetto, lo solleverei come un blocco con il tuo project manager e chiarirei che hai sollevato il bug con persona ma avrà un impatto sul tuo progetto se non viene risolto tempestivamente.

Vorrei anche andare a parlare con lo sviluppatore e spiegare perché non è possibile creare test unitari, ma saresti felice di mostrarlo sul tuo computer (supponendo che sia fattibile?).

Ha ragione al 100% che devi fornire abbastanza informazioni per rendere riproducibile il bug, altrimenti non c'è alcuna possibilità di scoprire se qualsiasi correzione che fornisce funzionerà davvero.

Ma - ha sbagliato l'IMHO al 100% che questo deve essere sotto forma di un test unitario. Se riesci a descrivere uno scenario di test in modo tale da riprodurre l'errore (almeno con un'alta probabilità in un ragionevole lasso di tempo, o mediante test manuali), hai la prova che il problema esiste - il che dovrebbe impostare il tuo collega nella responsabilità di ripararlo. Naturalmente, se sei in grado di creare uno scenario che riproduce il bug più rapidamente, sarebbe utile per lui. Idealmente, uno farebbe un test automatizzato e dipende dalla vostra organizzazione che ne ha la responsabilità.

Entrambe le parti dovrebbero impegnarsi.

Lo sviluppatore della biblioteca dovrebbe impegnarsi ulteriormente anche senza test unitari, poiché alcuni problemi non possono essere riprodotti con test unitari. A volte è hardware, a volte è una sequenza specifica di azioni corrette dal resto del programma che rende la libreria producendo risultati negativi.

Dovresti fare un ulteriore sforzo, perché dopo tutto questo non è un bug nella libreria, ma il risultato di azioni errate dal resto del programma (ad es. Heap corrotto può far comportare in modo strano qualsiasi libreria). Quindi ha senso ridurre il più possibile il codice non di libreria coinvolto nella riproduzione di bug. E probabilmente lo farai più veloce e più pulito di una persona che non ha familiarità con il codice della tua applicazione.

Se l'autore della libreria non è in grado di riprodurre il bug in base alla tua segnalazione, è irragionevole aspettarsi che ci passi molto tempo, figuriamoci a correggerlo.

Ma hai anche una quantità limitata di tempo a lavorare su un prodotto che è periferico per il tuo interesse. Sfortunatamente, questo può significare che il bug continua a esistere e non viene fatto alcun lavoro per risolverlo.

Fortunatamente questo non è necessariamente un disastro - mentre in un mondo ideale, tutto il software sarebbe privo di bug, non è questo il caso, e quindi dobbiamo dare la priorità in base ai problemi che causa agli Stati Uniti.

Ciò significa che è davvero tua responsabilità sviluppare un caso di test riproducibile SE LO VUOI RISOLTO. Potrebbe non interessarti se viene risolto e, in tal caso, hai fatto tutto ciò che è possibile e ci si dovrebbe aspettare da te. Potresti volerlo riparare, ma non abbastanza per dedicare tempo a renderlo riproducibile in questo momento. Questo è perfettamente accettabile.

Segnalare un bug al meglio delle tue capacità nel tempo in cui devi affrontarlo è semplicemente una buona cittadinanza, non devi andare oltre a meno che non sia necessario per il tuo programma. E potresti non voler farlo anche in quel momento, potrebbe esserci un'altra libreria che potresti usare, o potrebbe essere possibile creare il tuo in un periodo di tempo ragionevole. Fondamentalmente spetta a te decidere quale e che tipo di sforzo vale per te.

Sarei propenso a lasciar mentire i cani che dormono per ora - hai sollevato il problema e gli è stato assegnato. Presumibilmente ci sono processi in atto per rintracciare bug eccezionali e inseguirli?

Se desideri progredire attivamente oltre, suggerirei di parlare con il tuo manager per verificare se sono disponibili strumenti di test in grado di riprodurre in modo affidabile il problema.

Da parte dello sviluppatore - sarebbe seriamente inerte da parte loro non fare nulla dato che hai fornito le informazioni richieste. Potrebbe essere possibile, tuttavia, che abbiano un carico di lavoro enorme, quindi non è possibile dedicare il tempo necessario per rintracciare il problema.

Hai trovato un bug, l'hai segnalato e lui è un idiota a riguardo.

Se voi due foste amici intimi, avrebbe fatto qualcosa per aiutare, ma avrebbe preferito semplicemente respingere il problema.

Puoi fare di più, segnalando più dettagli e cercando di supportare le tue affermazioni sulla perdita di memoria. Tuttavia, hai le tue responsabilità e devi finire il tuo lavoro.

Accedi quante più informazioni possibili al bug tracker e vai avanti.

Se vedi di nuovo questa persona in futuro. Sii amichevole, prova a parlare di interessi comuni e capisci che le buone relazioni sono un modo molto più efficace per sistemare le cose, quindi qualsiasi quantità di fatti che puoi fornire per supportare un reclamo.

Spesso, ciò che ho riscontrato in situazioni simili è un presupposto che tutti i bug dovrebbero essere corretti e, sebbene sia ammirevole, è sicuramente un grande obiettivo da avere (ammettiamolo, non abbiamo mai deciso di scrivere bug!) In definitiva non è realistico in qualsiasi progetto di dimensioni decenti per correggere un bug solo perché è un bug (se riesci a trovarlo!) Ecco perché abbiamo metodologie, modelli e pratiche di gestione del progetto e di codifica ecc.

Quindi, una cosa che direi in difesa del proprietario della biblioteca (ed è stato il caso quando ho lavorato su alcuni grandi progetti) è che il tempo di sviluppo costa denaro ed è una risorsa limitata, quindi la decisione su come gestire un rapporto , che indaga, quali test vengono prodotti / necessari e, in definitiva, se (e se sì, quando) viene messa in atto una correzione si basa esclusivamente sull'impatto sul business. Qual è l'impatto del riavvio del processo di lunga durata una volta ogni tanto se fallisce e puoi facilmente automatizzarlo invece (e forse non dovresti già essere una misura di programmazione difensiva?) È solo il tempo o c'è di più ?

Guardalo anche dal loro punto di vista, una segnalazione di bug da un utente di un problema imprevedibile in un po 'di codice che si verifica molto raramente, solo in combinazione con il loro codice, possibilmente solo su una macchina e solo sotto una serie di tempistiche insolite le condizioni non avranno una forte giustificazione per un grosso pezzo di tempo di sviluppo da trovare e correggere - se è anche possibile. Ma se è un caso aziendale abbastanza forte per quell'utente che desidera / ha bisogno di prendere il tempo di investigare più a fondo e fornire un caso / applicazione di prova affidabile o una descrizione del problema radicalmente più dettagliata di quella iniziale, allora potrebbe essere un altro gioco di ruolo .

Questo è forse un problema di comunicazione che il proprietario della biblioteca non ha preso in considerazione di mettere in quel modo e se hai un caso aziendale forte (come il tuo codice è costoso per l'azienda, ha un requisito di conformità legale, buca di sicurezza o ha alcuni altri importanti effetti a catena), allora è il momento di dare il via alla direzione e lasciarli combattere.

Hai detto che "ho presentato un bug con la descrizione delle condizioni per far accadere questa perdita".

Se sei sicuro che la descrizione sia davvero sufficiente per riprodurre un bug, conosci già le condizioni esatte. Ora, se non è possibile scrivere unit test dopo aver conosciuto le condizioni, ciò significa chiaramente che non è possibile deridere alcuni dei componenti coinvolti o alcune parti del codice sono troppo strettamente accoppiate per consentire di creare un unit test pratico.

Dovresti chiedere al proprietario della biblioteca di refactificare il codice per permetterti di creare unit test. Dovrai spiegare chiaramente cosa c'è nella libreria che ti impedisce di creare unit test. Dovrà refactificare il codice altrimenti concedere che il test unitario non è possibile con il codice corrente. In entrambi i casi, hai vinto.

Se il problema persiste, sono disponibili le seguenti opzioni:

• È possibile riprodurre un bug con più prove.
• Prova a coinvolgere un'autorità superiore e chiedigli di valutare le tue prove.
• Prova a utilizzare la libreria nell'applicazione prototipo con ambiente simulato per essere codificato solo per riprodurre bug. In questo modo, sarai in grado di provare almeno che esiste un bug.