Devo dire a qualcuno che il loro commit ha causato una regressione?

Quando rintracci e correggi una regressione, ovvero un bug che ha causato l'interruzione del codice precedentemente funzionante, il controllo della versione rende completamente possibile cercare chi ha commesso la modifica che l'ha interrotta.

Vale la pena farlo? È costruttivo segnalarlo alla persona che ha commesso il commit? La natura dell'errore (sulla scala della semplice disattenzione al fondamentale fraintendimento del codice che hanno cambiato) cambia o no è una buona idea?

Se è una buona idea dirglielo, quali sono i modi migliori per farlo senza provocare offesa o farli diventare difensivi?

Supponiamo, per ragioni di argomento, che il bug sia sufficientemente sottile da impedire ai test automatici del server CI di rilevarlo.

Se ti avvicini a loro per dire loro di un errore che hanno fatto, a meno che tu non sia il miglior diplomatico al mondo, sarà difficile per lui non sembrare solo "Ah! - guarda questo errore che hai fatto!". Siamo tutti umani e le critiche sono difficili da prendere.

D'altra parte, a meno che il cambiamento non sia del tutto banale e ovviamente sbagliato, di solito trovo utile parlare con la persona che ha commesso il cambiamento originale come parte della mia indagine solo per assicurarsi di aver compreso appieno ciò che sta accadendo, quindi il modo in cui di solito finire per gestire questa situazione è andare da quella persona e avere una conversazione che va un po 'così:

Io: sto lavorando a questo bug in cui ... riepilogo del bug ... e penso di aver rintracciato il problema per una modifica che hai apportato. Ricordi a cosa serviva questo cambiamento? / hai del tempo per spiegare questo cambiamento?

Quindi:

Loro: certo, questo è per gestire ... la situazione di cui non ero a conoscenza ...

O qualcosa del genere:

Loro: No, scusami, non mi ricordo, mi sembra sbagliato.

Andando e studiando insieme il cambiamento / bug, il committer originale impara dai loro errori senza sentirsi criticato *, e c'è anche una buona possibilità che imparerai anche qualcosa.

Se il committer originale non è nei paraggi o è occupato, allora puoi sempre sfogliare e capire tutto da solo, trovo normalmente che parlare con la persona che ha originariamente apportato la modifica sia più veloce.

* Ovviamente funzionerà solo se sei veramente interessato all'aiuto delle altre persone. Se lo stai usando come un metodo sottilmente mascherato di dire a qualcuno un errore che hanno fatto, probabilmente è peggio che essere semplicemente aperto.

Sii assertivo, non aggressivo. Preferisci sempre dire qualcosa di simile a "questo pezzo di codice non funziona" vs "il tuo codice non funziona". Critica il codice, non la persona che ha scritto il codice.

Meglio ancora, se riesci a pensare a una soluzione, risolvila e spingi verso di essa, supponendo che tu abbia un sistema di controllo della versione distribuito. Quindi chiedi loro se la tua correzione è valida per il bug che stavano risolvendo. Nel complesso, cerca di aumentare la tua e la loro conoscenza della programmazione. Ma fallo senza che il tuo ego si frapponga.

Ovviamente, dovresti essere disposto ad ascoltare altri sviluppatori che vengono da te con lo stesso problema e ad agire come avresti desiderato.

Si sempre . Come programmatore, è il tuo lavoro imparare dagli errori.

Far loro sapere gli errori che commettono li aiuterà a diventare un programmatore migliore e ridurre le possibilità di errori in futuro. MA sii educato e non fare molto, creiamo bug ogni tanto. Trovo che un'e-mail educata sia un modo molto non conflittuale di far conoscere la gente.

Il modo costruttivo è trovare il bug, risolverlo e intraprendere azioni per evitare che insorgano bug simili in futuro.

Se si tratta di spiegare alle persone come non introdurre bug, provaci.

Una volta, ho lavorato in un team in cui il project manager non ha mai detto a un particolare sviluppatore che ha commesso un errore: ha organizzato un incontro con l'intero team in cui ha spiegato che è stato commesso un errore e che è stato definito un nuovo processo per sopprimere quel tipo di errori. In questo modo, nessuno è stato stigmatizzato.

In generale, sì .

