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

Quando você rastreia e corrige uma regressão - ou seja, um bug que fez o código que estava funcionando anteriormente parar de funcionar - o controle de versão torna totalmente possível procurar quem cometeu a alteração que a interrompeu.

Vale a pena fazer isso? É construtivo apontar isso para a pessoa que fez o commit? A natureza do erro (na escala da simples falta de atenção ao mal-entendido fundamental do código que eles mudaram) muda se é ou não uma boa idéia?

Se é uma boa idéia contar a eles, quais são as boas maneiras de fazer isso sem causar ofensas ou ficar na defensiva?

Suponha, por uma questão de argumento, que o bug seja suficientemente sutil que os testes automatizados do servidor de IC não possam detectá-lo.

Se você apenas abordá-los para contar a eles sobre um erro que eles cometeram, a menos que você seja o melhor diplomata do mundo, será difícil não soar como "Ha! - veja esse erro que você cometeu!". Somos todos humanos e as críticas são difíceis de aceitar.

Por outro lado, a menos que a mudança seja completamente trivial e obviamente errada, normalmente acho benéfico conversar com a pessoa que cometeu a alteração original como parte de minha investigação, apenas para ter certeza de que entendo completamente o que está acontecendo, daí o modo como costumo acabar lidando com essa situação é ir até a pessoa em questão e ter uma conversa mais ou menos assim:

Eu: Estou trabalhando nesse bug em que ... resumo do bug ... e acho que rastreei o problema para uma alteração que você fez. Você consegue se lembrar para que foi essa mudança? / você tem algum tempo para explicar essa mudança?

Qualquer então:

Eles: Claro, isso é para lidar com ... situação da qual eu não estava ciente ...

Ou algo parecido com:

Eles: Não, desculpe, eu não me lembro, parece errado para mim.

Ao investigar juntos a mudança / bug, o comunicador original aprende com seus erros sem sentir que está sendo criticado *, e também há uma boa chance de você aprender algo também.

Se o responsável pelo envio original não estiver por perto ou ocupado, você poderá apenas descobrir e descobrir tudo sozinho, normalmente acho que conversar com a pessoa que originalmente fez a alteração é mais rápido.

* É claro que isso só funcionará se você estiver realmente interessado na ajuda de outras pessoas. Se você está apenas usando isso como um método pouco disfarçado de contar a alguém sobre um erro que cometeu, isso provavelmente é pior do que apenas ser aberto sobre isso.

Seja assertivo, não agressivo. Sempre prefira dizer 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 envie-a para eles - supondo que você tenha um sistema de controle de versão distribuído. Em seguida, pergunte a eles se sua correção é válida para o bug que eles estavam corrigindo. No geral, tente aumentar o seu conhecimento e o conhecimento de programação. Mas faça isso sem que seu ego atrapalhe.

Obviamente, você deve estar disposto a ouvir outros desenvolvedores chegando com o mesmo problema e agir como você gostaria que eles fizessem.

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

Informar os erros que eles cometem os ajudará a se tornar um codificador melhor e reduzirá suas chances de cometer erros no futuro. Mas seja educado e não faça muita coisa, todos nós criamos bugs de vez em quando. Acho que um e-mail educado é uma maneira muito clara de informar as pessoas.

A maneira construtiva é encontrar o bug, corrigi-lo e executar ações para evitar erros semelhantes que possam surgir no futuro.

Se envolver explicar às pessoas como não introduzir bugs, siga em frente.

Uma vez, trabalhei em uma equipe em que 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, onde explicou que um erro foi cometido e que um novo processo foi definido para suprimir esse tipo de erro. Dessa forma, ninguém foi estigmatizado.

Em geral, sim .

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

Se for uma grande mudança, e não apenas um erro de digitação, é uma boa ideia avisar o autor antes de tentar corrigi-lo. "Joe, eu estava fundindo minhas próprias coisas ontem e encontrei algo que não tenho certeza de entender. Parece um bug, mas eu queria executá-lo antes de mexer no seu código. Dê uma olhada no mim?"

