Ya que hemos tocado el tema de los registros (logs), hablemos de ellos con un poco más de detalle. Sí, este será un tema avanzado (marcado con un asterisco), pero ¿por qué no empezarlo ahora mismo?

Tanto en nuestra primera conversación sobre por qué se necesita el ejemplo “¡Hola, Mundo!”, como en la discusión reciente en la sección “Log, Forest, log!”, expresamos una idea importante:

Es crucial aprender primero a ver qué está haciendo el programa durante su funcionamiento.

¿Por qué es esto importante?

No solo porque nos permite comprender mejor cómo funciona nuestro programa.

Digamos que ya hemos escrito un programa funcional; se compiló con éxito, lo lanzamos y ¡está en ejecución (!). ¡Parecería un éxito! Podríamos eliminar todas las operaciones de registro que colocamos en el programa para entender qué sucede dentro de él.

¡Pero no es tan simple! El hecho es que nuestro éxito podría ser temporal. Sí, el programa funciona correctamente ahora, pero funciona correctamente con los datos de entrada que está recibiendo en este momento. ¿Qué pasa si surge una situación que lleve al programa a fallar porque no tuvimos en cuenta algún escenario?

Tomemos como ejemplo un sitio web de servicios gubernamentales. Supongamos que eres uno de los desarrolladores y creaste un formulario de registro de usuario. Lo diseñaste con campos de información personal estándar: nombre, apellido, fecha de nacimiento y dirección de correo electrónico. ¡Todo funciona! Los usuarios llegan, llenan el formulario, no hay quejas. Y de repente, llega una queja de un usuario de que al intentar llenar el formulario, la página del sitio web “se rompe”, aparece un mensaje de error y el usuario no puede continuar. Lo pruebas tú mismo, ingresas diferentes datos: ¡todo funciona! ¿Cuál es el problema?

Si tuvieras registros (logs), al revisarlos podrías ver que el programa falla cuando el campo “Apellido” se deja vacío. La lógica de validación esperaba que cada persona tuviera tanto un nombre como un apellido, pero el usuario —quizás siguiendo convenciones de nombres de países como Islandia o Indonesia— solo proporcionó un nombre único. Tu sistema no estaba preparado para este escenario. ¿Inesperado, verdad?

Mientras los datos de entrada coincidían con sus expectativas, el programa funcionó con éxito. Pero con cierta combinación de datos de entrada, todo salió mal. Y si no fuera por los registros, nos sería difícil entender qué causó específicamente la falla en nuestro programa.

Notas

  • Permítanme recordarles que casos como nuestro ejemplo del usuario con un solo nombre se llaman casos extremos (corner / edge cases).

  • En una situación real, un diseño de formulario adecuado tendría en cuenta las diversas convenciones de nomenclatura entre diferentes culturas.

  • Muchas culturas tienen tradiciones de nombres que no siguen el patrón “Nombre + Apellido” común en los países occidentales.