Como pedir desculpas quando você interrompeu a compilação noturna [fechado]


181

Meu primeiro commit no meu projeto resultou na construção noturna sendo interrompida e as pessoas estão em cima de mim quando estamos chegando ao lançamento. Quero enviar um e-mail de desculpas que deve parecer sincero e ao mesmo tempo sugerir que esse foi meu primeiro commit e que isso não seria mais repetido.

Sendo um falante de inglês não nativo, tenho dificuldades em encontrar as palavras corretas. Alguém pode ajudar por favor?


99
Se a build nunca quebrou eu começar a suspeitar de um processo de construção quebrado;)
Lazarus

6
Como você soube que a construção estava quebrada?

65
Que tal: "Sinto muito por interromper a construção noturna. Se você quiser reter meu salário como forma de punição, não levarei a empresa ao tribunal do trabalho". Não, só brincando - não se desculpe, esse tipo de coisa acontece o tempo todo. As pessoas que estão "em cima de você" estão enlouquecendo psicopatas que não sabem como restaurar adequadamente o sistema ao estado anterior.
25411 Jas

14
Eu quebrei a compilação nos meus 10 primeiros commits! Não se preocupe com isso
Ninguém

135
Eu só desejo que eu tinha um nightly build para quebrar ..
Max

Respostas:


306

Não peça desculpas!

  • Quebrar a construção uma vez na lua azul não é grande coisa e nunca deve ser um obstáculo para o show.
  • A culpa é do seu gerente por não configurar versões contínuas e automatizadas.

Além disso, aposto que sua equipe falhou no 'Teste Joel' e não pode fazer uma compilação em uma única etapa.

Nesse caso, isso seria outra coisa pela qual você não deveria se desculpar. Na verdade, é um anti-padrão de equipe.


31
+1 Concordado! Não peça desculpas. APRENDA o que você fez de errado. Não faça isso de novo, pelo menos não em breve. Seja educado quando as pessoas estiverem "em cima de você". Aprenda com o que eles dizem (mesmo que seja apenas um idiota e quem está bem).
Peter K.

12
Bem, você pode se desculpar ainda ... Mas estou um pouco surpreso que as pessoas estejam em cima de você. Se você é novo na equipe, não deve ser uma surpresa que cometa um erro. Pelo menos isso mostra que você fez alguma coisa :)
Philippe

40
+1. Todo o objetivo de fazer uma compilação noturna é detectar problemas o mais cedo possível e antes que eles saiam com uma liberação. 95% dos desenvolvedores cometeram erros de alta visibilidade durante suas carreiras. Os outros 5% estão mentindo.
Blrfl 25/05

26
Embora eu concorde que isso não exige um pedido de desculpas no nível "caindo na espada", acho que exige um pedido de desculpas no nível "oops, meu mau". Nem todo 'desculpe' precisa ser abjeto.
Matthew Scouten

5
Não concordo com essa premissa, não há nada errado com um simples pedido de desculpas, percebo que estrago tudo e farei o possível para aprender com meu erro . Concordo que a melhor maneira de * corrigir * a si mesmo não é fazê-lo novamente, mas se você se importa, talvez não o mostre abertamente para que os outros saibam, nem sempre que você estragar tudo, mas ele claramente se sentiu mal por causa disso. e não há nada de errado em pedir desculpas.
Trufa 26/05

182

Bagels. Donuts. Etc. Em uma empresa em que trabalhei no passado, o check-in de código quebrado ou a interrupção de colegas é geralmente resolvido com a introdução de pedidos de desculpas no dia seguinte.

Tivemos um cara que explodiu um banco de dados de produção um dia, causando pânico e muita madrugada para toda a equipe. No dia seguinte, ele grelhava hambúrgueres no almoço.

Eu amo desculpas de colegas de trabalho. Saborosas, desculpas saborosas.


83
+1 em "Adoro desculpas de colegas de trabalho. Desculpas saborosas e saborosas".
25411 Jas

32
Quebrar a compilação noturna do desenvolvedor é uma coisa, mas acabar com o banco de dados de produção está em um nível totalmente diferente. Se eu já fiz isso, gostaria que grelhar hambúrgueres fosse o pior do meu castigo.
maple_shaft

20
Você quase pode provar a culpa.
Mike Speed

