Um programador deve corrigir a compilação falhada de outra pessoa? [fechadas]

Um programador dedicou algum trabalho ao repositório SVN e depois foi para casa. Depois que ele saiu, a construção automática 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 compilação foi concluída com êxito.

O segundo programador fez a coisa certa ou deveria ter esperado até o primeiro programador resolver o problema?

Depende até certo ponto de como sua equipe geralmente funciona, mas eu diria que tudo bem. Manter a construção funcionando economiza tempo para todos os outros.

É educado que o segundo programador envie o primeiro e-mail para explicar o que ele fez, apenas no caso de uma versão específica da biblioteca ser necessária ou se houver alguma outra complicação. É também uma maneira um pouco mais sutil de ressaltar que eles haviam quebrado a compilação.

Depende.

• O bug é tão óbvio que adicionar uma biblioteca é a maneira de corrigi-lo? Às vezes, a solução é 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ê registrou um ticket? Esse ticket foi atribuído a você?

Enfim, concentre-se em corrigir o erro, não em culpar o responsável.

Sim está tudo bem. No entanto, não é profissional para o programador original voltar para casa antes de testar se a compilação seria compilada.

Sua reputação está 100% sob seu controle. Coisas assim mancham sua reputação e tentar polir uma reputação manchada é muito difícil.

Comunicar

Não há regras estritas (além das regras da sua equipe) para esse cenário.

O Dev2 deve ser capaz de dizer ao dev1 que ele pode corrigir seu erro, nenhum deles deve temer algo resultante dessa troca, eles fazem parte de uma equipe.

Por que não? Se seu produto é mais importante do que culpar, certamente está tudo certo. Embora uma construção falhe por causa da alteração da biblioteca, ela é muito ruim e você precisa repreender o desenvolvedor por não testá-la.

Falhas de compilação acontecem. Se for importante que uma compilação diária aconteça, eu a corrigirei e solicitaria que o desenvolvedor que fez o check-in do código quebrado revise a correção no dia seguinte e garanta que o código esteja agora como deveria.

Como já foi dito, o cara que o corrigiu provavelmente deve enviar um e-mail para o cara que quebrou e detalhar qual foi a correção.

Meu lema é não se comprometer com o SVN depois das 15h, dessa forma, você sempre pode corrigir suas próprias falhas de compilação.

Se você não corrigir a falha de construção dele, a construção de todos os outros também falhará. Eu o corrigia para economizar tempo a longo prazo, mas verifique se eles estão cientes de que você precisava corrigi-lo.

Ter algum tipo de script 'apontar o dedo da culpa' é uma boa maneira de fazer isso, ou fazer a pessoa que quebra a construção comprar donuts!

Alguém precisa corrigi-lo e o primeiro programador não deveria ter ido para casa sem antes se certificar de que não havia quebrado a compilação. No entanto, para um problema tão facilmente resolvido, 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 do que educado - é uma comunicação básica.

Sim Sim Sim! Ele promove a propriedade coletiva do código e define um tipo de pressão saudável dos colegas na equipe para manter um alto padrão e não permitir que um cenário de janela quebrada se desenvolva. Um pouco de comunicação para informar o outro desenvolvedor é uma boa ideia.

Acho que não há problema em corrigir coisas óbvias - ou seja, se você tiver 100% de certeza de que o cara cujo código você está corrigindo faria a mesma - ou substancialmente a mesma - correção. Se a correção é mais complexa, geralmente é educado conversar com a pessoa cujo código você está corrigindo - pode ser que você tenha entendido mal a intenção ou o motivo da quebra não seja o que você pensava, ou talvez ele tenha pretendido outra correção. mas por alguma razão ainda não consegui cometer (a vida acontece, você sabe :).

Em geral, a regra geralmente é: você interrompe 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 estiver inacessível.

Obviamente, se você tiver o caso de um disjuntor de compilação em série - especialmente com o padrão "registrado, foi para casa, compilado por dias" - a pessoa responsável precisa conversar um pouco sobre por que os sistemas e testes de CI existem e como deve ser feito. verifique antes de fazer o check-in :)

Coisas acontecem. A falha em adicionar um novo arquivo de código (de origem ou compilado) ao Subversion é provavelmente a causa mais comum de compilações interrompidas, assumindo que funcionou no computador do desenvolvedor. No meu último emprego em um ambiente de IC, até os mais veteranos às vezes se esqueciam.

Eu acho que, se outra pessoa foi capaz de consertar a construção e, assim, manter a equipe 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 lembrá-lo de que o novo código seja adicionado antes da confirmação. Se isso acontecer com frequência, talvez torne uma ofensa menor punível com a "dança da vergonha", para ajudar a reduzir as ocorrências (e aliviar o clima).

Depende da dinâmica da equipe, mas em um mundo ideal, todos na equipe "possuiriam" todo o projeto, todo o código e, conseqüentemente, todos os erros juntos. Portanto, se você encontrar um problema, corrija-o e comunique-se com o criador do bug apenas se houver algum valor agregado específico no código ao fazê-lo.

Não há problema em consertar, a menos que seja uma ocorrência regular. Nesse caso, eu faria o chefe ligar para ele e fazê-lo voltar 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 é corrigi-lo ou, se não for óbvio, reverta as alterações e informe o primeiro programador para que ele possa corrigi-lo mais tarde.

Enfim, ter o cara mais novo que quebrou a construção para usar um chapéu estranho é 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.

Ainda em outros ambientes, é muito rude ou esperado por razões muito ruins.

Depende em grande parte da importância de uma construção quebrada e da importância de uma construção correta verificada. E, até certo ponto, depende de quão óbvio era que a correção era a correta e a única necessária.

Primeiro, 'fui para casa' é um anacronismo. Os programadores não voltam mais para casa - eles estão online ou offline. Você pode executar ping e esperar.

Mais seriamente, existem duas partes na questão. 'olhar através das alterações de código' é bom; descanso pode não ser a coisa certa a fazer. E se seu julgamento de uma biblioteca perdida estivesse errado?