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

Se ti avvicini a loro per dire loro di un errore che hanno fatto allora, a meno che tu non sia il miglior diplomatico del mondo, sarà difficile per lui non solo sembrare "Ha! - guarda questo errore che hai fatto!" . Siamo tutti umani e la critica è difficile da prendere.

D'altro canto, a meno che il cambiamento sia completamente banale e ovviamente sbagliato, di solito trovo che sia utile parlare con la persona che ha commesso il cambiamento originale come parte della mia indagine solo per assicurarmi di capire che cosa sta succedendo, quindi il modo in cui finisco di solito a gestire queste situazioni è andare a detta persona e avere una conversazione che va un po 'così:

Me: I'm working on this bug where ... summary of bug ... and I think I've tracked down the problem to a change you made. Can you remember what this change was for? / have you got some time to explain this change?

Quindi:

Them: Sure, thats to handle ... situation I wasn't aware of ...

O qualcosa sulla falsariga di:

Them: Nope sorry I don't remember, looks wrong to me.

Andando e indagando sul cambiamento / bug insieme, il committer originale apprende dai propri errori senza sentirsi criticato *, e ci sono anche buone probabilità che impari anche qualcosa.

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

* Naturalmente funzionerà solo se sei veramente interessato all'aiuto di altre persone. Se stai usando questo metodo sottilmente camuffato per dire a qualcuno di un errore che hanno commesso, probabilmente è peggio che essere semplicemente aperto su di esso.

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

Ancora meglio, se riesci a pensare a una soluzione, risolvila e invia a loro - supponendo che tu abbia un sistema di controllo della versione distribuito. Quindi chiedi loro se la tua correzione è valida per il bug che stavano riparando. Nel complesso, cerca di aumentare sia la tua conoscenza che la tua conoscenza della programmazione. Ma fallo senza che il tuo ego si intrometta.

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

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

Lasciandoli a conoscenza degli errori commessi li aiuterà a diventare un programmatore migliore e a ridurre le possibilità di commettere errori in futuro. MA è educato e non ne fa un grosso problema, creiamo bug ogni tanto. Trovo che una gentile email sia un modo non conflittuale di far sapere alle persone.

Il modo costruttivo è trovare il bug, correggerlo e intraprendere azioni per evitare che simili bug si presentino 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 di aver fatto un errore: ha organizzato un incontro con l'intero team in cui ha spiegato che è stato commesso un errore e che un nuovo processo è stato definito in per sopprimere questo tipo di errori. In questo modo, nessuno è stato stigmatizzato.

In generale, sì .

Nessuno dovrebbe mettersi sulla difensiva se ne hai tatto. Un modo semplice per gestirli è chiedergli di ricontrollare le modifiche prima di reinserirle nel bagagliaio (o qualunque cosa sia rilevante per il proprio sistema di controllo delle versioni). La gente lo apprezzerà se li salvi qualche minuto correggendo errori evidenti, ma non lo apprezzeranno se aggiusti qualcosa che non è stato rotto e finiscono per infrangere il loro codice. Dare loro la possibilità di rivedere le tue modifiche dice loro che non vuoi fare un passo avanti e dare loro l'opportunità di opporsi alle tue modifiche.

Se si tratta di un grosso cambiamento piuttosto che di un errore di battitura, è una buona idea dare un commento all'autore prima di provare a risolverlo. "Joe, stavo unendo le mie cose ieri e ho trovato qualcosa che non sono sicuro di capire, sembra un bug, ma volevo eseguirlo da te prima di andare a pasticciare con il tuo codice. me? "

Il tuo rapporto con l'autore è un fattore importante. Se non ti dispiacerebbe che l'autore fissasse il tuo codice senza dirlo, e se sei abbastanza sicuro che il sentimento è reciproco, allora potrebbe non valere la pena di menzionarlo. Se si tratta di qualcuno con più esperienza / anzianità / stato, vorrete far sapere loro che cambierete 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 metterlo in imbarazzo inutilmente.

