Depuración de código

Lejos de ser la actividad mas entretenida del mundo, la depuración de código es quizá, una de las mas habituales de los desarrolladores. No porque quieran, sino porque es un hecho de la vida. Como decía un grande, "si depurar es sacarle los bichos a los programas, programar es ponerselos".

Entonces, supongo que sería bueno establecer una formula algo práctica para hacer de esta tarea una actividad lo menos dolorosa posible. Y no estoy hablando de cuestiones tecnológicas, sino que de sencillas estrategias para encontrar los problemas lo antes posible, y seguir así, haciendo cosas mas entretenidas.

Me resulta muchas veces increíble ver como desarrolladores, al encontrar errores, lanzan su brazos al aire, quizá echan una mala palabra, y luego de criticar al sistema operativo, o al jefe de proyecto, o quien quiera que se les ocurra, no tienen idea de que ocurre en el sistema. Le entregan una mirada en blanco al monitor, y dicen "todo mal". Además, no saben que hacer.

La estrategia que sugiero es la mas sencilla del mundo y tal vez la menos usada. "Redux a minimum". O esa, reducir el problema a la parte mas sencilla, y ojalá hacia una que sí funcione.

Por ejemplo, si estoy haciendo un proyecto de integración, y nada aparentemente funciona, lo mejor es comenza por las interfaces salientes. Si eso funciona, tomar un paso adelante y ver si las transformaciones hacia esa interfaz andan, etc.

Si estoy haciendo un sitio web, quizá lo principal para ver "donde se cae", es que exactamente está funcionando. Por obvio que suene, lo que no funciona, es donde deja de funcionar.

O sea, llegar al lugar donde conozco, para así resolver lo que si conozco.

Para esto, es muy útil las siguientes prácticas:

1. Utilizar el depurador siempre que escribo código, para ver si mi código efectivamente hace lo que pienso que hace.
2. Tener siempre en mente (y esto lo aprendí de un analista argentino) siempre la parte teórica del asunto, para así poder armar hipótesis de lo que ocurre cuando algo no ocurre como esperamos.
3. Mantener la calma y revisar todo, aún lo que uno está seguro que debería estar.
4. Utilizar herramientas como NTEST, para hacer pruebas unitarias. Usualmente cuando algo se cae, es porque hay algo fundamentalmente incorrecto, y estas herramientas son perfectas para encontrar estas fallas.

Ah, y por último, creo que es una excelente práctica de las empresas colocar a los novatos a corregir errores como primera tarea. Así logramos dos objetivos inmediatos, primero, consiguen experiencia y conocimiento aprendiendo los sistemas ya existentes, y segundo, aprender todas las formas de que las cosas fallan, para así no volver a repetirlas.