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

45

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?

teamwork continuous-integration

— nahab
fonte

31

Pergunta: Um membro do programador fez uma pergunta. Outro membro leu a pergunta e viu alguns erros sintáticos e gramaticais. Por isso, decidiu editá-la e corrigi-la, para facilitar a leitura. O que o editor fez de certo ou deveria ter acabado de esperar o pôster corrigir os erros?

— yannis

2

Quais são as regras da sua equipe para essa situação?

4

@nahab Oh, não se preocupe, não estou dizendo que é um problema :). Só que em uma comunidade, como em uma equipe, os membros que se ajudam devem ser incentivados. Também não acho que um desenvolvedor que esteja quebrando uma compilação não seja profissional, mesmo que por um pequeno erro, essas coisas aconteçam para o melhor de nós.

— yannis

11

Toda a idéia de ter Hudson em primeiro lugar é porque os seres humanos são humanos e vão quebrar a construção de vez em quando. Você só quer pegá-lo cedo. Pode-se argumentar que o programador em questão deveria ter verificado que a compilação foi criada antes de voltar para casa.

14

Isso é muito mais fácil de entender se você considerar o contrário - se a compilação for interrompida, diminuindo a velocidade de toda a equipe (mesmo em casa, depois do expediente) e você poderá corrigi-la, mas faça uma escolha deliberada, não devido a algum ponto do procedimento , você deve ter permissão para manter seu emprego?

— Bill K

87

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.

— Luke Graham
fonte

101

também é educado o primeiro desenvolvedor a comprar rosquinhas para compensar a quebra do build

— jk.

17

Eu gostaria de cerveja ao invés de donuts.

— Martin York

2

Os donuts podem ser ofensivos ao intolerante ao glúten. US $ 5 cartões de presente a Best Buy, por outro lado ...

— Christopher Mahan

1

@ChristopherMahan resultaria em uma briga entre todos os membros da equipe sobre quem a recebe; ou se receber um membro da equipe como a distribuição implícita de uma caixa de rosca na sala de descanso é uma proposta muito mais cara. De qualquer forma, um vale-presente da Best Buy poderia ser ofensivo para quem trabalhava na Circuit City ou na CompUSA. :)

— Dan Neely

1

O que você pode obter na Best Buy por menos de US $ 5?

— Kevin cline

12

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.

— mouviciel
fonte

9

"... não culpar o responsável." A menos que seja uma ocorrência regular.

— Shawn D.

11

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.

— Michael Riley - também conhecido por Gunny
fonte

2

+1 por colocar o ônus no primeiro desenvolvedor a testar a compilação. O segundo parágrafo realmente não é verdadeiro ou relevante. Outras pessoas podem prejudicar sua reputação, intencionalmente ou não, mesmo quando seu comportamento está completamente acima do normal.

— Caleb

6

É perfeitamente possível que o programador original tenha a biblioteca em sua máquina, mas a máquina que faz a construção automática não. Sim, a biblioteca deve estar no SVN, mas esse pode ser um problema realmente sutil, que nem se nota.

— mpdonadio

7

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.

— xsace
fonte

5

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.

— DPD
fonte

3

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.

— AndyC
fonte

2

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!

— luketorjussen
fonte

2

Nossa ferramenta de IC, na verdade, tem a opção de enviar email ao desenvolvedor que interrompeu a compilação (além do restante da equipe).

— TMN

2

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.

— Alex Dalziel
fonte

Com as compilações de integração que às vezes levam uma hora ou mais, dependendo da complexidade do seu sistema, você precisa implementar um "limite de confirmação" todos os dias para garantir que a última compilação do dia ocorra enquanto todo mundo ainda estiver por perto. Mesmo assim, as pessoas têm consultas médicas, prática de futebol infantil, etc., e precisam sair imediatamente, independentemente do status da construção. Agile diz que o trabalho deve estar em um ritmo sustentável e não deve ser um desperdício para os trabalhadores. Mantê-los lá até as 8:00 para assistir a uma compilação ter sucesso é contrário a isso.

— #

@ KeithS: Verdadeiro. Mas descobri que, independentemente de quando eu partir, o momento mais provável para eu interromper a construção é quando estou com pressa: logo antes do almoço, antes de uma reunião, logo antes do final do dia. Portanto, acho que é uma "melhor prática pessoal" não comprometer nada quando não houver tempo suficiente para assistir e corrigir a compilação posteriormente.

— Daniel Pryden

2

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.

— Peter Kelly
fonte

2

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

— StasM
fonte

1

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

— KeithS
fonte

1

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.

— Dave
fonte

0

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.

— HLGEM
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 é 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 ^ _ ^

— fortran
fonte

0

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.

— David Schwartz
fonte

0

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?

— Kris
fonte