Seu relacionamento com o autor é um grande fator. Se você não se importaria que o autor corrigisse seu código sem avisar, 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 / antiguidade / status, convém que eles saibam que você vai mudar o código deles. Se é alguém com menos, pense se é o tipo de coisa que eles precisam ouvir para evitar repetir o erro ou isso pode constrangê-los desnecessariamente.

Lembre-se sempre de que, se você descobrir quem fez o check-in do "bug", eles poderão descobrir com facilidade quem "corrigiu" seu código. Se você acha que eles ficariam chateados / aborrecidos / envergonhados ao descobrir sua mudança depois do fato, conte-os com antecedência.

Além disso, a correção do bug não é sua única opção. Você sempre pode apenas relatar o bug no rastreador de problemas. O tato é novamente necessário aqui - relatar o erro o torna mais visível para toda a equipe, mas também dá ao autor a chance de corrigir seu próprio erro. Os relatórios são a melhor opção se você não tiver certeza da melhor maneira de corrigir o problema ou se 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 vou lhe dizer.

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

Você está recebendo excelentes respostas aqui.

Eu só podia adicionar uma técnica que aprendi com um gerente uma vez quando cometeria um erro.

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

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

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

Eu acho que há uma questão mais profunda subjacente a essa pergunta. Sim, o remetente certamente deve estar ciente das consequências de suas alterações, 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 até causaram um problema. Aí reside a questão mais profunda: por que o remetente já não sabe sobre a regressão e por que eles próprios não a corrigiram? A situação que você descreveu pode indicar uma falta de responsabilidade ou vigilância por parte do remetente original, o que é uma preocupação potencial em relação ao desempenho e motivação gerais.

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, o que inclui estar ciente de seu impacto, inclusive no sistema de construção e (obviamente) no 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 ela deve ser responsável e envolvida na correção do que deu errado. Mesmo que não sejam "culpados", por exemplo, seu código expôs um bug subjacente que existe na base de código há anos, eles devem ser uma das primeiras pessoas a estar cientes de um problema com sua alteração. Mesmo que o remetente original não seja a pessoa certa para corrigir o bug, ele deve estar intimamente conectado ao ciclo de vida de suas alterações.

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

Mas, para acrescentar algo diferente: sua premissa é falha.

Um colega de trabalho fez um commit que não quebrou o IC, mas levou você a descobrir um problema.

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 que não são cobertos por testes automatizados (ou manuais padronizados) ao confirmar?

De qualquer maneira, envolva seu colega na correção, com testes para garantir que isso não ocorra novamente. Vocês dois são heróis! Mas se você deixar escapar qualquer culpa em palavras ou ações, será responsável por perpetuar uma das piores doenças organizacionais: prestação de contas 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 tenha sido você!

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

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

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

Portanto, você não deve hesitar em dizer que alguém cometeu um erro. É normal. Todo mundo comete erros, até os melhores! Somente aqueles que não fazem nada não cometem erros;)

Além do que os outros disseram, verifique se realmente é o commit deles que causou um bug. Certamente não culpe alguém por seu próprio erro. Não importa o quanto você os aborda com tato, você ainda os irritará se os culpar por algo que eles não fizeram. (Falando como alguém que tem sido culpado constantemente pelos erros de outras pessoas; uma vez alguém veio até mim e disse que eu fiz algo totalmente estúpido, levantei o log de confirmação e descobri que a última pessoa a tocar nessa linha de código era a pessoa que estava me culpando. De alguma forma, ele ainda parecia pensar que era minha culpa porque eu escrevi a linha originalmente.)

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

Sim, conte-lhes absolutamente, mas não faça isso na frente de toda a equipe

Aproxime o desenvolvedor 1: 1 e aponte o erro. Não faça muito disso. Eu sempre pensei 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 já estivemos no lugar deles em algum momento ou outro e, como diz a segunda resposta mais votada, você aprende com seus erros

