Esta definición es amplia. Mucha gente está en contra de la programación defensiva, pero esto es a menudo debido a los tipos de métodos que han visto propugnados por algunos como programación defensiva. La programación defensiva no debería ser vista como una forma de evitar el desarrollo dirigido por pruebas o como una forma de simplemente compensar los fallos y seguir adelante.
El «Fail Fast» no debe ser visto como una contrapartida a la programación defensiva. Todo cae bajo el mismo paraguas. ¿Qué son estos métodos, si no formas de anticipar que tu programa puede fallar, y prevenirlos, o bien formas de manejar esos fallos de forma adecuada?
La programación defensiva, en pocas palabras, consiste en programar con la intención de anticiparse a los posibles puntos de fallo. El objetivo es evitar esos probables problemas antes de que se produzcan.
Fallar rápido y en voz alta
En pocas palabras, fallar rápido y en voz alta significa que cuando se produce un error, lo hará tan pronto como sea posible, y alertará a quien deba alertar, en lugar de continuar silenciosamente en un estado de error que puede causar más problemas. Aquí hay un excelente artículo sobre el desarrollo de estilo fail-fast. La premisa de la metodología fail-fast es fallar cuando se adquiere una entrada que pueda comprometer el programa más tarde (o, más generalmente, entrar en un estado de fallo tan pronto como cualquier problema pueda ser detectado, en lugar de permitir que los datos malos viajen y un programa se ejecute sin comprobar, o peor, que los datos malos se almacenen en algún lugar). Esto es más útil cuando se trata de la entrada del usuario, o cuando se trata de la entrada que está llegando desde fuera del script, módulo, o incluso fuera de su sistema a través de una API. Un ejemplo de dónde se podría emplear esto sería una comprobación de valores no válidos o tipos de datos pasados a funciones.
Transacciones
Las transacciones son una característica de las bases de datos que permite agrupar las consultas, de modo que si una de ellas falla, todas lo hacen. Se trata de una implementación de ACID, sobre la que puedes leer más aquí. La idea es que agrupar múltiples consultas en un proceso puede ser a veces una solución más segura y estable, especialmente cuando las consultas dependen unas de otras. Los desarrolladores de PHP a menudo ignoran completamente las transacciones, o asumen que son innecesarias, pero cuando se interactúa con las bases de datos, un poco de programación defensiva puede recorrer un largo camino. Las transacciones se discuten en mayor profundidad en este excelente post, pero en pocas palabras, las transacciones le permiten ejecutar sus actualizaciones de MySQL, y luego comprobar los resultados antes de comprometer los resultados. Si está usando PDO (debería hacerlo), puede usar los métodos de PDO para comenzar una transacción, confirmar los resultados, así como retroceder. Además de la mencionada visión general de las transacciones, profundice en ellas con esta guía en profundidad.
Conclusión
De nuevo, estos son sólo consejos generales. Obviamente, cada uno de ellos tiene sus usos y cada uno tiene situaciones notables en las que no se utilizaría. Sin embargo, si tomas conceptos como estos y los trabajas en tus regímenes de desarrollo diarios, puede hacerte más eficiente en lo que haces. Y aunque este es un tema que se aplica más a los desarrolladores que están aprendiendo PHP actualmente, es un buen repaso de las prácticas para todos.
Si una sola cosa se saca de esto, especialmente por los desarrolladores más nuevos, es que usted debe programar a la defensiva – planear para la posibilidad de errores y equivocaciones. Manéjelos adecuadamente. No permita que los errores silenciosos progresen. Falla rápido. Pruebe su código. Si construyes aplicaciones robustas que comprueben y resuelvan los problemas, y anticipen y manejen los futuros, estarás haciendo que tus aplicaciones sean más fiables y, con suerte, estarás ayudando a crear una mejor experiencia de usuario entre bastidores.