Nessuno dovrebbe difendersi se sei discreto al riguardo. Un modo semplice per gestirlo è chiedere loro di ricontrollare la modifica prima di ricollegarla al trunk (o qualsiasi cosa sia rilevante per il sistema di controllo della versione). Le persone lo apprezzeranno se li salvi qualche minuto correggendo errori evidenti, ma non lo apprezzeranno se risolvi qualcosa che non è stato rotto e finiscono per rompere il loro codice. Dare loro la possibilità di rivedere la modifica indica che non si desidera fare un passo avanti e offre loro l'opportunità di opporsi alle modifiche.

Se è un grande cambiamento piuttosto che un semplice errore di battitura, è una buona idea dare un avvertimento all'autore prima di scavare nel tentativo di risolverlo. "Joe, ieri ho unito le mie cose e ho trovato qualcosa che non sono sicuro di capire. Sembra un bug, ma volevo eseguirlo da te prima di andare a fare confusione con il tuo codice. Vuoi dare un'occhiata a me?"

La tua relazione con l'autore è un grande fattore. Se non ti dispiace l'autore che ripara il tuo codice senza dirtelo e se sei abbastanza sicuro che il sentimento sia reciproco, potrebbe non valere la pena menzionarlo. Se è qualcuno con più esperienza / anzianità / stato, vorrai fargli sapere che cambierai il loro codice. Se è qualcuno con meno, allora considera se è il genere di cose che devono ascoltare per evitare di ripetere l'errore o potrebbe metterli in imbarazzo inutilmente.

Ricorda sempre che se riesci a scoprire chi ha controllato il "bug", possono facilmente scoprire chi ha "corretto" il loro codice. Se pensi che sarebbero sconvolti / infastiditi / imbarazzati nel scoprire il tuo cambiamento dopo il fatto, dillo loro in anticipo.

Inoltre, la correzione del bug non è la tua unica opzione. Puoi sempre segnalare il bug nel tracker dei problemi. Qui è di nuovo richiesto il tatto: la segnalazione del bug lo rende più visibile a tutto il team, ma offre anche all'autore la possibilità di correggere il proprio errore. La segnalazione è l'opzione migliore se non si è certi del modo migliore per risolvere il problema o se non si ha il tempo di risolverlo.

Se faccio un commit che include un bug, è meglio che me lo dica. Se trovo un tuo commit che include un bug, te lo dirò sicuramente.

Miglioriamo solo quando comprendiamo i nostri errori. È così che produciamo un codice migliore in futuro.

Stai ricevendo risposte eccellenti qui.

Potrei solo aggiungere una tecnica che ho imparato da un manager una volta quando avrei fatto un errore.

Ero il consulente di mezza età con il dottorato. ed era la giovane manager senza, quindi poteva esserci un gradiente di prestigio percepito. Ad ogni modo, aveva chiaramente avuto esperienza con questa situazione e sapeva come gestirla.

Mi disse in tono quasi di scusa che sembrava esserci un problema e avrei avuto il tempo di esaminarlo?

Abbastanza spesso, l'errore era mio e lei lo sapeva. Questa è abilità.

Penso che ci sia un problema più profondo alla base di questa domanda. Sì, il mittente dovrebbe certamente essere informato delle conseguenze del loro cambiamento, in modo che possano capire cosa è successo e non fare più la stessa cosa. Tuttavia, il contesto della tua domanda indica che hai preparato e inviato una correzione all'insaputa del mittente originale che hanno persino causato un problema. Qui sta il problema più profondo: perché il mittente non conosce già la regressione e perché non l'hanno risolto da soli? La situazione che hai descritto può indicare una mancanza di responsabilità o vigilanza da parte del mittente originale, che è una potenziale preoccupazione per quanto riguarda le prestazioni complessive e la motivazione.

La mia esperienza di ingegneria del software mi ha insegnato a possedere tutte le mie modifiche al codice, non solo i progetti di cui sono responsabile, fino alla produzione, il che include la consapevolezza del loro impatto, incluso sul sistema di compilazione e (ovviamente) il comportamento del prodotto.

Se il cambiamento di qualcuno ha causato un problema, ciò non significa che la persona sia un cattivo ingegnere, ma di solito dovrebbe essere responsabile e coinvolto nella riparazione di qualsiasi cosa sia andata storta. Anche se non sono "in errore", ad esempio il loro codice ha esposto un bug sottostante che esiste da anni nella base di codice, dovrebbero essere tra le prime persone a essere consapevoli di un problema con la loro modifica. Anche se il mittente originale non è la persona giusta per correggere il bug, dovrebbe essere strettamente connesso al ciclo di vita della sua modifica.

