De todos es sabido que los errores en el software son el pan nuestro de cada día. Alguna de las aplicaciones con las que nos toca trabajar dan más problemas que otras, y lo más normal es que si una aplicación se mantiene viva, con constantes actualizaciones y mejoras, los problemas vayan surgiendo a medida que se añaden nuevas funcionalidades. Por no hablar por supuesto de nuevas aplicaciones, recien salidas del horno, en las que tras una arquitectura moderna y robusta, puede esconderse una falta de testeo de algunos módulos o funcionalidades, o simplemente algunos descuidos de programación que aíºn no ha degenerado en error ya que para explotar necesitan verse inmersas bajo una serie de condicionantes que en entornos de desarrollo es difícil simular.
Y estoy hablando de errores, de errores de programación, típicos mensajes de alerta, con nuesto querido símbolo de admiración, o su triangulito… no de errores provenientes de una mala toma de requerimientos (modulos que no fallan pero no hacen lo que se supone que tenían que hacer). Petadas, reventadas, bugs… ya sabéis de lo que hablo.
Sobre prevención de errores hablaremos otro día, pero… ¿cómo resolvemos los errores de software una vez se han producido?
Si tenemos suerte y nuestro Proyecto cuenta con un Plan de Riesgos en el cual se ha contemplado el riesgo de errores en el software y se ha documentado cuales son los pasos que debemos seguir en caso de que se produzca un error… tendremos bastante ganado. Vamos a suponer que no es así, para hacer el “más difícil todavía”.
La posibilidad de resolver un error comienza cuando este se produce (obvio), lo que no es tan obvio es que debemos disponer de medios para detectar el error lo antes posible, cosa de la que a veces nos olvidamos. “Bueno, si falla ya llamarán”. “No ha llamado nadie en toda la mañana, eso es que va bien”. ¿Por qué debemos esperar a la llamada de un usuario para ponernos en marcha? ¿No sería mucho mejor que una vez se ha producido un error, la propia aplicación sea capaz de enviarnos una alarma al equipo de trabajo, y así poder ponernos a investigar prácticamente en el acto? Que bonito sería que antes de que llamara el usuario llamarle tíº. Hola buenas tardes señor Fulanito, hemos observado que ha surgido un error en la Aplicación durante el proceso de blablabla, le informamos que tenemos el error controlado, que no ha afectado a la transacción que estaba llevando a cabo, y que tenemos ya a una persona resolviendo la incidencia. O… que te llamara el usuario… Ah si, buenas tardes sr Menganito, somos conocedores del error que se le ha producido en la aplicación, se ha realizado un análisis del mismo, y visto que su nivel de importancia es medio, y no produce ningíºn bloqueo en la aplicación, hemos postpuesto la publicación del parche a la primera hora de mañana, para así juntarlo con otras mejoras que teníamos pendientes.
Qué diferencia eh. Y no es tan difícil conseguir que una aplicación mande un SMS o un E-Mail cuando se ha producido una excepción en la aplicación.
Y para finalizar unas cuantas frases.
“Los errores de software desprestigian a la empresa, desprestigian al producto, desprestigian al grupo de trabajo y desprestigian al programador. Además, cabrean.”
“La confianza del usuario en un producto es inversamente proporcional al níºmero de errores generados por la aplicación, multiplicado por la importancia de los mismos (y añadiría también por aquí algo sobre la media de la distancia de tiempo entre errores)”.
“Esta claro que no se puede tratar igual la gestión de errores de sistemas críticos como el de una central nuclear o un cohete espacial, pero eso no quiere decir que nos tengamos que olvidar de la gestión de errores de un simple editor de texto. Siempre que lo queramos vender, claro.”
Seguimos en la siguiente parte.
Saludos.
Miguel.