¿Otras personas corrigen errores cuando los ven, o esperan hasta que se producen bloqueos / pérdida de datos / personas mueren antes de arreglarlo?
Ejemplo 1
Customer customer = null;
...
customer.Save();
El código es claramente incorrecto, y no hay forma de evitarlo: está llamando a un método con una referencia nula. Sucede que no se bloquea porque Saveno tiene acceso a ningún dato de instancia; entonces es como llamar a una función estática. Pero cualquier pequeño cambio en cualquier lugar puede causar de repente un código roto que no se bloquea: comenzar a fallar.
Pero tampoco es inconcebible que corregir el código:
Customer customer = null;
...
customer = new Customer();
try
...
customer.Save();
...
finally
customer.Free();
end;
podría introducir un choque; uno no descubierto a través de pruebas unitarias con cobertura completa y pruebas manuales de usuario.
Ejemplo 2
float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);
La gente que sabe la física reconocerán que se supone que debe ser R 2 en el denominador.
El código está mal, está absolutamente mal. Y sobreestimar la velocidad hará que los retrocohetes disparen demasiado pronto, matando a todos los ocupantes de la nave espacial.
Pero también es posible que quizás sobreestimar la velocidad esté enmascarando otro problema: las bolsas de aire no pueden desplegarse mientras el transbordador se mueve demasiado rápido. Si de repente arreglamos el código:
float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);
Ahora la velocidad es precisa y, de repente, las bolsas de aire se están desplegando cuando no deberían.
Ejemplo 3
Aquí hay un ejemplo que tuve recientemente, comprobando si una cadena contiene caracteres no válidos:
if (StrPos(Address, "PO BOX") >= 0)
{
//Do something
}
¿Qué pasa si resulta que hay un error en la Do somethingrama? Arreglando el código obviamente incorrecto:
if (StrPos("PO BOX", Address) >= 0)
{
//Do something
}
Corrige el código, pero introduce un error.
A mi modo de ver, hay dos posibilidades:
- arregla el código y te culpan por romperlo
- espere a que el código se bloquee y se le culpe por tener un error
¿Qué haces políticamente?
Ejemplo 4 - El error del mundo real de hoy
Estoy construyendo un objeto, pero llamando al constructor incorrecto:
Customer customer = new Customer();
Resulta que el constructor "sin parámetros" es en realidad un constructor parametrizado desde más atrás en la cadena de herencia:
public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)
Llamarlo es un error, ya que omite todos los constructores posteriores.
Podría cambiar el linaje del objeto para no exponer un constructor tan peligroso, pero ahora tengo que cambiar el código a:
Customer customer = new Customer(depends);
Pero no puedo garantizar que este cambio no rompa nada. Al igual que mi Ejemplo 1 anterior, tal vez alguien, en algún lugar, de alguna manera, bajo algunas condiciones esotéricas, depende de lo construido Customerpara ser inválido y lleno de basura.
Tal vez el Customerobjeto, ahora que está construido correctamente , permitirá que se ejecute un código que nunca antes lo hizo, y ahora puedo obtener un bloqueo.
No puedo apostar la vida de tu esposa.
Y puedo probarlo desde aquí hasta el martes, no puedo jurar por la vida de tu hija que no introduje una regresión.
¿Yo:
- ¿Arreglar el código y ser culpado por romperlo? o
- ¿Dejar el error y ser culpado cuando el cliente lo encuentra?