Principio de fallo temprano

Los sistemas no deberín fallar, y las aplicaciones no deberían romperse. Eso es lo que todo el mundo quiere. Sin embargo en ocasiones fallan, se quedan colgados y se rompen; asi que debemos intentar evitar que eso succeda.

Existen varios enfoques para prevenir los errores de software:

• Posponer la gestión del fallo.
• Proporcionar un flujo alternativo cuando se produzca el fallo.
• Silenciar el fallo y continuar.

Sin embargo este es un principio del desarrollo de software que dice justamente lo contrario: Falla rápido, y no busques soluciones.

Que es el Fallo temprano

Los seres humanos solemos cometer errores, y el software suele tener bugs. De hecho, el único código que no tiene bugs es el código que aún no se ha escrito.
¿Que podemos hacer entonces?
Evitar que algo acabe fallando, pero sin solucionar el fallo no resuelve nada. Al proceder de esa forma, lo único que se consigue es ocultar el error. Y cuando más tarde un problema en llegar a la superficie, más dificil y costoso será localizarlo y solucionarlo.
Pensemo que el hecho de que una aplicación tenga un fallo no es peor que pueda pasar; e incluso puede ser algo que apenas tenga impacto. Hay cosas mucho más graves que un error al intentar leer un fichero: interbloqueos en base de datos que paran todo el sistema, calculos mal realizados que se guardan y se procesan, información incosistente que se almacena, registros borrados o no recuperables. Si una parte del sistema falla, justo antes de que ocurra uno de esos problemas graves, realmente estaremos de suerte.
Eso es el motivo por el que el principio de fallo temprano nos anima a generar un fallo lo "antes posible": si algo falla, entonces debemos generar un fallo inmediatamente y de la manera más visible posible. Si hay algo inusual, o inesperado; generamos un fallo, en lugar de usar flujos alternativos con soluciones "por defecto".

¿Porqué fallo temprano?

Aplicando está técnica, los bugs y los fallos apareceran mucho antes en el proceso de desarrollo, con lo que:

• Los bugs se pueden detectar antes, son más fáciles de reproducir, y más fáciles de solucionar.
• Los bugs están ocados en capas más interiores, con menos dependencias, y debería ser más sencilla su solución.
• La mayoría de los bugs deberían ocurrir durante el desarrollo, con lo que hay menos bugs en producción.
• Se reduce el coste de bugs y fallos.

Cuanto más tiempo tarde un bug en aparecer, más tiempo y coste llevará corregirlo.

¿Comó podemos aplicar el principio de fallo temprano?

Hay muchas prácticas del desarrollo ágil que hacen uso de los principios de fallo temprano:

• Con TDD (Test-driven development): Es necesario escribir de antemano tests que den cobertura a todas las clases, y a todos los requisitos conocidos. Se están validando bugs en unidades de código muy pequeños.
• En integración continua: se exigue a los desarrolladores que integren el trabajo local en los repositorios constantemente. Para cada integración se verifica mediante una compilación, y una batería de pruebas automáticas, que permite ver problemas cada poco tiempo.

Otros ejemplo de fallo temprano:

• Si falta una variable de entorno o un parámetro de entrada, en lugar de arrancar el sistema usando alguna técnica que de respaldo al valor que falta (por ejemplo con valores por defecto); el sistema debería fallar, parar el arranque, y notificar el error, para permitir que se solucione el problema de configuración.
• Cuando un cliente envia una petición con algún parámetro no válido, en lugar de hacer una corrección silenciona del paramétros y continuar con la petición; se debería generar un error que haga que el cliente pueda solucionar el problema lo antes posible.
• Las excepciones no se deben anular en silencio. Unicamente se debería capturar una excepción cuando el código que la captura se encarga de realizar algún tipo de operación para controlarla. En cualquier otro caso, deberíamos dejar que las excepciones se propagen hacía arriba, dejando que la aplicación falle si no hay ningún manejador que sepa interceptar dicha excepción.