Devo dizer a alguém que o commit deles causou uma regressão?

Se você se aproximar deles para falar sobre um erro que eles cometeram, a menos que você seja o melhor diplomata do mundo, será difícil não soar como "Ha! - olhe para esse erro que você cometeu!" . Somos todos humanos e a crítica é difícil de aceitar.

Por outro lado, a menos que a mudança seja completamente trivial e obviamente errada, eu normalmente acho benigno falar com a pessoa que cometeu a mudança original como parte da minha investigação apenas para ter certeza de que eu entender o que está acontecendo, daí a maneira que eu costumo acabar lidando com essa situação é indo até a dita pessoa e tendo uma conversa que vai um pouco como isto:

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?

Então:

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

Ou algo do tipo:

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

Indo e investigando a mudança / bug juntos, o committer original começa a aprender com seus erros sem apenas sentir que estão sendo criticados *, e há também uma boa chance de você aprender algo também.

Se o committer original não estiver por perto ou estiver ocupado, você pode apenas ler e descobrir tudo sozinho, eu normalmente acho que falar com a pessoa que originalmente fez a mudança é mais rápido.

* É claro que isso só funcionará se você estiver genuinamente interessado na ajuda de outras pessoas. Se você está apenas usando isso como um método mal disfarçado de dizer a alguém sobre um erro que eles cometeram, então isso provavelmente é pior do que ser aberto sobre isso.

Seja assertivo e não agressivo. Sempre favor dizendo algo parecido com "este pedaço de código não está funcionando" vs "seu código não está funcionando". Critique o código, não a pessoa que escreveu o código.

Melhor ainda, se você puder pensar em uma solução, corrija-a e pressione-a - supondo que você tenha um sistema de controle de versão distribuído. Em seguida, pergunte se sua correção é válida para o bug que eles estavam corrigindo. No geral, tente aumentar seu conhecimento e o conhecimento de programação. Mas faça isso sem o seu ego atrapalhando.

É claro que você deve estar disposto a ouvir outros desenvolvedores chegando até você com o mesmo problema e agir como você gostaria que acontecesse.

Sim, sempre . Como programador, é seu trabalho aprender com os erros.

Deixá-los saber os erros que cometem irá ajudá-los a se tornar um melhor codificador e reduzir suas chances de cometer erros no futuro. MAS seja educado e não faça muita coisa, todos nós criamos erros de vez em quando. Acho que um e-mail educado é uma maneira muito não conflituosa de informar as pessoas.

A maneira construtiva é encontrar o bug, consertá-lo e tomar ações para evitar que bugs similares surjam no futuro.

Se envolver explicar às pessoas como não introduzir erros, vá em frente.

Uma vez, trabalhei em uma equipe onde o gerente de projeto nunca disse a um desenvolvedor em particular que ele cometeu um erro: ele organizou uma reunião com toda a equipe, explicando que um erro foi cometido e que um novo processo foi definido. a fim de suprimir esse tipo de erros. Dessa forma, ninguém foi estigmatizado.

Em geral, sim .

Ninguém deve ficar na defensiva se você for diplomático sobre isso. Uma maneira fácil de lidar com isso é pedir que eles verifiquem novamente a alteração antes de enviá-la de volta ao tronco (ou o que for relevante para o sistema de controle de versão). As pessoas vão gostar se você salvá-las por alguns minutos corrigindo erros óbvios, mas eles não vão gostar se você consertar algo que não foi quebrado e acabar quebrando o código deles. Dar a eles a chance de revisar sua alteração diz a eles que você não quer pisar na ponta dos pés e dá a eles a oportunidade de se opor às suas alterações.

Se é uma grande mudança, em vez de apenas um erro de digitação, é uma boa idéia dar ao autor um alerta antes de você tentar corrigi-lo. "Joe, eu estava mesclando minhas próprias coisas ontem e encontrei algo que não tenho certeza se entendi. Parece um bug, mas eu queria passar por você antes de mexer no seu código. Você daria uma olhada com eu? "

Seu relacionamento com o autor é um grande fator. Se você não se importar com o autor consertar seu código sem lhe dizer, e se tiver certeza de que o sentimento é mútuo, talvez não valha a pena mencionar. Se for alguém com mais experiência / senioridade / status, você deverá informar a eles que alterará o código deles. Se é alguém com menos, então considere se é o tipo de coisa que eles precisam ouvir para evitar a repetição do erro ou pode embaraçá-los desnecessariamente.

Lembre-se sempre de que, se você puder descobrir quem registrou o "bug", ele poderá descobrir com facilidade quem "corrigiu" seu código. Se você acha que eles ficariam chateados / chateados / envergonhados em descobrir sua mudança após o fato, por todos os meios, diga-lhes de antemão.

Além disso, corrigir o erro não é sua única opção. Você pode sempre informar o bug no rastreador de problemas. O tato é novamente necessário aqui - reportar o bug torna-o mais visível para toda a equipe, mas também dá ao autor a chance de corrigir seu próprio erro. A geração de relatórios é a melhor opção se você não tiver certeza sobre a melhor maneira de corrigir o problema ou se simplesmente não tiver tempo para corrigi-lo.

