Una técnica sencilla para crear programar mejor: Unhappy Paths

👉 Original de Ryan O’Neill: A simple technique for more reliable software

Por un software más confiable ¶

La construcción de software confiable a menudo evoca imágenes de extensas pruebas y complejas infraestructuras de respaldo. Sin embargo, existe una técnica sorprendentemente simple que puede marcar una gran diferencia: tratar los caminos infelices (unhappy paths) como casos de uso de primera clase.

La ilusión del camino feliz ¶

Nos encanta el camino feliz. Es ese escenario ideal donde todo funciona según lo planeado, sin errores ni imprevistos. Sin embargo, esta preferencia por lo ideal nos puede cegar ante la realidad de que el software, en su interacción con el mundo real, se enfrenta a innumerables situaciones inesperadas. Ignorar estas rutas menos ideales es prepararse para el fracaso.

Tratando los caminos infelices como primera clase ¶

La técnica es engañosamente simple y se desarrolla en varios pasos:

1. Identificación de componentes críticos ¶

El primer paso es reconocer los aspectos más críticos de tu servicio. Aquellos que, si fallan, tienen el mayor impacto negativo. Por ejemplo, en un servicio que gestiona cuentas de ahorro, el pago puntual y correcto de intereses sería un componente crítico.

2. Imaginando escenarios de fallo ¶

Una vez identificados los componentes críticos, el siguiente paso es prever todos los modos posibles en que estos podrían fallar. Este ejercicio de imaginación debe centrarse exclusivamente en el cómo podría fallar algo, evitando el porqué. Por ejemplo: “Hubo un error y el trabajo para enviar pagos no se ejecutó”.

3. Razonamiento a través de una solución ¶

Para cada escenario de fallo, es crucial razonar cómo se podría recuperar el sistema. Este proceso revela áreas que necesitan automatización o herramientas específicas. Las soluciones pueden variar desde recuperaciones automatizadas, ideales para sistemas auto-reparables, hasta intervenciones manuales para casos más complejos.

Priorización y ejecución ¶

El resultado de este ejercicio es una lista de brechas que necesitan ser cerradas. Al igual que con cualquier proyecto de software, estas necesidades deben priorizarse, estimarse y ejecutarse.

Conclusión ¶

Adoptar este enfoque no solo mejora la fiabilidad del software sino que también prepara al equipo para manejar fallos de manera más efectiva. En el mejor de los casos, se logra un sistema robusto y confiable. En el peor, se tiene un registro de casos de fallo potenciales y opciones de remedio listas para ser implementadas cuando sean necesarias, idealmente no a las 3 a.m. de un domingo.

Este método, por su simplicidad y eficacia, debería ser una herramienta estándar en el arsenal de todo desarrollador de software. La próxima vez que te enfrentes a la planificación de un nuevo proyecto, recuerda que el camino hacia un software confiable pasa por dar prioridad a los caminos infelices tanto como a los felices. Happy Hacking.

Resumen ¶

Ryan O’Neill, ingeniero, propone una técnica sencilla pero efectiva para construir software más fiable, centrada en tratar los caminos infelices o casos de fallo como casos de uso de primera clase. Describe un proceso de cuatro pasos para identificar, imaginar escenarios de fallo, razonar soluciones y priorizar ejecuciones para mejorar la confiabilidad del software.

Ideas ¶

• Los ingenieros prefieren los “caminos felices”, pero los casos de fallo son igualmente importantes.
• Tratar los casos de fallo como casos de uso de primera clase mejora la fiabilidad del software.
• Identificar las partes críticas del servicio es el primer paso para construir un software fiable.
• Imaginar escenarios de fallo ayuda a prepararse para solucionar problemas.
• La recuperación automática es la forma más preferible de manejar fallos.
• La recuperación manual y la depuración manual son menos preferibles pero necesarias.
• La documentación y la capacitación en herramientas administrativas son cruciales para la recuperación de fallos.
• Priorizar y ejecutar soluciones a fallos identificados refuerza la robustez del sistema.

Citas ¶

• “Para construir software fiable, tienes que sentirte cómodo con los caminos infelices.”
• “Imagina todos los modos en que tu parte crítica podría fallar.”
• “Lo más preferible: Recuperación automatizada.”
• “Todavía bueno: Recuperación manual.”
• “Lo menos preferible: Depuración manual.”
• “Te quedarás con una serie de huecos que necesitan ser tapados.”

Hábitos ¶

• Identificar rápidamente las partes más críticas de un servicio.
• Imaginar activamente escenarios de fallo sin concentrarse en el porqué.
• Priorizar la recuperación automatizada sobre la manual.
• Documentar herramientas y procesos para la recuperación de fallos.
• Capacitar a los nuevos empleados en el uso de herramientas administrativas.
• Priorizar y ejecutar la solución de fallos como cualquier otro proyecto de software.

Datos ¶

• Los fallos y casos de borde ocurren menos frecuentemente que los caminos felices, pero son críticos para la fiabilidad del software.
• La mayoría o todos los mecanismos necesarios para la recuperación de fallos probablemente no existan inicialmente.
• La recuperación automática, manual y la depuración manual son categorías clave para manejar fallos.

Referencias ¶

• docs.new como herramienta para abrir un documento en blanco y comenzar el proceso.

Recomendaciones ¶

• Tratar los casos de fallo como casos de uso de primera clase desde el inicio del desarrollo de software.
• Invertir en automatización y herramientas para la recuperación de fallos.
• Documentar y capacitar en el uso de herramientas para la recuperación de fallos.
• Priorizar la solución de fallos identificados para fortalecer la confiabilidad del sistema.
• Considerar la auditabilidad y la depurabilidad como aspectos clave en el diseño del sistema.

Si te gusta este tipo de contenido recibe uno nuevo cada semana a través de nuestra newsletter.