A muchos de nosotros lo que más nos gusta es escribir código, incluso a veces escribir código nos gusta demasiado. Sin embargo, el código en si mismo no sirve para nada, lo que importa es resolver un problema y ese problema no queda resuelto hasta que la aplicación pasa a estar en producción.

Podemos pensar que una vez que el código entra en producción deja de ser problema nuestro y pasa a ser responsabilidad de los equipos de operaciones y soporte el mantener la aplicación funcionando y a los usuarios contentos, pero esto es sólo una verdad a medias.

Todo acaba fallando

Hacer que una aplicación siga funcionando durante el tiempo que estaba previsto (y, desgraciadamente, lo habitual es mucho más tiempo del que estaba previsto), es una tarea complicada. Al entrar en producción, todas esos maravillosos tests automatizados y controles de calidad se enfrentan a la cruda realidad de sistemas cambiantes en el tiempo y usuarios con ideas curiosas de cómo debe funcionar la aplicación.

Antes o después, empezarán a surgir problemas en producción, a veces imputables a nuestro desarrollo, a veces debidos a factores externos, pero el hecho es que afectan directamente al objetivo de nuestro de desarrollo: aportar valor.

Al principio, estos problemas quedarán en manos de las primeras líneas de soporte, ya sean soporte a usuarios o equipos de sistemas, pero irremediablemente llegará un momento en que un problema superará estas líneas y te lo acabarán escalando a ti.

Asume tu responsabilidad

He conocido gente que cuando se encontraba con un problema de este tipo lo único que hacía era poner excusas, culpar al usuario, al sistema operativo, a la topología de red… en definitiva, culpar cualquier cosa con tal de no asumir que podría haber un problema en su aplicación.

Esta actitud tan defensiva no es en absoluto productiva, sólo consigue enquistar el problema, enfadar a los usuarios y hacer perder tiempo y dinero a todas las partes implicadas.

En lugar de eso, es fundamental que cuando se produzca un problema seamos capaces de trabajar conjuntamente con el resto de equipos para buscar una solución. Al final, nosotros somos los que tenemos más herramientas para arreglar un problema porque nosotros somos los que podemos modificar el código fuente.

Prepárate para lo imprevisible

El primer paso para resolver un problema es poder diagnosticarlo de forma fiable, y ahí entramos nosotros. Es importante desde el primer momento diseñar y desarrollar aplicaciones que puedan ser inspecionadas y diagnosticadas.

Para ello, es necesario contar con herramientas que nos permitan conocer el estado actual del sistema y tener una visión histórica de lo que ha ido ocurriendo. Lo mínimo indispensable es contar con un log que nos permita registrar errores, aunque también podemos utilizar otras técnicas que nos permitan monitorizar en tiempo real el comportamiento de la aplicación, como contadores de rendimiento o sistemas desarrollados adhoc para ello.

Hoy en día hay multitud de herramientas para ayudarnos a ello, desde librerías genéricas como log4net hasta componentes específicos para aplicaciones web como elmah .

A la hora de generar la información de monitorización es importante distinguir entre la información relativa al sistema y la información relativa a la actividad del usuario.

Por una parte, podemos enfrentarnos a problemas derivados de cambios de versiones de componentes (bases de datos, sistemas operativos), deficiencias en sistemas externos, incremento de carga, etc., y en ese caso necesitaremos saber cómo se encuentra nuestro sistema, en qué entorno se está ejecutando y cómo se comportan los sistemas conectados a él.

Por otra parte, habrá ocasiones en que un usuario encuentre un problema que, a primera vista, parece imposible que se produzca. En estos casos, es fundamental poder trazar la actividad de ese usuario concreto, de manera que podamos reconstruir su forma de usar la aplicación y descubrir si realmente es un problema en la aplicación o un problema de uso (no hay que olvidar que la palabra del usuario no es siempre la fuente más fiable de información).

En ambos casos, contar con herramientas que permitan obtener esa información puede ser al diferencia entre que el equipo de soporte/operaciones sea capaz de resolver un problema, o que nos escalen una incidencia misteriosa que no tenemos ni idea de cómo resolver.

Es importante prestar atención a los mensajes de error generados por la aplicación, intentar preservar los stack traces y guardar la información de forma legible evitando llenar un log con cientos de mensajes inútiles, porque eso puede ser la diferencia entre vivir tranquilo y despertarte un sábado a las 3 de la mañana.

Conclusión

Puede parecer que después de poner al desarrollador como tester, ahora quiero también cargarle con el rol de soporte, pero nada más lejos de la realidad. Cada uno tiene su rol, pero hay que estar preparado para trabajar en equipo y resolver los problemas que puedan surgir.

Al diseñar o desarrollar una aplicación siempre hay que pensar en los usuarios, pero no debemos olvidar que un grupo de los usuarios de nuestra aplicación serán los equipos de operaciones y soporte, y que antes o después nosotros tendremos que ayudar a esos equipos, así que por la cuenta que nos trae, hagámosles (hagámosnos) la vida más sencilla.