Normalmente cuando hablamos de arquitectura de software pensamos en muchísimas cosas relacionadas con el tema y que normalmente son parte de un lenguaje “común” que prácticamente todos los desarrolladores de software manejamos y conocemos. Sin embargo, existen varios temas que por distintas razones no trabajamos o no nos gusta trabajar con el mismo ahínco con el que trabajamos tareas tales como la lógica de negocio, la capa de acceso a datos, las entidades y los servicios. Uno de estos temas es el manejo de errores.
El Error –> un asunto de perspectiva
Contrariamente a lo que uno ve en temas de arquitectura; donde cada empresa tiene su propio “sabor” de lo que debería ser una arquitectura, hay algo que por lo general es muy estándar: la forma de presentar el error al usuario final –> a través de un MessageBox. Esto es algo casi endémico e incluso vemos desarrolladores tratando de implementar algún tipo de MessageBox en una aplicación Web para presentar un error, sin embargo; el tema central –> el como manejo el error –> se controla a un nivel muy básico e incluso en muchas casos no se trabaja.
Esto se da por varias razones, pero la principal es la falta de interés del desarrollador por hacer algo con la excepción –> normalmente esta enfocado en que el software haga lo que tiene que hacer lo antes posible. A la mayoría de los desarrolladores les parece suficiente con presentar un message box y con loguear el error en el EventViewer –> en el mejor de los casos. Esta falta de esfuerzo a la hora de manejar errores de forma adecuada crea una falsa sensación de inseguridad en el usuario final del sistema, porque normalmente termina pensando que el sistema es más malo de lo que realmente es –> Así devs, aunque no nos guste, muchos usuario finales consideran que mucho del software que ellos usan no sirve y está mal hecho. Esto quiere decir, que nosotros mismos le estamos facilitando esta percepción al usuario final, ya que podríamos decir que por nuestra falta de esfuerzo a la hora de manejar los errores el usuario final, termina pensando que nuestro sistema no funciona.
¿Qué debo hacer?
Sin duda alguna darle la importancia que merece el tema. Personalmente considero que no se deben retornar excepciones de sistema al usuario final, ya que esto lo confunde en una situación en donde normalmente deberíamos hacerle la vida más simple. La idea es más bien crear un framework de excepciones de negocio donde existan excepciones creadas por nosotros con un perfil de negocio y las cuales puedan ser mapeadas o convertidas a partir de una excepción de sistema.
Este módulo de manejo de excepciones recibirá y convertirá excepciones de sistemas en excepciones de negocios. Estos mapeos se pueden guardar en diferentes tipos de repositorios, ya sea un documento XML, una base de datos, un archivo de texto con un formato CSV, etc. La idea es que este mapeo sea tan granular como se pueda, ojala por módulo y por operación. Por ejemplo, no debería devolver la misma excepción de negocios un error de InvalidOperationException provocado en el módulo de pago del POS a recibir esta excepción en el módulo de manejo de oportunidades de venta en el CRM.
El Logging
Otro punto importante es que hacer con esta excepción cuando algo ocurre. ¿ La pongo en el event viewer? la guardo en un documento XML. De acuerdo a mi experiencia, la búsqueda de errores es un verdadero dolor de cabeza para las empresas y por lo general, se tarda más encontrando el error que reparando el mismo. Es por esto que se tiene que buscar una forma centralizada de loguear los errores. Normalmente en una arquitectura distribuida esto se logra utilizando el visor de eventos del servidor y las características de seguimiento de estos servidores de aplicaciones como por ejemplo el Windows AppFabric. Cuando se tiene la posibilidad de tener un servidor EAI o ESB como Biztalk Server podemos utilizar este servidor como repositorio de errores para poder tener todos los errores centralizados y así poder tener una mejor administración de los mismos.
A nivel local se debe de usar una forma de logging sencilla que permite llevar el control del lado del cliente. Para esta tarea se puede utilizar NLog, o el Logging application block del grupo de patterns and practices. Ambos pueden ser utilizados a nivel de cualquier capa e incluso en combinacion con los motores de seguimiento mencionados anteriormente.
No hay comentarios:
Publicar un comentario