Um programador deve consertar a construção com falha de outra pessoa? [fechadas]

45

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?

    
por nahab 09.11.2011 / 11:53
fonte

16 respostas

87

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.

    
por 08.11.2011 / 10:48
fonte
12

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.

    
por 08.11.2011 / 10:52
fonte
11

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.

    
por 08.11.2011 / 14:40
fonte
7

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 08.11.2011 / 14:42
fonte
5

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.

    
por 08.11.2011 / 11:03
fonte
3

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.

    
por 08.11.2011 / 18:01
fonte
2

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 !!

    
por 08.11.2011 / 10:45
fonte
2

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.

    
por 08.11.2011 / 11:41
fonte
2

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.

    
por 08.11.2011 / 21:35
fonte
2

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:)

    
por 08.11.2011 / 21:47
fonte
1

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).

    
por 08.11.2011 / 15:16
fonte
1

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.

    
por 09.11.2011 / 03:01
fonte
0

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.

    
por 08.11.2011 / 15:24
fonte
0

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 ^ _ ^

    
por 08.11.2011 / 17:21
fonte
0

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.

    
por 09.11.2011 / 06:08
fonte
0

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?

    
por 09.11.2011 / 11:49
fonte