Buona trazione sulla tua domanda! Tutti ti hanno detto cosa fai. Dovresti dirlo? SÌ! Ogni volta che la domanda "dovrei comunicare di più?", La risposta è quasi sempre SÌ!

Ma per aggiungere qualcosa di diverso: la tua premessa è difettosa.

Un collega ha fatto un commit che non ha rotto la CI, ma ti ha portato a scoprire un problema.

Congratulazioni! Hai trovato un nuovo bug, non una regressione. Seriamente, testate manualmente ogni scenario e linea di codice non coperti da test automatizzati (o manuali standardizzati) quando commettete?

Sicuramente, coinvolgi il tuo collega nella correzione, con test per assicurarsi che non possa più accadere. Siete entrambi eroi! Ma se lasci scivolare qualsiasi colpa in parole o azioni, sei responsabile di perpetuare una delle peggiori malattie organizzative: responsabilità senza responsabilità.

Se hai davvero bisogno di trovare un villico, pensa al ragazzo che ha commesso il codice originale che si è rotto e ha lasciato una trappola per il tuo amico ignaro (ovviamente senza una copertura di prova sufficiente). Spero che non fossi tu!

Considera sempre l'altra persona come una persona migliore di te, vedi sempre le altre buone caratteristiche e sappi sempre che anche io posso fare errori.

Di 'loro quando sono solo voi due.

Se qualcuno si offende quando gli hai detto che ha fatto un errore, significa che pensa di essere il più saggio della terra e non commette errori, e quando criticato, ha la sensazione, come abbiamo detto in Polonia, che "la corona sta cadendo da la sua testa'.

Quindi non dovresti esitare a dire che qualcuno ha fatto un errore. È normale. Tutti commettono errori, anche il migliore! Solo quelli che non fanno nulla non commettono errori;)