40
"Explodir um banco de dados de produção" coloca todos os tipos de imagens hilariantes na minha cabeça sobre o que exatamente aconteceu com o banco de dados. A maioria deles envolve todos ouvindo uma explosão alta da sala do servidor. "Oh Deus, o banco de dados está atingindo um volume crítico!" "Rápido! Abaixe as hastes de controle!" "É tarde demais, os dados, ela está condenada!" BOOM
Carson Myers

7
drop database... Oh, o poder dessas duas pequenas palavras. Faz anos, mas eu me lembro bem;) #
Leigh

80

Duas citações para você:

O homem que não comete erros geralmente não faz nada. - William Connor Magee

Quem não cometer erros não está se esforçando o suficiente. - Wess Roberts

Concordo com Jim G. , não me desculpe, mas aprenda com ele e não cometa o mesmo erro novamente ... mantenha-o SECO;)


9
Ou há uma citação mais geral de: "quem está sem pecado lance a primeira pedra" Se quem está gemendo sobre a construção quebrada já a quebrou antes, eles não deveriam estar gemendo
Richard

como o segundo !!
Sufendy

1
Citando - me a todos os graduados que já menti "I expect you to make lots of mistakes. Own up to them, accept them, and learn from them. If you never make mistakes, you'll never really learn anything",.
S.Robins

Bom uso do princípio "DRY" ... :)
J. Allan

53

Não se desculpe, basta corrigi-lo o mais rápido possível. Tudo bem, no entanto, todo mundo quebra a construção pelo menos uma vez, na minha última empresa, foi como um ritual de iniciação. Quando um membro da equipe quebrava a compilação, colocávamos um patinho de borracha em sua mesa na manhã anterior à sua entrada, para que ele soubesse que ele quebrou a compilação e ele a consertaria.

Nós o chamamos de Duckie de Integração Contínua e, quando você o tinha durante o dia, as pessoas o provocavam, mas tudo era divertido, nada disso deveria ser mesquinho.

Pegamos algo como uma construção quebrada e a transformamos em um exercício de construção de equipe.


2
+1: não apenas com o que eles se preocupam - com o que eles devem se preocupar. Você não fez nada errado, como tal - apenas flexionou os limites do que é possível um pouco longe demais;). Você provavelmente também é a pessoa mais bem posicionada para consertar isso. Todo mundo faz isso de vez em quando. Todo mundo envia algo para viver que não deveria ter saído. Todo mundo deixa a cláusula WHERE fora de uma declaração UPDATE uma vez na vida. É como você reage que é importante. Onde estamos, todos os desenvolvedores tendem a se fechar, recusando-se a falar sobre quem foi o culpado individualmente, se alguém perguntar, isso é corrigido.
Tom Morgan

Que parece ser uma realmente ótima maneira de lidar com erros.
Trufa 26/05

3
Integração Contínua Duckie , Hahahaha
AttackingHobo

43

"Desculpe, minha culpa!" é assim que geralmente peço desculpas quando quebrei a compilação. Acontece. Mas, como outros já disseram, esta é uma oportunidade para melhorar seus sistemas, para que uma pessoa não possa quebrar com facilidade a construção para todos os outros.

Eu não faria um pedido formal de desculpas nessas circunstâncias, mas se você realmente acha que um pedido de desculpas mais formal é apropriado, seu pedido de desculpas deve fazer o seguinte:

  • Expressar arrependimento.
  • Indique o problema.
  • Tomar responsabilidade.
  • Faça as pazes.
  • Salve o rosto.

Ou seja, "Sinto muito [EXPRESSAR Lamentar] por ter incomodado você [TOMAR RESPONSABILIDADE] por acidentalmente [SALVAR CARA] violando a construção [DECLARAR O PROBLEMA]. Os donuts estão comigo amanhã. [FAÇA AMENDS]" "

Cada parte é necessária em um pedido de desculpas apropriado; se você não indicar o problema, não está claro. Se você não se arrepende, assume a responsabilidade e faz as pazes, as pessoas se sentem insinceras. A parte de salvar o rosto é a parte mais esquecida de um pedido de desculpas; a parte de salvar o rosto é o que lembra à pessoa ferida que você é um colega valioso que às vezes comete erros, e não um idiota (ou um sabotador!)

Finalmente, algumas reflexões sobre a quebra de build:

Trabalho na equipe do compilador C # / Visual Basic. É claro que hoje o Visual Studio agora é um projeto tão grande que possui uma equipe própria apenas para gerenciar a infraestrutura de construção e uma sala enorme com seu próprio sistema de ar condicionado dedicado. Em meados dos anos 90, quando comecei como estagiário, a equipe de criação do Visual Basic era uma estagiária - eu - e um armário cheio de máquinas. Os tempos mudaram!

