Outras pessoas corrigem bugs quando os veem ou esperam até que ocorram falhas / perda de dados / pessoas morrem antes de corrigi-lo?
Exemplo 1
Customer customer = null;
...
customer.Save();
O código está claramente errado, e não há como contornar - ele está chamando um método em uma referência nula. Acontece que não trava porque Save
não acessa nenhum dado da instância; então é como chamar uma função estática. Mas qualquer pequena alteração em qualquer lugar pode causar repentinamente código quebrado que não falha: começar a falhar.
Mas também não é inconcebível que a correção do código:
Customer customer = null;
...
customer = new Customer();
try
...
customer.Save();
...
finally
customer.Free();
end;
pode apresentar uma falha; um não descoberto através de testes de unidade com cobertura completa e teste manual do usuário.
Exemplo 2
float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);
As pessoas saberem física vai reconhecer que é suposto ser de R 2 no denominador.
O código está errado, está absolutamente errado. E superestimar a velocidade fará com que os retro-foguetes disparem muito cedo, matando todos os ocupantes da espaçonave.
Mas também é possível, talvez, superestimar a velocidade, mascarando outro problema: os airbags não podem ser acionados enquanto o ônibus espacial se move muito rápido. Se repentinamente corrigirmos o código:
float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);
Agora a velocidade é precisa e, de repente, os airbags estão sendo acionados quando não deveriam.
Exemplo 3
Aqui está um exemplo que eu tive recentemente, verificando se uma string contém caracteres inválidos:
if (StrPos(Address, "PO BOX") >= 0)
{
//Do something
}
E se houver um erro no Do something
ramo? Corrigindo o código obviamente incorreto:
if (StrPos("PO BOX", Address) >= 0)
{
//Do something
}
Corrige o código, mas introduz um erro.
A meu ver, existem duas possibilidades:
- corrigir o código e ser responsabilizado por quebrá-lo
- aguarde o código travar e seja responsabilizado por ter um bug
O que você faz politicamente?
Exemplo 4 - Bug do mundo real de hoje
Estou construindo um objeto, mas chamando o construtor errado:
Customer customer = new Customer();
Acontece que o construtor "sem parâmetros" é na verdade um construtor parametrizado mais adiante na cadeia de herança:
public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)
Chamar isso é um erro, pois ignora todos os construtores subseqüentes.
Eu poderia alterar a linhagem do objeto para não expor um construtor tão perigoso, mas agora tenho que alterar o código para:
Customer customer = new Customer(depends);
Mas não posso garantir que essa mudança não vá quebrar nada. Como no meu Exemplo 1 acima, talvez alguém, em algum lugar, de alguma forma, sob algumas condições esotéricas, dependa que o construído Customer
seja inválido e cheio de lixo.
Talvez o Customer
objeto, agora que ele esteja corretamente construído, permita a execução de algum código que nunca funcionou anteriormente, e agora eu possa travar.
Não posso apostar na vida da sua esposa.
E posso testar daqui até terça-feira, não posso jurar pela vida de sua filha que não introduzi uma regressão.
Eu:
- Corrigir o código e ser responsabilizado por quebrá-lo? ou
- Deixe o bug e seja responsabilizado quando o cliente o encontrar?