Pode parecer uma pergunta razoável, mas faz algumas suposições terríveis:
- linhas de código = esforço
- linhas de código = valor
- todas as linhas de código são iguais
Nada disso é verdade.
Por que uma correção que parece tão simples ao observar as alterações feitas levou dois dias para ser concluída?
- Porque o problema foi relatado com uma descrição vaga de como recriá-lo. Levei várias horas para obter uma reprodução confiável do item. Alguns desenvolvedores voltariam imediatamente para a pessoa que estava relatando o problema e precisariam de mais informações antes de investigar. Tento fazer o máximo possível com as informações fornecidas. Eu sei que alguns desenvolvedores não gostam de ter que corrigir bugs, e fazem o que podem para sair disso. Afirmar que não há o suficiente é uma ótima maneira de parecer que você está tentando ajudar, mas não precisa fazer nada. Sei que relatar erros pode ser difícil e sou grato por quem o fizer. Quero mostrar apreço pelos relatórios de erros, tentando fazer o máximo possível com as informações fornecidas antes de solicitar mais detalhes.
- Como o problema relatado estava relacionado à funcionalidade, não estou familiarizado. O recurso que ele tinha a ver era algo que eu raramente uso e não é algo que eu já usei em grandes detalhes. Isso significava que demorei mais do que o necessário para entender como usá-lo e as nuances de como ele interage com o software com o bug.
- Porque dediquei um tempo para investigar a causa real do problema, não apenas analisando os sintomas . Se algum código estiver gerando um erro, você pode envolvê-lo em uma instrução try..catch e suprimir o erro. Sem erro, sem problema. Certo? Desculpe, tornar o problema invisível não é o mesmo que corrigi-lo. "Engolir" um erro pode facilmente levar a outros efeitos colaterais inesperados. Eu não quero ter que lidar com eles em um ponto no futuro.
- Porque investiguei se havia outras maneiras de chegar ao mesmo problema, não apenas as etapas de reprodução relatadas . Um conjunto de etapas de reprodução pode facilmente fazer com que o erro pareça estar em um só lugar, quando na verdade pode ser mais profundo. Encontrar a causa exata de um problema e analisar todas as maneiras de chegar lá pode fornecer informações valiosas. Informações como, por exemplo, como o código é realmente usado, onde pode haver outros locais com possíveis problemas (outros?) Que precisam ser resolvidos ou podem mostrar inconsistências no código que significam que um erro é causado (ou tratado) em um caminho de código mas não outro.
- Porque reservei um tempo para verificar se havia outras partes do código que poderiam ser afetadas de maneiras semelhantes . Se um erro levou ao bug, o mesmo erro também poderia ter sido cometido em outra parte da base de código. Agora é um ótimo momento para verificar.
- Porque quando encontrei a causa do problema, procurei a maneira mais simples de corrigi-lo, com risco mínimo de introdução de efeitos colaterais . Não quero a correção mais rápida possível. Quero uma correção que provavelmente não cause confusão ou outros problemas no futuro.
- Porque testei a alteração completamente e verifiquei que ela solucionava o problema para todos os diferentes caminhos de código que foram afetados . Não quero contar com outra pessoa para testar se o que fiz foi correto. Não quero que um bug seja encontrado no futuro e que eu precise voltar a esse código quando seguir em frente. A troca de contexto é cara e frustrante. Ter um testador dedicado a olhar para a "mesma" mudança novamente é algo que eu quero evitar sempre que possível.
Eu não gosto de ter que corrigir bugs. Em parte porque podem parecer o resultado de uma falha anterior da minha parte. A outra razão pela qual não gosto de consertar bugs é que prefiro trabalhar em coisas novas.