Naqueles dias antes da integração contínua e de processos sólidos de check-in, as equipes tinham uma variedade de penalidades por interromper a construção. Em algumas equipes, a penalidade era que, se você quebrasse a construção, teria que usar um chapéu engraçado todos os dias no trabalho até que outra pessoa quebrasse a construção. Em algumas equipes, se você usava esse chapéu, era responsável por verificar se a construção noturna estava correta.

Essa última parte parece talvez cruel, mas na verdade serviu a um propósito valioso. Como quase todo mundo quebrou a compilação de uma vez ou outra, eventualmente a equipe inteira aprendeu os processos para verificar a compilação noturna.


15

Não peça desculpas. Seus colegas de trabalho são os responsáveis ​​por não revisar seu primeiro commit e por não terem um sistema de feedback rápido para compilações como um servidor de integração contínua.

No meu trabalho atual, temos uma regra informal de que alguém que se comprometa furtivamente pouco antes de sair do trabalho e acaba quebrando a construção precisa trazer doces / bolos / bebidas para toda a equipe no dia seguinte. Mas temos uma integração contínua que nos avisa sobre uma construção quebrada durante o dia. E a regra provavelmente não se aplicaria ao primeiro commit de alguém.

De qualquer forma, um e-mail formal de desculpas é provavelmente um pouco demais.


Uma excelente revisão pontual deveria ter percebido isso. Porque você faz alterações na revisão por pares antes de aplicá-las ao master / HEAD / default, certo?
Frank Shearar

11

Uma regra fundamental - quando você estiver errado, ADMITA: - | Você não precisa se desculpar. Todo mundo comete erros. Os profissionais admitem isso. Isso é trabalho em equipe. Os outros membros da equipe devem se reunir para ajudá-lo. Caso contrário, peça ajuda. O máximo que se pode dizer depois é: o que podemos aprender com isso?

Eles dizem que um casamento bem-sucedido se baseia em três pequenas palavras - "eu estava errado".

Se alguém não comete um erro ocasional, não está funcionando, mas um erro que não se aprende é o de dois erros.


Eu acho que essa é uma ótima resposta e muito melhor do que a "Não peça desculpas" que tem os votos mais altos. Você pode pedir desculpas a todos por quebrar a compilação, mas eles também precisam mostrar um pouco de graça. Eles também deveriam estar dizendo "não se preocupe, todos nós já o quebramos antes, afinal, é para isso que existe". Contanto que você tente não quebrá-lo novamente, eles devem ser legais com isso. Se você ignora todo mundo e comete o mesmo erro, é uma história diferente.
Rocklan

6

O melhor pedido de desculpas é consertar o intervalo rapidamente


5

Se sua empresa já tem uma maneira de testar suas alterações de compilação, (A) suas alterações falharam (mas você as registrou mesmo assim) ou (B) elas foram bem-sucedidas (e você precisa criar um novo caso de teste).

Se seus colegas testam cuidadosamente suas alterações e esperam encontrar pausas na construção noturna, (C) você tem um processo frágil (e precisa introduzir testes como os encontrados na Programação Extrema).

É possível que (D) Suas alterações tenham causado alterações imprevistas no código de Bill, que estavam em vigor antes ou foram alteradas na mesma compilação que a sua.

Dependendo de como você e sua empresa testam, peço desculpas caso a caso:

  • (A) Falha no teste de construção, mas verifiquei minhas alterações. Desculpe, estou alterando meu processo para não fazer novamente.
  • (B) Passei no teste de construção e adicionei o teste JUnit XYZtest.java para reduzir a chance de nova ocorrência.
  • (C) Como não temos um processo de teste de construção, estou criando um para minhas alterações. Gostaria de compartilhar com você como podemos melhorar nosso processo de criação.
  • (D) Trabalharei com Bill para escrever um teste JUnit XYZtest.java para reduzir a chance de ocorrência.

Tenho certeza de que há um (E) em que não pensei.

Observe que estou dizendo "reduzir a chance de reincidência" em vez de "para que isso não aconteça novamente". Isso vai acontecer novamente. Mas você pode melhorar seu processo para reduzir essa possibilidade. Acho que essa é uma das marcas de um programador vencedor.


2