Normalmente, acho que funciona melhor quando você começa com um elogio e depois chega ao erro ... algo como "a correção que você implementou funciona muito bem, mas parece ter quebrado x, y, z" ou "obrigado por fazer um , 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 TDD com ferramentas de CI para garantir que o que estava em nosso repositório SVN fosse bom, código de funcionamento o tempo todo. Quando algo foi confirmado, nosso servidor TeamCity conseguiu uma cópia, compilou e executou testes de unidade. Também executava testes de integração a cada hora. Se algo foi confirmado que causou a falha do IC, todos receberam um email informando que a compilação havia sido quebrada com base em uma confirmação por uma pessoa específica.

Isso nem sempre pegou tudo; ai de nós, não aplicamos a cobertura do código e, mesmo que algo tenha sido coberto por testes de unidade ou integração, eles podem não exercer esse código suficientemente. Quando isso acontecia, quem quer que tenha a tarefa de corrigir o problema conhecido (se o controle de qualidade detectar) ou o defeito (se, dun-dun-dun, os clientes o fizerem), executará uma "culpa" (mostra quem modificou pela última vez cada linha de um arquivo de código) e determine o culpado.

Chamar alguém para verificar o código quebrado não é necessariamente uma coisa ruim. Eles falharam em fazer seu trabalho corretamente, e eles ou outra pessoa tiveram que voltar e corrigir o erro. Isso acontece o tempo todo; quão grande deve ser o negócio depende de quão fácil foi a correção, se o erro indica que a pessoa nem sequer compilou ou executou o código em questão e a cultura corporativa geral. O importante é que algo é aprendido pela pessoa que cometeu o erro; se a construção for interrompida devido ao mesmo cara repetidamente, há um problema mais profundo com essa pessoa que deve ser resolvido. Construções que quebram o tempo todo indicam um problema com a comunicação ou o conhecimento do processo pela equipe.

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

Existem muitos fatores em jogo.

• Quão grave é o bug?
• Qual é a relação de antiguidade entre você e o disjuntor?
• Quão ocupada / estressada é a equipe?
• O disjuntor estava trabalhando na parte deles da base de código ou na sua?
• Qual é a sua certeza de que foi um bug real e qual a sua correção?

Se o problema foi menor - um erro de digitação / thinko / recortar e colar - e o disjuntor é um colega ocupado, e você está confiante em sua avaliação do problema, 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-o durante o almoço ou ao encontrá-los na sala de descanso.

Porém, se a natureza do erro indicar um mal-entendido (da plataforma de implementação, das políticas locais ou das especificações do projeto), faça-o aparecer o mais rápido possível.

Se você não tiver certeza de sua avaliação, peça para que eles revisem sua correção, especialmente se não estiver no código com o qual você está muito familiarizado. (Eu recomendo fortemente que sua equipe de desenvolvimento adote uma política de 'parceiro de código' em que todas as alterações sejam revisadas por outra pessoa antes do check-in, de qualquer maneira.)

O que acontece se você não lhes contar?

Os contras

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

Segundo, eles acham que estão fazendo um trabalho melhor do que estão. Quando as pessoas não são conscientizadas de seus problemas, dificilmente podem ser responsabilizadas por pensar que estão indo bem quando não estão. Mesmo quando o problema é um erro descuidado, as pessoas cometem menos quando estão cientes de que os erros são percebidos.

Em seguida, se alguém não procurar quem fez isso, como você saberá se você tem um funcionário com problemas específicos que é sempre descuidado ou tem mal-entendidos básicos sobre o produto? Uma pessoa responsável gostaria que isso continuasse em uma equipe à qual ele está associado?

Se você conserta e segue em frente sem discutir, tem certeza, você o corrigiu corretamente? Às vezes, são os testes que precisam mudar quando um requisito é alterado. Se for algo diferente de um erro de digitação bastante pequeno, você pode realmente ter certeza de que um dos dois tem a solução correta? Você pode estar quebrando o código dele em troca sem consultar.

Os prós

As pessoas não ficam envergonhadas ou irritadas com você por apontar seus erros.

Eu acho que me apaixono muito por contar a eles, mas fazendo isso de maneira agradável e particular. Não há necessidade de humilhação pública. Se a pessoa cometer repetidamente os mesmos erros ou cometer erros críticos que demonstram falta de entendimento, o supervisor também precisará ser informado.