Oltre a ciò che altri hanno detto, assicurati che sia proprio il loro commit a causare un bug. Certamente non dare la colpa a qualcun altro per il tuo errore. Non importa quanto delicatamente ti avvicini a loro, li farai comunque incazzare se li biasimerai per qualcosa che non hanno fatto. (Parlando come qualcuno che è stato incolpato costantemente per gli errori di altre persone; una volta qualcuno è venuto da me e ha detto che ho fatto qualcosa di assolutamente stupido e ho portato il registro di commit e ho scoperto che l'ultima persona a toccare quella riga di codice era la persona che mi stava incolpando. In qualche modo sembrava ancora pensare che fosse colpa mia perché avevo scritto la riga in origine.)

Perché non vedo una sola risposta qui che riflette il commento più votato sulla domanda ??

Sì, parlane assolutamente, ma non farlo di fronte a tutto il team

Avvicinati allo sviluppatore 1: 1 e segnala il bug. Non fare molto. Ho sempre pensato che sottolineare l'errore di fronte all'intera squadra fosse una cattiva idea. Potrebbe funzionare per alcuni sviluppatori, ma non è per tutti e può avere un effetto negativo. Ricorda, siamo stati tutti nei loro panni a un certo punto o nell'altro, e come dice la seconda risposta più votata, impari dai tuoi errori

Di solito trovo che funzioni meglio quando inizi con un complimento e poi arrivi all'errore ... qualcosa del tipo "la correzione che hai implementato funziona alla grande, MA sembra che abbia rotto x, y, z" o "grazie per aver fatto un , b, c, MA sembra che stia causando x, y, z "

Risposta semplice: Sì.

Risposta più lunga: il mio ultimo lavoro è stato presso una società Agile che ha utilizzato TDD con strumenti CI per garantire che ciò che era nel nostro repository SVN fosse buono, codice funzionante in ogni momento. Quando qualcosa è stato commesso, il nostro server TeamCity ha ricevuto una copia, compilato ed eseguito test unitari. Ha inoltre eseguito test di integrazione ogni ora. Se veniva commesso qualcosa che causava il fallimento dell'elemento della configurazione, tutti ricevevano un'e-mail in cui si affermava che la build si era interrotta in base a un commit di una determinata persona.

Questo non ha sempre preso tutto; guai a noi, non abbiamo imposto la copertura del codice e anche se qualcosa fosse coperto da test unitari o di integrazione, potrebbero non esercitare quel codice sufficientemente. Quando ciò accadesse, chiunque avesse il compito di risolvere il problema noto (se il QA lo avesse colto) o un difetto (se, dun-dun-dun, i clienti lo avessero fatto), avrebbe eseguito una "colpa" (mostra chi ha modificato per ultimo ogni riga di un file di codice) e determinare il colpevole.

Chiamare qualcuno per verificare il codice non è necessariamente una cosa negativa. Non sono riusciti a svolgere correttamente il loro lavoro e loro o qualcun altro hanno dovuto tornare indietro e correggere l'errore. Questo succede sempre; quanto grande dovrebbe essere l'accordo dipende da quanto fosse facile la correzione, se l'errore indica che la persona non ha nemmeno compilato o eseguito il codice in questione e la cultura aziendale complessiva. La cosa importante in tutto è che qualcosa viene appreso dalla persona che ha commesso l'errore; se la build si interrompe più volte a causa dello stesso ragazzo, c'è un problema più profondo con quella persona che deve essere risolto. Le build che si rompono continuamente indicano un problema con la comunicazione del team o la conoscenza del processo.

Sì. Chiedi alla persona di rivedere la correzione apportata al codice. A volte ho scoperto che il bug di qualcun altro era in realtà una parte complicata del codice con alcune altre conseguenze invisibili se il bug fosse semplicemente corretto.

Ci sono molti fattori in gioco.

• Quanto è grave il bug?
• Qual è la relazione di anzianità tra te e l'interruttore?
• Quanto è impegnata / stressata la squadra?
• L'interruttore funzionava nella loro parte della base di codice o nella tua?
• Quanto sei sicuro che fosse un vero bug e quanto sei sicuro che la tua correzione sia corretta?

Se il problema era minore - un errore di battitura / typo / cut & paste - e l'interruttore è un peer impegnato e sei sicuro della tua valutazione del problema, probabilmente non devi portarlo alla loro attenzione. (ad es foo.x = bar.x; foo.y = bar.y, foo.z = bar.y.).

Nella maggior parte degli altri casi, è una buona idea menzionare il problema. In casi non gravi, non è necessario interrompere ciò che stanno facendo; aspettare e farlo a pranzo o quando ci si imbatte in una stanza di riposo.

Se la natura dell'errore indica un grave fraintendimento (della piattaforma di implementazione, delle politiche locali o delle specifiche del progetto), tuttavia, segnalalo al più presto.

Se non sei sicuro della tua valutazione, chiedi loro di rivedere la tua correzione, soprattutto se non è nel codice con cui hai molta familiarità. (Consiglio vivamente al tuo team di sviluppo di adottare una politica di "code buddy" in cui tutte le modifiche sono riviste da un'altra persona prima del check-in, comunque.)

Cosa succede se non glielo dici?

I contro

Possono fare lo stesso errore in altri luoghi perché non capiscono che sta causando un problema. Non solo, ma ci sarà tempo extra inutile per correggere ripetutamente lo stesso errore. Non puoi imparare dagli errori che non sei consapevole di avere.

Secondo, pensano di fare un lavoro migliore di quello che sono. Quando le persone non sono rese consapevoli dei loro problemi, difficilmente possono essere incolpate di pensare che stanno andando bene quando non lo sono. Anche quando il problema è un errore negligente, le persone ne fanno meno quando sono consapevoli che gli errori vengono notati.

Successivamente, se qualcuno non cerca chi lo ha fatto, come fai a sapere se hai un particolare dipendente problematico che è sempre negligente o ha dei malintesi di base sul prodotto? Una persona responsabile vorrebbe che continuasse in una squadra alla quale è associata?

Se risolvi e vai avanti senza discuterne, sei sicuro di averlo corretto? A volte sono i test che devono cambiare quando cambia un requisito. Se si tratta di qualcosa di diverso da un errore di battitura piuttosto secondario, puoi davvero essere sicuro che uno di voi abbia la soluzione corretta? Potresti rompere il suo codice in cambio senza consultare.

I pro

Le persone non si imbarazzano o si arrabbiano con te per aver sottolineato i loro errori.

Immagino di scendere fortemente dal lato di dirglielo, ma di farlo in modo gentile e riservato. Non c'è bisogno di umiliazione pubblica. Se la persona commette ripetutamente gli stessi errori o commette errori critici che mostrano una mancanza di comprensione, anche il supervisore deve essere informato.