Cuando se arreglan los errores en el código existente, es fácil caer en el hábito de encontrar el "error" en el código y ajustar el código para evitar el error. Pero si la raíz del problema fue un error de diseño, o un problema con el algoritmo, entonces sólo agregar otra bandera o declaración de "goto" en el código es el enfoque equivocado. No sólo has dejado la causa raíz intacta, sino que ahora has hecho el código 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 codificador original?" Luego mira la diferencia entre el enfoque de "hoja limpia de papel" y el que está realmente ahí delante de ti. Pero sé pragmático. Ciertamente no estoy sugiriendo que deberías reimplementar una función porque tú y el autor tienen un enfoque diferente. Tome este paso como un experimento de pensamiento. Tienes un caso de prueba que falla. El autor falló en este caso. ¿Qué la llevó a perderse este caso? Si la autora hubiera sabido de este caso, ¿cómo habría sido diferente su enfoque? Este tipo de preguntas son invaluables cuando se investiga 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, y añadir otra variable automática que tenía que ser correctamente inicializada en 3 puntos de entrada diferentes del 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 sub-pasos. Una vez que hicimos eso, la necesidad de variables adicionales y casos especiales desapareció. 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 estamos en el camino correcto. El caso de prueba que reproduce el problema demostró que tanto el arreglo original (demasiado complejo), como el revisado (simplificado) resuelven el problema. Ahora sólo necesitamos estar seguros de que no hemos roto nada más.
Dado que este arreglo se dirige a un lanzamiento de campo (es decir, uno que ya está instalado en las instalaciones del cliente), también ejecutaremos tres tipos de pruebas de regresión intensivas. Dos de ellas comprobarán la continua adherencia al estándar POSIX (la corrección de errores está en el código que implementa una función POSIX), y el tercer tipo de prueba es una prueba de regresión a nivel de sistema general.
Arregla el algoritmo primero. Una vez que el algoritmo sea correcto, ocúpate del código.
Empresa