Ricorda sempre che se riesci a scoprire chi ha registrato il "bug", possono facilmente scoprire chi ha "corretto" il loro codice. Se pensi che sarebbero turbati / infastiditi / imbarazzati a scoprire il tuo cambiamento dopo il fatto, a tutti i costi dirlo in anticipo.

Inoltre, correggere il bug non è la tua unica opzione. Puoi sempre segnalare il bug nel tuo tracker di problemi. Il tatto è di nuovo richiesto qui - riportare il bug lo rende più visibile all'intero team, ma dà anche all'autore la possibilità di correggere il proprio errore. La segnalazione è l'opzione migliore se non sei sicuro del modo migliore per risolvere il problema o se non hai 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 codice migliore in futuro.

Qui ottieni risposte eccellenti.

Potrei aggiungere solo una tecnica che ho imparato da un manager una volta in cui avrei commesso un errore.

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

Mi ha accennato con un tono quasi di scusa che sembrava esserci un problema e avrei avuto il tempo di esaminarlo?

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

Penso che ci sia un problema più profondo alla base di questa domanda. Sì, il mittente dovrebbe essere messo al corrente delle conseguenze del cambiamento, in modo che possano capire cosa è successo e non ripetere la stessa cosa. Tuttavia, il contesto della tua domanda indica che tu hai preparato e inviato una correzione senza che il mittente originale fosse a conoscenza del fatto che causavano persino 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 descritta potrebbe indicare una mancanza di responsabilità o vigilanza da parte del mittente originario, che è una potenziale preoccupazione per quanto riguarda le prestazioni e la motivazione complessiva.

La mia esperienza nell'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, compreso l'essere consapevoli del loro impatto, anche sul sistema di compilazione e (ovviamente) 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 dovrebbero essere responsabili e coinvolti nel correggere ciò che è andato storto. Anche se non sono "in colpa", ad es. il loro codice ha esposto un bug sottostante che è esistito nella base di codice per anni, dovrebbero essere una delle prime persone a essere consapevoli di un problema con il loro cambiamento. Anche se il mittente originale non è la persona giusta per correggere il bug, dovrebbe essere strettamente connesso al ciclo di vita del loro cambiamento.

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

Ma aggiungere qualcosa di diverso: la tua premessa è imperfetta.

A co-worker made a commit that didn't break CI, but lead you to discover a problem.

Congratulazioni! Hai trovato un nuovo bug, non una regressione. Seriamente, testerai manualmente ogni scenario e linea di codice non coperti da test automatici (o standardizzati manuali) quando esegui il commit?

Con tutti i mezzi, coinvolgere il collega nella correzione, con test per assicurarsi che non possa ripetersi. Sei entrambi degli eroi! Ma se ti lasci scappare la colpa o la parola, 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 sufficiente copertura di test). Spero che non sei stato tu!

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

Diglielo quando è solo per voi due.

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

Quindi non dovresti esitare a dire che qualcuno ha fatto un errore. È normale. Ognuno fa errori, anche i migliori! Solo quelli che non fanno niente non fanno errori;)

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

Perché non vedo qui una sola risposta che rifletta il commento votato in cima alla domanda ??

Sì, diglielo assolutamente, ma non farlo davanti all'intero team

Avvicinati allo sviluppatore 1: 1 e indica il bug. Non fare un grosso problema. Ho sempre pensato che segnalare l'errore di fronte a tutta la 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 ad un certo punto o in un altro, e come la seconda risposta votata in alto dice, si impara dai propri errori