Se eu fizer um commit que inclua um bug, é melhor você me dizer. Se eu encontrar um commit seu que inclua um bug, certamente lhe direi.

Nós só melhoramos quando compreendemos nossos erros. É assim que produzimos um código melhor no futuro.

Você está recebendo excelentes respostas aqui.

Eu só pude adicionar uma técnica que aprendi de um gerente quando cometi um erro.

Eu era o consultor de meia-idade com o Ph.D. e ela era a jovem gerente sem, então poderia ter havido um gradiente de prestígio percebido. De qualquer forma, ela claramente tinha experiência com essa situação e sabia como lidar com isso.

Ela mencionou para mim em um tom quase apologético que parecia haver um problema, e eu teria tempo de investigar isso?

Muitas vezes, o erro era meu e ela sabia disso. Isso é habilidade.

Eu acho que há uma questão mais profunda subjacente a esta questão. Sim, o apresentador deve certamente estar ciente das consequências de sua mudança, para que eles possam entender o que aconteceu e não fazer a mesma coisa novamente. No entanto, o contexto da sua pergunta indica que você preparou e enviou uma correção sem o conhecimento do remetente original de que eles causaram um problema. Aí reside a questão mais profunda: por que o apresentador já não sabe sobre a regressão e por que eles não resolveram eles mesmos? A situação que você descreveu pode indicar uma falta de prestação de contas ou vigilância por parte do remetente original, que é uma preocupação potencial em relação ao seu desempenho geral e motivação.

Minha experiência em engenharia de software me ensinou a possuir todas as minhas alterações de código, não apenas os projetos pelos quais sou responsável, até a produção, incluindo o conhecimento de seu impacto, inclusive no sistema de criação e (obviamente) comportamento do produto.

Se a mudança de alguém causou um problema, isso não significa que a pessoa é um mau engenheiro, mas geralmente eles devem ser responsáveis e envolvidos na correção do que deu errado. Mesmo que eles não sejam "culpados", e. seu código expôs um bug subjacente que existe na base de código há anos, ele deve ser uma das primeiras pessoas a ter conhecimento de um problema com sua mudança. Mesmo que o remetente original não seja a pessoa certa para corrigir o bug, ele deve estar intimamente ligado ao ciclo de vida da alteração.

Boa tração na sua pergunta! Todo mundo te disse o que fazer. Você deve dizer? SIM! Sempre que a pergunta perguntar "devo comunicar mais?", A resposta é quase sempre SIM!

Mas para adicionar algo diferente: sua premissa é falha.

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

Parabéns! Você encontrou um novo bug, não uma regressão. Sério, você testa manualmente todos os cenários e linhas de código não cobertos por testes automatizados (ou manuais padronizados) quando você se compromete?

Por todos os meios, envolva seu colega na correção, com testes para garantir que isso não aconteça novamente. Vocês são ambos heróis! Mas se você deixar escapar qualquer culpa na palavra ou ação, você é responsável por perpetuar uma das piores doenças organizacionais: responsabilidade sem responsabilidade.

Se você realmente precisa encontrar um vilão, pense no cara que cometeu o código original que quebrou e deixou uma armadilha para seu amigo desavisado (obviamente sem cobertura de teste suficiente). Espero que não seja você!

Sempre considere a outra pessoa como alguém melhor do que você, sempre veja outras boas características e sempre saiba que posso cometer erros também.

Diga a eles quando são apenas vocês dois.

Se alguém se ofende quando você disse que ele cometeu um erro, isso significa que ele pensa que é o mais sábio do mundo e não se engana, e quando criticado, ele tem a sensação, como dissemos na Polônia, que 'coroa está caindo de sua cabeça '.

Então você não deve hesitar em dizer que alguém cometeu um erro. É normal. Todos cometem erros, mesmo os melhores! Somente aqueles que não fazem nada não cometem erros;)

Além do que os outros disseram, certifique-se de que é realmente o commit que causou um bug. Certamente não culpe alguém pelo seu próprio erro. Não importa o quão diplomático você os aproxime, você ainda vai irritá-los se os culpar por algo que eles não fizeram. (Falando como alguém que tem sido culpado pelos erros de outras pessoas constantemente; uma vez alguém me procurou e disse que eu fiz algo completamente estúpido e eu inventei o registro de commits e descobri que a última pessoa a tocar naquela linha de código era a pessoa que estava me culpando. De alguma forma, ele ainda parecia pensar que foi minha culpa, porque eu tinha escrito a linha originalmente.)

Por que não vejo aqui uma única resposta que reflita o melhor comentário votado sobre a questão ??

Sim, diga a eles, mas não faça isso na frente de toda a equipe

Aproxime-se do desenvolvedor 1: 1 e aponte o bug. Não faça muita coisa disso. Eu sempre achei que apontar o erro na frente de toda a equipe era uma má ideia. Pode funcionar para alguns desenvolvedores, mas não é para todos e pode ter um efeito negativo. Lembre-se, todos nós estivemos no lugar deles em algum momento ou outro, e como a segunda resposta votada diz, você aprende com seus erros

