Meu primeiro commit no meu projeto resultou na composição noturna sendo quebrada e as pessoas estão em cima de mim enquanto estamos nos aproximando do lançamento. Quero enviar um email de desculpas que soe sincero e ao mesmo tempo insinuando que este era meu primeiro commit e isso não seria mais repetido.
Sendo um falante nativo de inglês, tenho dificuldades em encontrar palavras corretas. Alguém por favor pode ajudar?
Don't apologize!
Além disso, aposto que sua equipe falha no 'Joel Test' e não pode fazer uma compilação em um degrau.
Se sim, isso seria outra coisa pela qual você não deveria se desculpar. De fato, é um anti-padrão de equipe.
Bagels. Donuts. Etc. Em uma empresa em que trabalhei no passado, checar código quebrado ou causar ruptura nos colegas é geralmente resolvido com a entrada de alimentos no dia seguinte.
Tivemos um cara explodir um banco de dados de produção um dia, causando pânico em massa e uma noite para toda a equipe. No dia seguinte, ele grelhava hambúrgueres no almoço.
Adoro desculpas por colegas de trabalho. Saborosas e saborosas desculpas.
Duas citações para você:
The man who makes no mistakes does not usually make anything.--William Connor Magee
Anyone who doesn't make mistakes isn't trying hard enough.--Wess Roberts
Concordo com Jim G. , não se desculpe, mas aprenda com ele e não o faça o mesmo erro novamente ... mantenha-o seco;)
Não se desculpe, apenas CORTE-O assim que possível. Tudo bem, porém, todo mundo quebra a construção pelo menos uma vez, na minha última companhia era uma espécie de ritual de iniciação. Quando um membro da equipe quebrou a construção, colocamos um patinho de borracha em sua mesa pela manhã antes de ele entrar, isso o fez saber que ele quebrou a construção e que ele iria consertá-lo.
Nós o chamamos de Duckie de Integração Contínua e quando você tinha isso para o dia as pessoas iriam te provocar, mas era tudo divertido, nada disso deveria ser malvado.
Nós pegamos algo como uma construção quebrada e a transformamos em um exercício de construção de equipe.
"Desculpe! Meu mal!" é como eu geralmente peço desculpas quando eu quebrei a compilação. Acontece. Mas, como outros disseram, esta é uma oportunidade para melhorar seus sistemas de modo que uma pessoa não possa quebrar a compilação com facilidade para todos os outros.
Eu não faria um pedido formal de desculpas nessas circunstâncias, mas se você realmente achar que um pedido de desculpas mais formal é apropriado, então seu pedido de desculpas deve fazer estas coisas:
Isto é, "Sinto muito [EXPRESS REGRET] que eu te incomodei [ASSUMIR A RESPONSABILIDADE] acidentalmente [SAVE FACE] quebrando a compilação [STATE THE PROBLEM]. Donuts estão em mim amanhã. [MAKE AMENDS]"
Cada parte é necessária em um pedido de desculpas adequado; se você não indicar o problema, então não está claro. Se você não se arrepende, se responsabiliza e faz as pazes, as pessoas se sentem insinceras. A parte que salva a face é a parte mais negligenciada de um pedido de desculpas; a parte que salva o rosto é o que lembra a parte lesada de que você é um valioso colega de trabalho que às vezes comete erros, e não um idiota (ou um sabotador!)
Finalmente, algumas reflexões sobre a quebra de construções:
Eu trabalho na equipe de compiladores C # / Visual Basic. É claro que hoje o Visual Studio é agora um projeto tão grande que tem uma equipe própria apenas para gerenciar a infraestrutura de construção e uma enorme sala com seu próprio sistema de ar condicionado dedicado. Em meados da década de 1990, quando comecei como estagiário, a equipe de criação do Visual Basic era um interno - eu - e um armário cheio de máquinas. Os tempos mudaram!
Naqueles dias, antes da integração contínua e dos processos de check-in, as equipes teriam várias penalidades para quebrar a compilação. Em algumas equipes a penalidade era que se você quebrasse a construção, você teria que usar um chapéu engraçado todos os dias no trabalho até que alguém quebrasse a construção. Em algumas equipes, se você estivesse usando esse chapéu, você seria responsável por verificar se a construção noturna estava correta.
Esse último som parece cruel, mas na verdade serviu a um propósito valioso. Como quase todo mundo quebrou a compilação de uma vez ou outra, eventualmente toda a equipe aprenderia os processos para verificar a compilação noturna.
Não se desculpe. São seus colegas de trabalho os culpados por não revisar seu primeiro commit e por não ter um sistema de feedback rápido para compilações como um servidor de integração contínua.
No meu emprego atual, temos uma regra informal de que alguém que se comprometa sorrateiramente antes de sair do trabalho e acaba quebrando a construção tem que trazer doces / bolos / bebidas para toda a equipe no dia seguinte. Mas nós temos integração contínua que nos avisa de 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 pedido formal de desculpas é provavelmente um pouco demais.
Uma regra fundamental - quando você está errado, ADMIT IT: - | Você não precisa se desculpar. Todo mundo comete erros. Os profissionais admitem isso. Isso é trabalho em equipe. Os outros membros da equipe devem estar reunidos para ajudá-lo. Se não, peça ajuda. O máximo que tem que ser dito depois é - o que podemos aprender com isso?
Eles dizem que um casamento bem-sucedido é baseado em três pequenas palavras - "Eu estava errado".
Se alguém não cometer um erro ocasional, ele não está trabalhando mas um erro com o qual não se aprende é dois erros.
Se sua empresa já tiver uma maneira de testar suas alterações de compilação, (A) suas alterações falharão (mas você as verificou de qualquer maneira) ou (B) tiveram êxito (e você precisa criar um novo caso de teste).
Se seus colegas cuidadosamente testarem suas mudanças e esperarem encontrar interrupções na compilação noturna, então (C) você terá um processo frágil (e você precisará introduzir testes como os encontrados em Extreme Programming).
É possível que (D) Suas alterações causaram alterações imprevistas no código de Bill que estavam em vigor antes ou foram alteradas na mesma versão da sua.
Dependendo de como você e sua empresa testam, peço desculpas caso a caso:
Tenho certeza de que há um (E) em que não pensei.
Observe que estou dizendo "para reduzir a chance de recorrê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. Isso, eu acho, é uma das marcas de um programador vencedor.
Não se desculpe. Você é humano e cometerá erros. Todo mundo vai quebrar a construção ocasionalmente, a chave é apenas corrigi-lo rapidamente.
Quanto às pessoas pulando em cima de você ... bem, estou curioso para saber se elas já escreveram em um bug.
Como abordar isso depende da atmosfera do seu grupo. Se é uma cultura de culpa, eu tenho muito cuidado em pedir desculpas e como você faz isso. Se é uma atmosfera positiva e colaborativa, então, sim, algo como "eu errei, desculpe. Como podemos evitar isso no futuro?" é provavelmente uma boa ideia.
De qualquer forma, um erro assim deve ser acompanhado de algum tipo de post-mortem para a) descobrir como isso aconteceu e b) como minimizar as chances de que isso aconteça novamente.
Não estou familiarizado com sua estrutura (trabalho em um ambiente muito diferente), mas, em última análise, a realidade é que, ocasionalmente, as pessoas cometem erros e as coisas são quebradas. Você aprende com a experiência e segue em frente.
No meu ambiente, se você quebrou a construção, você obteria um nervo bem-humorado e algum cometa espirituoso. Não tenho certeza de qual país fala inglês em sua língua, mas pode ser que, como um falante não nativo de inglês, você não esteja entendendo a natureza dos comentários.
Sendo do outro lado como um desenvolvedor Senior, uma vez eu comentei em uma revisão de código que alguma forma de fazer x "sucked" não porque o código era ruim, mas sim para a estrutura do projeto. Foi mais um comentário para mim mesmo que eu preciso consertar o problema estrutural. Só mais tarde descobri que o Jr Dev estava muito zangado com ele devido ao meu impreciso discurso irreverente.
Você recebe o símbolo de construção quebrada . Passe a raiva para o próximo beneficiário sortudo. Acontece o tempo todo. A qualidade é importante, mas os erros são inevitáveis. Consertá-los. Ir em frente. Envergonhe o próximo pobre homem.
Como regra geral, eu diria:
Se o seu checkin causar um erro no compilador, você teria se surpreendido se tivesse feito um "get latest" antes do check-in, um simples "whoops, my bad" está em ordem. (especialmente se você chegar às 10 da manhã seguinte, enquanto todos estão decidindo qual changeset reverter para)
Se o seu checkin causar um comportamento geral inesperado, mesmo erros de tempo de execução, não acho que deva ser usado contra você. Vem com o território. Desde que o "get latest" de todos geralmente seja aprovado em seus compiladores, as pessoas realmente não deveriam estar ajustando (com algumas exceções, como excluir um banco de dados, excluir a cópia do servidor do projeto e todos os changesets) , ou qualquer outra coisa que seja tão burra que as pessoas tenham que assumir intenções maliciosas).
O TEAM falhou.
Sua empresa precisa de mais revisões de código em um desenvolvedor que faz uma compilação pela primeira vez.
Eu 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 que você está fazendo as coisas corretamente.
Estar perto do tempo de lançamento não é uma desculpa, mas um motivo melhor para verificar novamente o novo código.
Se a sua divulgação não puder ser facilmente desfeita, existem problemas ainda maiores com este grupo.
Eu não entendo porque as pessoas estão em cima de você. Se o sistema está bem configurado, eles devem ser capazes de descobrir as 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 fazê-lo - antes que alguém duvide que o MS construa filosofias, mas de vez em quando alguém faz isso - e o QA da empresa inteira pára por um dia).
E sim - não se desculpe. Basta conversar com seu gerente e fazê-lo entender que você aprendeu com o que fez.
Cria quebra o tempo todo. Bugs 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 compilação é tão grande, isso significa que seu processo está quebrado.
Você deve fazer construções contínuas, e não construções noturnas.
Melhor resposta tardia do que nunca ...
Como muitos outros disseram, não se desculpe por ter quebrado a compilação. Simplesmente admita que foi você e continue com o trabalho. Essa coisa aconteceria se você estivesse lá ou não, e ninguém merece ser maltratado por causa disso. As pessoas reagem mal sob pressão, então, se você conseguir manter a calma e simplesmente continuar o trabalho, você se destacará quando for importante. Meu conselho para quando as pessoas lhe dão dificuldade é simplesmente evitar ser defensivo, desarmar a situação deixando que as pessoas saibam que você está ou no problema ou você é rápido em procurar conselhos se achar que ficou preso.
Pessoalmente, vejo uma construção quebrada como uma oportunidade.
Então, o que estou dizendo é que quebrar a compilação ocasionalmente significa que as pessoas estão fazendo o trabalho delas. Claro que você pode ter cometido um erro, mas se você usá-lo como uma oportunidade para aprender, você está fazendo o seu trabalho simplesmente aprendendo a fazê-lo melhor da próxima vez.
Diga-lhes que precisam de compilações de CI por check-in. Dessa forma, você não teria que esperar até a noite para saber que está quebrado. SIM!!! Diga-lhes que é o processo que está errado, nada mais. Você acabou de identificar uma lacuna no sistema deles.
Mas sim, certifique-se de corrigi-lo. Não é grande coisa. Não está em produção. Apenas uma noite sem valor.
Uma prática usual na minha empresa é:
Minha empresa também tem uma maneira legal de lidar com um "incidente":
Eu não me desculparia.
Eu culpo chumbo CI por me permitir cometer construção quebrada.
Deve haver um processo de IC para impedir que os desenvolvedores cometerem códigos corrompidos.
Se a compilação local falhar, não deverá ser permitido entrar no servidor de compilação.
Enquanto eu penso que algum tipo de pedido de desculpas pode estar em vigor, por favor, não diga: "Vou me certificar de que isso não aconteça novamente". Porque vai. E se isso acontecer, vai te morder.
Se você estiver trabalhando em um projeto de código aberto,
apenas diga "Desculpe, eu quebrei a compilação. Pode ser que eu estivesse com muito sono!"
e adicione-o como um comentário do github.
É porque muitos desenvolvedores de código aberto escrevem código durante a meia-noite.