Di solito trovo che funzioni meglio quando inizi con un complimento e poi arrivi all'errore ... qualcosa come "la correzione che hai implementato funziona alla grande, MA sembra che abbia rotto x, y, z", o "grazie per fare a, b, c, MA sembra che causi 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 tutto ciò che era presente nel repository SVN fosse valido e che il codice funzionasse in ogni momento. Quando qualcosa è stato commesso, il nostro server TeamCity ha ottenuto una copia, compilato ed eseguito test unitari. Inoltre ha eseguito i test di integrazione ogni ora. Se qualcosa è stato commesso che ha causato il fallimento dell'elemento della configurazione, tutti hanno ricevuto un'e-mail in cui si afferma che la build si era interrotta in base a un commit da parte di una determinata persona.

Questo non ha sempre catturato tutto; guai a noi, non abbiamo applicato la copertura del codice, e anche se qualcosa fosse coperto da test di unità o integrazione, non potevano esercitare quel codice sufficientemente. Quando ciò accadeva, chiunque avesse il compito di risolvere il problema noto (se il QA lo avesse catturato) o il difetto (se, dun-dun-dun, i clienti lo facessero), 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. Hanno fallito nel fare il loro lavoro correttamente, e loro o qualcun altro hanno dovuto tornare indietro e correggere l'errore. Questo succede sempre; quanto dovrebbe essere grande l'accordo dipende da quanto sia stata 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. Ciò che è importante in tutto è che qualcosa venga appreso dalla persona che ha commesso l'errore; se la costruzione si rompe a causa dello stesso ragazzo più e più volte, c'è un problema più profondo con quella persona che deve essere affrontato. Le build che si interrompono continuamente indicano un problema con la comunicazione o la conoscenza del processo da parte del team.

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

Ci sono molti fattori in gioco.

• Quanto è grave l'errore?
• Qual è la relazione di anzianità tra te e l'interruttore?
• Quanto è occupato / stressato la squadra?
• L'interruttore funzionava nella loro parte del codebase o del tuo?
• Quanto sei certo che sia stato un vero bug e quanto sei certo che la tua correzione sia corretta?

Se il problema era minore - un refuso / thinko / cut & incolla bug - e l'interruttore è un peer occupato, e sei sicuro nella tua valutazione del problema, probabilmente non hai bisogno di portarlo alla loro attenzione. (ad esempio 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; aspetta e fallo durante il pranzo o quando ti imbatti in sala break.

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

Se non sei sicuro della tua valutazione, chiedi loro di rivedere la tua correzione, specialmente se non si tratta di codice con cui hai familiarità. (Consiglio vivamente al team di sviluppo di adottare una politica di "codice amico" in cui tutte le modifiche vengono esaminate da un'altra persona prima del check-in comunque).

Cosa succede se non glielo dici?

I contro

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

In secondo luogo, pensano di fare un lavoro migliore di quello che sono. Quando le persone non vengono rese consapevoli dei loro problemi, difficilmente si può essere accusati di pensare che stanno facendo bene quando non lo sono. Anche quando il problema è un errore incauto, le persone ne fanno meno quando sono consapevoli che gli errori vengono notati.

Quindi, se qualcuno non cerca chi l'ha fatto, come farai a sapere se hai un particolare dipendente problematico che è sempre negligente o ha incomprensioni di base del prodotto? Una persona responsabile vorrebbe che continuasse in una squadra a cui è associato?

Se correggi e vai avanti senza discuterne, sei sicuro, l'hai risolto correttamente? A volte sono i test che devono cambiare quando cambia un requisito. Se è qualcosa di diverso da un errore di battitura abbastanza semplice, puoi essere sicuro che uno di voi abbia la soluzione corretta? Potresti interrompere il suo codice in cambio senza consultare.

I professionisti

Le persone non si sentono imbarazzate o infastidite da te per aver segnalato i loro errori.

Credo di essere venuto giù dal lato del dire loro, ma di farlo bene e in privato. Non c'è bisogno di umiliazione pubblica. Se la persona fa ripetutamente gli stessi errori o commette errori critici che mostrano una mancanza di comprensione, allora anche il supervisore deve essere reso consapevole.