Cuando se corrigen errores en código existente, es fácil caer en el hábito de buscar el «error» en el código y ajustarlo para evitarlo. Pero si la causa principal del problema era un error de diseño o un problema con el algoritmo, entonces añadir simplemente otra bandera o instrucción goto en el código es un enfoque erróneo. No solo has dejado intacta la causa principal, sino que ahora has hecho que el código sea más difícil de entender para el próximo ingeniero de software que tenga que resolverlo.
Entrénate para preguntarte «¿cómo habría resuelto este problema si yo fuera el programador original?». A continuación, observa la diferencia entre el enfoque de «hoja en blanco» y el que realmente tienes delante. Pero sé pragmático. No estoy sugiriendo que debas reimplementar una función porque tú y el autor tengáis un enfoque diferente. Considera este paso como un experimento mental. Tienes un caso de prueba que falla. El autor pasó por alto este caso. ¿Qué le llevó a pasar por alto este caso? Si el autor hubiera sabido de este caso, ¿en qué habría cambiado su enfoque? Este tipo de preguntas son muy valiosas cuando se analiza un código que básicamente funciona, pero que aún tiene algunos errores.
En nuestro caso, en lugar de añadir otro parámetro a una función interna, añadir otra variable automática que tenía que inicializarse correctamente en tres puntos de entrada diferentes al procedimiento principal y añadir código para probar esta nueva variable en un punto crítico, me di cuenta de que podíamos reparar el algoritmo cambiando el orden en el que se realizaban los subpasos. Una vez hecho esto, desapareció la necesidad de variables adicionales y casos especiales. El código final es, en realidad, mucho más fácil de entender que el código original, por no hablar del primer intento de reparación. Esto me da la confianza de que vamos por el buen camino. El caso de prueba que reproduce el problema demostró que tanto la solución original (demasiado compleja) como la solución revisada (simplificada) resuelven el problema. Ahora solo tenemos que asegurarnos de que no hemos estropeado nada más.
Dado que esta corrección se va a lanzar al mercado (es decir, ya está instalada en las instalaciones de los clientes), también realizaremos tres tipos de pruebas de regresión intensivas. Dos de ellas comprobarán el cumplimiento continuado del estándar POSIX (la corrección del error se encuentra en el código que implementa una función POSIX), y el tercer tipo de prueba es una prueba de regresión general a nivel del sistema.
Primero corrige el algoritmo. Una vez que el algoritmo sea correcto, ocúpate del código.