Eu costumo encontrá-lo funciona melhor quando você começar com um elogio e, em seguida, chegar ao erro ... algo como "a correção que você implementou funciona muito bem, mas parece ter quebrado x, y, z" ou "obrigado para fazer a, b, c, mas parece estar causando x, y, z "

Resposta simples: sim.

Resposta mais longa: Meu último trabalho foi em uma empresa Agile que usava o TDD com ferramentas de CI para garantir que o que estava em nosso repositório do SVN fosse bom, código de trabalho em todos os momentos. Quando algo foi confirmado, nosso servidor TeamCity recebeu uma cópia, compilou e executou testes de unidade. Ele também executou testes de integração por hora. Se algo foi cometido que causou a falha do IC, todo mundo recebeu um e-mail afirmando que o build tinha quebrado baseado em um commit de uma pessoa em particular.

Isso nem sempre pega tudo; ai de nós, nós não reforçamos a cobertura de código, e mesmo se algo fosse coberto por testes unitários ou de integração, eles não poderiam exercitar esse código o suficiente. Quando isso aconteceu, quem quer que tenha a tarefa de corrigir o problema conhecido (se o controle de qualidade pegou) ou defeito (se, dun-dun-dun, os clientes o fizeram), iria correr uma "culpa" (mostra quem modificou cada linha de um arquivo de código) e determinar o culpado.

Chamar alguém para checar código quebrado não é necessariamente uma coisa ruim. Eles não conseguiram fazer o trabalho corretamente, e eles ou outra pessoa tiveram que voltar e consertar o erro. Isso acontece o tempo todo; O tamanho do negócio deve depender de quão fácil foi a correção, se o erro indica que a pessoa nem mesmo compilou ou executou o código em questão e a cultura corporativa geral. O importante na coisa toda é que algo é aprendido pela pessoa que cometeu o erro; se a build quebrar devido ao mesmo cara várias vezes, há uma questão mais profunda com essa pessoa que deve ser abordada. Construções quebrando o tempo todo indicam um problema com a comunicação ou conhecimento da equipe sobre o processo.

Sim. Peça à pessoa para revisar a correção que você fez no código. Às vezes, descobri que o erro de outra pessoa era, na verdade, uma parte complicada do código, com algumas outras conseqüências ocultas, se o erro fosse corrigido.

Existem muitos fatores em jogo.

• Quão severo é o bug?
• Qual é a relação de antiguidade entre você e o infrator?
• Quão ocupado / estressado está o time?
• O separador estava funcionando em sua parte da base de código ou na sua?
• Qual a sua certeza de que se tratava de um problema real e como você está certo de que sua correção está correta?

Se o problema foi menor - um erro de digitação / thinko / cut & Cole o bug - e o disjuntor é um colega ocupado, e você está confiante em sua avaliação do problema, você provavelmente não precisa chamar a atenção deles. (por exemplo, foo.x = bar.x; foo.y = bar.y, foo.z = bar.y ).

Na maioria dos outros casos, é uma boa ideia mencionar o problema. Em casos não graves, você não precisa interromper o que eles estão fazendo; espere e faça durante o almoço ou quando correr para eles na sala de descanso.

Se a natureza do erro indicar um sério desentendimento (da plataforma de implementação, as políticas locais ou a especificação do projeto), abra-o o mais rápido possível.

Se você não tiver certeza da sua avaliação, peça a eles que revisem sua correção, especialmente se ela não estiver no código com o qual você está familiarizado. (Eu recomendo vivamente que a sua equipa de desenvolvimento adopte uma política de 'code buddy' onde todas as alterações são revistas por uma outra pessoa antes do checkin, de qualquer forma.)

O que acontece se você não contar a eles?

Os contras

Eles podem cometer o mesmo erro em outros lugares porque não entendem que isso está causando um problema. Não só isso, mas haverá tempo extra desnecessário para corrigir repetidamente o mesmo erro. Você não pode aprender com os erros que não sabe que tem.

Em seguida, se alguém não procurar quem fez isso, como você saberá se você tem um problema específico de funcionário que é sempre descuidado ou que tem mal-entendidos básicos sobre o produto? Uma pessoa responsável quer que isso continue em uma equipe na qual ele ou ela está associado?

Se você consertar e seguir em frente sem discutir, tem certeza de que o corrigiu corretamente? Às vezes, são testes que precisam ser alterados quando um requisito é alterado. Se for algo diferente de um erro de digitação, você realmente pode ter certeza de que algum de vocês tem a solução correta? Você pode estar quebrando o código dele em troca sem consultar.

Os profissionais

As pessoas não ficam constrangidas ou incomodadas com você por apontar seus erros.

Eu acho que eu venho strongmente ao lado de dizer a eles, mas fazê-lo bem e em particular. Não há necessidade de humilhação pública. Se a pessoa repetidamente cometer os mesmos erros ou cometer erros críticos que demonstrem falta de compreensão, o supervisor também precisa ser informado.