Corrigindo um erro que nunca causou um problema até agora

Recentemente, fiz uma alteração que fazia com que algum código fosse executado com muito mais frequência do que costumava ser. Isso levou à descoberta de um bug. Esse bug tinha o potencial de acontecer a qualquer momento em que o código era executado, mas porque era executado tão raramente que nunca aparecia.

Quando eu trouxe isso à atenção do desenvolvedor líder, ele queria que eu desfizesse a alteração que expunha o bug, em vez de corrigi-lo, citando o ditado: "Se não estiver quebrado, não conserte".

Está claro para mim que tivemos sorte até agora, mas ele não quis ouvir a razão.

Devo consertar mesmo assim?

Atualizar

O líder tecnicamente não tem nenhuma autoridade sobre mim. Apenas posse. Ele é o único desenvolvedor do projeto há vários anos, até um ano atrás, e acho que ele não aceita críticas construtivas muito bem. Pelo que vale a pena, não o critiquei. Eu apenas apontei que só porque o bug nunca apareceu não significava que não estava lá.

Eu sugeriria que, se você possui rastreamento de bugs, envie-o. Se for crítico, eleve-o e leve-o à atenção dele. Deixe seu superior rebaixá-lo no rastreador. Quando as coisas derem errado, você terá a trilha do papel.

Pessoalmente, eu o consertaria, a menos que exigisse muito mais esforço do que valia. "Se não está quebrado, não conserte" é horrível aplicar ao software.

Se o seu desenvolvedor líder é o seu chefe e ele diz que não toque, nesse caso eu não faria.

A maioria das respostas e comentários sugeriu mitigar a responsabilidade pela decisão, criando um relatório de erro e permitindo que outra pessoa fizesse a ligação.

Como não tenho rastreador de erros (e duvido que alguém além de mim o usaria se o fizéssemos), fiz a próxima melhor coisa. Passei por cima da cabeça do desenvolvedor principal. Depois de explicar a situação à gerência, eles viram as coisas do meu jeito. Eles me disseram para corrigi-lo corretamente e ignorar a solicitação de demanda do lead . Eles disseram que alisariam qualquer plissado se ele descobrisse o subterfúgio e reclamasse.

Não é uma solução ideal, mas pelo menos o bug foi corrigido corretamente.

Lembre-o de que a frase é: "Se não estiver quebrado, não conserte" e não "Se o cliente não percebeu, não conserte".

Que justificativa você tem para a mudança que fez? Se você não pode apontar quais mudanças o usuário experimentaria ou a dívida técnica foi removida, eu ficaria do lado do desenvolvedor líder em termos de dizer apenas de volta a mudança, pois isso está apenas piorando as coisas.

Você tem pelo menos algumas opções diferentes aqui em minha mente:

Se você apenas seguir em frente e consertar o erro, corre o risco de adicionar mais erros à mistura, o que poderia sair pela culatra. Dependendo da quantidade de experiência que você tem e da confiança de evitar alguma surpresa desagradável que provavelmente seria o meu guia aqui.

Se você faz o que foi instruído a fazer, é apenas culpa que seria o problema ou é mais do que isso? Estou me perguntando o que há de errado aqui, além das coisas conhecidas como princípios e valores. Quero dizer que, como uma piada, mas também um ponto honesto do que há de errado com essa ideia?

Enquanto meu instinto avassalador seria consertar os bugs para não esconder o problema, há situações em que eu segurava meu nariz e escondia o problema.

1. O código é usado internamente e, ocasionalmente, para que as conseqüências do bug sejam gerenciáveis ​​dentro da empresa.
2. Considerações comerciais impressionantes que exigiam remessa hoje, e uma correção de bug poderia ser lançada duas semanas depois, com consequências mínimas.

Profissionalmente, não gosto dessas respostas e deixaria claro internamente que o éter dessas situações estava ocorrendo.

Por fim, você não deve fazer nada que seu superior tenha dito explicitamente que não. Acredito que a melhor coisa a fazer em sua posição é criar um relatório de erro em qualquer banco de dados de rastreamento de erros que você tiver. Dessa forma, pelo menos todos estão cientes do problema e alguém com mais autoridade pode decidir o que fazer com ele.

Copie a função de buggy, aplique a correção, renomeie-a, talvez disfarce-a um pouco e chame-a.

Com base no seu comentário de dois bugs, sua melhor opção pode ser seguir a letra da lei, mas ignorar seu espírito.

Obviamente, há uma desvantagem da codificação de copiar e colar, mas parece que esse será o menor dos seus problemas.