¿Quién no se ha encontrado una «burrada» al revisar el código de un proyecto o el funcionamiento de un programa y ha puesto el grito en el cielo?
Especialmente cuando el proyecto ya debería estar finalizado (o supuestamente ya lo está).
¿Qué hacer al respecto?
Esto nos ha ocurrido recientemente revisando y modificando el código de un proyecto para un cliente. Había un programador que evidentemente no sabía ni siquiera unir dos cadenas de caracteres en el lenguaje del proyecto (C++) y usaba otra operación mucho más compleja y costosa para ello.
Aunque es demasiado tarde para corregir ese punto en concreto en ese proyecto (sin modificar cientos o miles de líneas de programa), ¿cómo se puede evitar este tipo de situación en un futuro?
Ese programador obviamente tiene algo que no ha entendido al aprender a programar o ha adquirido un vicio pensando que esa era la forma «correcta» o «buena» de hacerlo.
Además repetirá ese error una y otra y otra vez en este proyecto y en todos los siguientes. ¿Por qué? ¡Porque nadie verifica ni corrige al programador!
A nadie se nos ocurriría conducir un automóvil al que nunca hiciéramos una revisión. No se trata sólo de que nos lleve de un lugar a otro – también tenemos que asegurarnos de que funcionará correctamente, sin vicios ocultos, al hacerlo.
El remedio es instaurar una función de revisión y corrección de programadores como parte de nuestra función de control de calidad. Una máquina defectuosa no producirá buenos resultados. Un programador «defectuoso» tampoco.
Hay una forma relativamente sencilla de hacerlo, que son las revisiones de código por parte de programadores expertos, que a su vez haya sido corregidos adecuadamente y/o tengan gran capacidad y experiencia.
No se trata de hacer correcciones a fondo de cada línea, si no de revisar partes del código y ver fallos y vicios y corregir al programador. Esto eleva la calidad del programador y de los demás programadores revisados, poco a poco, hasta que los proyectos se finalizan con mucha más facilidad y menos problemas.
Ni lo habrá nunca. ¿Por qué no hay tiempo? Porque hay que ir corrigiendo de forma muy costosa los errores de los programadores (y analistas …).
¿Por qué no ir previniendo esta situación instaurando poco a poco esta función de corrección?
El único «riesgo» de hacer esto es que un día nos encontremos con un equipo de programación eficiente, que los proyectos salgan bien, al menos a nivel técnico, y que no tengamos a nadie a quién «echar la culpa» en ese equipo.
Pero quizás éste sea un «riesgo» aceptable …