Não peça desculpas. Você é humano e cometerá erros. Todo mundo irá quebrar a compilação ocasionalmente, a chave é corrigi-la rapidamente.

Quanto às pessoas pulando em cima de você ... bem, estou curioso para saber se elas já escreveram um bug.


2

Como abordar isso depende da atmosfera do seu grupo. Se é uma cultura de culpa, eu teria muito cuidado em pedir desculpas e como você faz isso. Se é uma atmosfera positiva e colaborativa, sim, algo como "Eu errei, me desculpe. Como podemos evitar isso no futuro?" provavelmente é uma boa ideia.

De qualquer forma, uma brincadeira como essa deve ser acompanhada de algum tipo de post-mortem para: a) descobrir como isso aconteceu eb) como minimizar as chances de isso acontecer novamente.

Não estou familiarizado com a sua estrutura (trabalho em um ambiente muito diferente), mas, em última análise, a realidade é que, ocasionalmente, as pessoas cometem erros e as coisas quebram. Você aprende com a experiência e segue em frente.


2

No meu ambiente, se você quebrasse a construção, obteria uma boa nervura e um cometa espirituoso. Não sei em que país de língua inglesa você está, mas pode ser que, como um falante não nativo, você não esteja recebendo a natureza sublinhada dos comentários.

Sendo do outro lado como desenvolvedor sênior, certa vez, comentei em uma revisão de código que alguma maneira de fazer x "era ruim" não porque o código era ruim, mas afetava a estrutura do projeto. Foi mais um comentário para mim mesmo que eu precisava resolver o problema estrutural. Só mais tarde descobri que o Jr Dev estava muito zangado com ele devido ao meu discurso impreciso e irreverente.


2

Hum. Você recebe o token de compilação quebrado . Passe a raiva para o próximo sortudo. Acontece o tempo todo. A qualidade é importante, mas os erros são inevitáveis. Consertá-los. Ir em frente. Vergonha o próximo pobre cara.


1
Eu já vi muito isso. O outro é que você "cuida" da construção noturna até que alguém a destrua. Isso não significa consertar, mas descobrir por que e quem deve consertá-lo.
Stephen Darlington

1

Como regra geral, eu diria:

Se o seu check-in causar um erro do compilador, você se surpreenderia se tivesse feito uma "atualização mais recente" antes de fazer o check-in, um simples "grito, meu mal" está em ordem. (especialmente se você passear às 10 da manhã seguinte, enquanto todo mundo estiver decidindo para qual mudança mudar)

Se o seu check-in causar um comportamento inesperado geral, até mesmo erros de tempo de execução, não acho que deva ser mantido contra você. Vem com o território. Desde que todos os usuários "recebam as últimas atualizações" geralmente sejam aprovados em seus compiladores, as pessoas realmente não devem estar se adaptando (com algumas exceções, como excluir um banco de dados, excluir a cópia do servidor do projeto e todos os conjuntos de alterações ou qualquer outra coisa que seja tão burro que as pessoas têm que assumir intenções maliciosas).


1

A equipe falhou.

Sua empresa precisa de mais revisão de código em um desenvolvedor fazendo uma primeira compilação.

Só não vejo como uma equipe permite que isso continue sem que eles façam uma revisão e ofereçam algumas garantias ao longo do caminho de que você está fazendo as coisas corretamente.

Estar perto do tempo de lançamento não é uma desculpa, mas uma razão melhor para verificar novamente o novo código.

Se sua liberação não puder ser facilmente desfeita, há problemas ainda maiores com esse grupo.


0

Eu não entendo por que as pessoas estão em cima de você. Se o sistema estiver bem configurado, eles deverão conseguir alterar suas alterações / corrigi-las rapidamente.

Mas, novamente, se você é um daqueles caras que quebraram as janelas, então ... eu não posso ajudar. (É incrivelmente difícil fazer o que se pede - antes que alguém questione a EM construindo filosofias, mas de vez em quando alguém o faz - e todo o controle de qualidade da empresa pára por um dia).

E sim - não se desculpe. Converse com seu gerente e faça-o entender que você aprendeu com o que fez.


0

Construções quebram o tempo todo. Erros e erros são um fato da vida, e é por isso que você deve ter um processo que minimize os efeitos de erros e erros.

Se uma quebra de construção é um problema, significa que seu processo está quebrado.

Você deve fazer construções contínuas, não noturnas.


