Um programador dedicou algum trabalho ao repositório SVN e depois foi para casa. Depois que ele saiu, o build automático do Hudson falhou. Outro programador viu isso e, depois de examinar as alterações no código, detectou que o problema era a ausência de uma biblioteca. Ele adicionou essa biblioteca ao SVN e a próxima construção foi concluída com sucesso.
O segundo programador fez a coisa certa ou deveria ter esperado o primeiro programador corrigir o problema?
Depende, até certo ponto, de como sua equipe costuma funcionar, mas eu diria que está bem. Manter a construção funcionando economiza tempo a todos.
É educado para o segundo programador deixar o primeiro um e-mail para explicar o que ele fez, caso uma versão específica da biblioteca seja necessária ou haja alguma outra complicação. É também uma maneira um pouco mais sutil de apontar que eles quebraram a compilação.
Depende.
O erro é tão óbvio que adicionar uma biblioteca é a maneira de solucioná-lo? Às vezes, a correção está em encontrar uma solução alternativa para não precisar dessa biblioteca.
O projeto está em uma fase em que todas as alterações devem estar vinculadas a um ticket existente? Em caso afirmativo, você arquivou um ingresso? Esse ticket foi atribuído a você?
De qualquer forma, concentre-se em corrigir o bug, não em culpar o responsável.
Sim, tudo bem. No entanto, não é profissional para o programador original ir para casa antes de testar se a compilação seria compilada.
Sua reputação é 100% em seu controle. Coisas como essa mancha sua reputação e tentar polir uma reputação manchada é muito difícil.
Comunique-se
Não há regras rígidas (além das regras da equipe) para esse cenário.
O Dev2 deve ser capaz de dizer ao dev1 que ele pode consertar seu erro, nenhum deles deve temer algo resultante dessa troca, eles são parte de uma equipe.
Por que não? Se o seu produto é mais importante do que consertar as culpas, certamente está tudo bem. Embora uma falha na compilação por causa da mudança de biblioteca seja muito fraca e você precisa repreender o desenvolvedor por não testá-lo.
Construa falhas. Se é importante que uma compilação diária aconteça, eu a consertaria e, em seguida, solicitaria ao desenvolvedor que verificasse o código quebrado para revisar a correção no dia seguinte e garantir que o código esteja agora como deveria.
Como já foi dito, o cara que consertou provavelmente deveria mandar um e-mail para o cara que o quebrou e detalhar qual era a correção.
Meu lema é não se comprometer com o SVN depois das 3 da tarde para que você possa sempre corrigir suas próprias falhas de compilação.
Se você não corrigir sua falha de compilação, a compilação de todos os outros também falhará. Eu iria corrigi-lo para economizar tempo a longo prazo, mas certifique-se de que eles estão cientes de que você tinha que consertá-lo.
Ter algum tipo de script 'apontar o dedo da culpa' é uma boa maneira de fazer isso, ou fazer com que a pessoa que quebra a construção compre rosquinhas !!
Alguém precisa consertar e o primeiro programador não deveria ter ido para casa sem primeiro ter certeza de que ele não havia quebrado a construção. No entanto, para um problema tão facilmente corrigido, chamá-lo de volta para consertá-lo seria extremo.
Concordo com a sugestão de Luke Graham de enviar um e-mail explicativo, embora eu diria que é mais que educado - é comunicação básica.
Sim sim sim! Promove a propriedade de código coletivo e estabelece um tipo de pressão de colegas saudável na equipe para manter um alto padrão e não permitir o desenvolvimento de um cenário de janela quebrada. Um pouco de comunicação para informar ao outro desenvolvedor é uma boa ideia.
Acho que não há problema em consertar coisas óbvias - ou seja, se você tem 100% de certeza de que o cara cujo código você está consertando consiga fazer o mesmo - ou substancialmente o mesmo - consertar. Se a correção é mais complexa, geralmente é educado falar com a pessoa cujo código você está consertando - pode ser que você tenha entendido errado a intenção ou a razão da quebra não seja o que você pensou, ou talvez ele tenha planejado outra correção mas por alguma razão não poderia cometer isso ainda (a vida acontece, você sabe :).
Em geral, a regra geralmente é: você quebra a compilação - você corrige a compilação, mas há exceções, especialmente se a correção for óbvia e / ou a pessoa responsável for inacessível.
Claro, se você tiver o caso do disjuntor de construção serial - especialmente com o padrão "check in, went home, build broken for days" - a pessoa responsável precisa conversar sobre porque os sistemas e testes de CI existem e como se deve verificar antes de fazer o check-in:)
As coisas acontecem. A falha em adicionar um novo arquivo de código (seja fonte ou compilado) ao Subversion é provavelmente a causa mais comum de construções quebradas, assumindo que funcionou no computador do desenvolvedor. No meu último trabalho com um ambiente de IC, até mesmo os caras mais antigos às vezes esqueciam.
Eu acho que, se outra pessoa foi capaz de consertar a construção e, assim, manter o time cantarolando, tudo bem. Eu acho que o programador que foi para casa precisa de pelo menos um e-mail amigável informando o que aconteceu e para lembrá-lo de que o novo código seja adicionado antes dos commits. Se isso acontecer com frequência, talvez torne isso uma ofensa menor, punível com a "dança da vergonha", para ajudar a reduzir ocorrências (e aliviar o clima).
Depende da dinâmica da equipe, mas em um mundo ideal, todos na equipe "possuem" todo o projeto, todo o código e, conseqüentemente, todos os erros em conjunto. Portanto, se você encontrar um problema, conserte-o e comunique-se com o originador do bug somente se houver algum valor agregado específico ao código ao fazê-lo.
Não há problema em consertar, a menos que seja uma ocorrência regular, caso em que eu faria o chefe chamá-lo e fazê-lo retornar e consertar ele mesmo.
Depende, depende ...
Como programadores, nosso trabalho é fazer as coisas funcionarem, não julgar as pessoas. Então, eu diria que a melhor coisa que você pode fazer é consertar isso, ou, se não for óbvio, apenas reverter as mudanças e avisar o primeiro programador para que ele possa consertá-lo mais tarde.
De qualquer forma, ter o último cara que quebrou a construção para usar um chapéu estranho é o suficiente para prestar mais atenção na próxima vez ^ _ ^
Em alguns ambientes, isso é muito rude e por boas razões. Em outros ambientes, é esperado e por boas razões.
Em outros ambientes, é muito rude ou esperado por razões muito ruins.
Depende, em grande parte, da importância de uma compilação quebrada em relação à importância de uma compilação correta verificada. E, até certo ponto, depende de como era óbvio que a correção era a correção certa e a única necessária.
Primeiro, "foi para casa" é um anacronismo. Os programadores não vão mais para casa - são apenas online ou offline. Você poderia fazer ping e esperar.
Mais seriamente, na verdade existem duas partes para a questão. 'olhando através das mudanças de código' está bem; o descanso pode não ser a coisa certa a fazer. E se o julgamento de uma biblioteca desaparecida estivesse errado?