Regla N°2 de la Ingeniería de Software: Va a fallar

Si no falla es que no se usa…

Es imposible determinar si cierto software continuara funcionando en un futuro, porque las condiciones en las que se verá envuelto son impredecibles (actualizaciones de software con el que convive, actualizaciones de hardware… incluso la fecha y hora del ordenador). Si bien es cierto que podría decirse que la informática es determinista, el costo de determinar todas las opciones posibles, es demasiado alto.

Muchos de los primeros problemas que nos encontramos son al pasar de un ambiente de desarrollo, donde todo funciona, a otro ambiente de productivo donde parece que cada paso que damos en un problema a corregir.

Hay que evitar actitudes optimistas con respecto a la posibilidad que ocurran fallos, puesto que es muy probable que estos ocurran, por otro lado considerar que el usuario del sistema hará un uso “lógico” o coherente de este, es un desatino, generalmente nos sorprenderá descubriendo errores, que nunca se nos hubieran pasado por la cabeza.

Una vez más la visión correcta es aceptar que los fallos van a ocurrir e intentar establecer mecanismos para mitigar su impacto.

Algunos de estos mecanismos son:

• Poseer un ambiente de pruebas, semejante al ambiente de producción, pero que no tengas ninguna afectación real en las operaciones, además de estar completamente aislado del ambiente de desarrollo.
• Asegurar que tenemos trazabilidad de los errores (esto es que podamos reproducir el camino que se siguió para generar el error). Esta es una de las más difíciles y opacas, con lo que de antemano debemos prever esta situación y diseñar nuestro software para tal efecto.
• Mantener el código sencillo, en base a estándares, que sea fácilmente comprensible por el equipo que está trabajando actualmente con el codigo (no solo por el que genero el código).
• Usar herramientas de control de versiones. Frecuentemente una “pequeña” modificación de código genera “desastrosos” resultados en nuestras operaciones, es importante poder localizar fácilmente estos cambios.
• Creación de pruebas unitarias, que nos ayuden a probar de forma automática y completa todos los elementos de un sistema (aunque sea por separado), evidentemente esto tiene que venir de la mano de una arquitectura, cuyo diseño nos permite probar el sistema de forma unitaria.

Un último consejo, “No repitas código”, a veces me he encontrado con inmensos bloques de código completamente iguales, salvo algún pequeño detalle. Es necesario estructurar correctamente nuestro software, y evitar la duplicidad del código (mediante funciones, herencia o patrones de software), porque basándonos en la regla “Va a fallar”, cuando más código igual tengamos en nuestras aplicaciones, mas tendremos que trabajar para repararlo (con la casi certeza que no lo vamos a corregir en todos los lados donde esta duplicado).