+1 em "se uma quebra de construção é um problema, significa que seu processo está quebrado". Por outro lado, você ainda precisa lidar com o processo interrompido, e isso significa fazer o possível para evitar a interrupção da construção noturna até que o processo seja aprimorado.
Caleb

0

Melhor uma resposta tardia do que nunca ...

Como muitos outros disseram, não peça desculpas por quebrar a compilação. Simplesmente admita que era você e continue com o trabalho. Isso aconteceria se você estivesse lá ou não, e ninguém merece ser tratado mal por causa disso. As pessoas reagem mal sob pressão; portanto, se você conseguir manter a calma e simplesmente continuar o trabalho, você se destacará quando for importante. Meu conselho para quando as pessoas enfrentam dificuldades é simplesmente evitar ficar na defensiva, desarmar a situação, informando as pessoas de que você está ou não envolvido no problema ou você é rápido em procurar conselhos se descobrir que ficou preso.

Pessoalmente, vejo uma construção quebrada como uma oportunidade.

  • Se a construção for interrompida e você puder provar que é sua culpa, é provável que mostre que os processos de integração e construção contínuos estão fazendo seu trabalho. Isso é bom, pois valida seus processos. Se a construção nunca quebrar, eu me preocuparia que houvesse algo errado com ela.
  • Se você quebrou a compilação de uma maneira bastante comum e acontece com frequência dessa maneira, talvez algo esteja faltando no processo do IC. Esta é uma oportunidade para melhorar seus processos para que os cenários de falha comuns possam ser melhor gerenciados.
  • Se você foi além do dever e realmente atrapalhou a construção com um problema obscuro, terá a oportunidade de aprender sobre algo novo que pode ser importante o suficiente para acionar um aviso ao resto da equipe.

Então, o que estou dizendo é que quebrar a compilação ocasionalmente significa que as pessoas estão fazendo seu trabalho. Claro que você pode ter cometido um erro, mas se você usá-lo como uma oportunidade de aprender, estará fazendo seu trabalho simplesmente aprendendo a fazê-lo melhor da próxima vez.


-1

Diga a eles que precisam de compilações de IC por check-in. Dessa forma, você não precisaria esperar até a noite para saber que está quebrado. SIM!!! Diga a eles que é o processo que está errado, nada mais. Você acabou de identificar uma lacuna no sistema deles .

Mas sim, certifique-se de consertar. Não é grande coisa. Não está em produção. Apenas uma noite inútil.


-2

Uma prática usual na minha empresa é:

  • Gritando "não fui eu!" (geralmente provas CVS / SVN de outra forma)
  • Vestindo uma camiseta dizendo "my-userlogin ist Schuld!" (sim, 50% da camisa do nosso desenvolvedor)
  • Alegando que funciona na caixa de envio local e que todos os testes foram aprovados

Minha empresa também tem uma ótima maneira de lidar com esse "incidente":


-2
  • Eu não pediria desculpas.

  • Eu culparia o líder de IC por me permitir cometer uma construção quebrada.

  • Deve haver um processo de IC para impedir que os desenvolvedores cometam códigos quebrados.

  • Se a construção local falhar, não deverá ser permitido entrar no servidor de construção.


1) Nem todos os projetos são configurados para integração contínua. É bom ter e pode ajudar em situações como os OP, mas está longe de ser um dado. 2) Nunca é demais pedir desculpas, mesmo quando não é realmente um grande negócio, mesmo quando existem ferramentas que poderiam ter evitado o problema. 3) Culpar alguém por um problema que você causou, seja realmente sua culpa ou não, é uma péssima idéia.
Caleb

Existem dois problemas aqui: 1 - código quebrado na máquina local. 2 - código quebrado em um servidor de compilação. O primeiro problema é muito pequeno, pois todos os desenvolvedores cometem erros. As alterações podem ser desfeitas e não haverá impacto no sistema ou no departamento. É provável que o segundo problema tenha um impacto negativo muito maior no sistema e no departamento.
CodeART

-2

Embora eu ache que possa haver algum pedido de desculpas, não diga: "Vou garantir que isso não aconteça novamente". Porque vai. E se isso acontecer, ele vai te morder.


-2

Se você estiver trabalhando em um projeto de código aberto,

apenas diga "Desculpe, eu quebrei a construção. Pode ser que eu estivesse com muito sono!"

e adicione-o como um comentário no github.

Isso ocorre porque muitos desenvolvedores de código aberto escrevem código durante a meia-noite.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.