fail fast fail early - significado - ¿Qué significa la expresión "Fallo temprano" y cuándo querría hacerlo?
fail faster significado (5)
"Fallo temprano" significa que el programa debe generar una excepción y dejar de funcionar si algo sale mal. (Se describe en la lista de consejos de Pragmatic Programmer como Crash Early )
En mi trabajo de bioinformática, tiendo a usar un enfoque de "falla temprana" porque mi mayor preocupación es garantizar la corrección. Por el contrario, Rails te permite ocultar fallos. Por ejemplo, el try Rails te permite llamar algo sobre un objeto, y no generará una excepción si ese objeto es nil . Supongo que esto se debe a que con los sitios web, garantizar que el programa siga funcionando es más importante que la corrección.
¿Qué significa la expresión "Fallo temprano" y en qué circunstancias es más útil este enfoque y cuándo evitaría el enfoque?
Esencialmente, fallar rápido (también conocido como fallar antes ) es codificar su software de tal manera que, cuando hay un problema, el software falla tan pronto y lo más visiblemente posible , en lugar de intentar proceder en un estado posiblemente inestable.
Fallar rapido
por Jim Shore
editado por Martin Fowler
http://www.martinfowler.com/ieeeSoftware/failFast.pdf...
Afortunadamente, existe una técnica simple que reducirá drásticamente la cantidad de estos errores en su software. No reducirá el número total de errores, al menos no al principio, pero hará que la mayoría de los defectos sean mucho más fáciles de encontrar.La técnica es construir su software para que "falle rápidamente".
Falla inmediata y visible.
Algunas personas recomiendan que su software sea robusto resolviendo los problemas automáticamente. Esto hace que el software "falle lentamente". El programa continúa funcionando justo después de un error, pero falla de maneras extrañas más adelante.
Un sistema que falla rápidamente hace exactamente lo contrario: cuando ocurre un problema, falla de manera inmediata y visible. Fallar rápido es una técnica no intuitiva: "fallar de forma inmediata y visible" parece que haría que su software sea más frágil, pero en realidad lo hace más robusto. Los errores son más fáciles de encontrar y solucionar, por lo que hay menos producción.
...
También tenga en cuenta el concepto relacionado de un iterador rápido de falla : un iterador que, después de ciertas modificaciones a la colección fuera del iterador, se lanza lo antes posible en lugar de proceder en un estado potencialmente inestable o no determinista.
Fallas tempranas encarna la idea de que cuando se crea un software, cuanto antes falla o si falla una prueba, o si encuentra un error, más fácil es corregirlo (y también es más barato). También se aplica a su modelo de negocio. Es mejor descubrirlo antes (en la versión beta, por ejemplo) que después de haberlo lanzado.
Significa: "Atrapar errores lo antes posible" . Si es posible, desea saber que están allí tan pronto como están allí =).
Cuanto antes se detecte un error, más barato será eliminarlo. Si pudieras conocer el error justo en el momento en que escribiste la línea de buggy, sería increíble. Sabría exactamente lo que pretendía hacer y tendría el mayor poder para eliminar ese error rápidamente.
Por otro lado, si solo atrapas el error un mes después, o después de que se libera, el daño es mucho mayor. Los usuarios ya tienen que lidiar con eso, no recordará lo que estaba pensando tan bien (o tal vez ya no estará trabajando para la compañía, por lo que alguien tendrá que averiguar cuáles fueron sus pensamientos).
Una vez tuve un programador junior oracle trabajando para mí que puso un bloque de excepción "ignorar todo" en todo su código para que nunca se vieran los errores. Esto inicialmente hizo que su código pareciera impresionante, pero: A) Los errores tardaron mucho más en encontrarlos; y B) Perdí toda (bueno, el 80% de mi) fe en sus habilidades después de eso.
Desde entonces, le he enseñado a la gente que esto es algo muy malo, ya que oculta los errores.
No confunda esto con un módulo de código capaz de hacer frente a entradas de baja calidad (como HTML, que tampoco es un XHTML válido en un navegador), ya que no es necesario que se produzcan fallos. Lo más probable es que causaron un fallo hace muchos años, pero la forma de resolverlo era hacer que el sistema asumiera suposiciones razonables sobre cómo recuperarse.