Fail Fast vs. Robustness

Question

Nuestro producto es un sistema distribuido. Los módulos en los que trabajo son bastante nuevos, bastante rigurosos, bien probados. Se desarrollaron teniendo en cuenta las mejores prácticas recientes. Otros módulos se pueden considerar como software heredado.

Mientras estoy atenta a todo lo que sucede dentro de los módulos de los que soy responsable, estoy bajo presión constante para trabajar con los datos incorrectos que me envían desde los otros módulos. En el fondo, soy un desarrollador principal "Fail Fast" y, como resultado, cuando surgen problemas, generalmente puedo eliminar la posibilidad de error en mis módulos. No se trata tanto de culpar, sino de ahorrar esfuerzos desperdiciados para perseguir insectos en los lugares equivocados.

Pero el argumento con el que siempre me enfrento es: "No podemos dejar que esto falle en la producción, el cliente espera que esto funcione, ¿por qué no soluciona este problema?". Y este sería un argumento para la solidez: ser liberal en lo que acepta, conservador en lo que envía.

También debo tener en cuenta que estos son en su mayoría problemas intermitentes. Los vemos en pruebas de integración, pero son difíciles de reproducir. El tiempo y la concurrencia están involucrados.

Estoy teniendo dificultades para equilibrar los dos principios. Parte de esto es mi preocupación de que si empiezo a permitir y propagar datos excepcionales, estoy invitando a problemas y no tendré tanta confianza en mi sistema. Pero no puedo argumentar en contra de mantener el sistema funcionando incluso si otros módulos me están enviando datos incorrectos. La razón por la que otros módulos no se solucionan es porque son demasiado complejos y frágiles, mientras que los míos aún parecen claros y seguros. Pero si no resisto la presión, mis módulos se cargarán lentamente con los mismos problemas que he estado rechazando hasta ahora.

Debo decir que el sistema no está "cayendo" en producción, pero mi módulo puede simplemente mostrar un error al operador y pedirles que se pongan en contacto con el soporte técnico. Un colapso sería un gran problema, pero si estoy informando el error claramente, ¿no es esto lo correcto? Sospecho que mis compañeros simplemente no quieren que el cliente vea ningún problema, punto. Pero mi módulo está rechazando datos de otros módulos dentro de nuestro producto, no de la entrada del cliente. Entonces me parece que simplemente no estamos abordando problemas.

Entonces, ¿tengo que ser más pragmático o mantenerme firme?

Answer 1

Gracias a todos. El caso que provocó esta pregunta terminó bien, y en parte gracias a las ideas que obtuve de las respuestas anteriores.

Mi reacción inicial fue seguir rápido, pero pensé en esto un poco más, y llegué a la conclusión de que una de las funciones de mi módulo es proporcionar un ancla estabilizadora al resto del sistema. Eso no significa necesariamente aceptar datos incorrectos, sino resolver problemas, aislarlos y manejarlos de manera transparente hasta que encontremos una solución.

Planeé agregar un nuevo controlador y una ruta de código para este caso, que se ejecutaría correctamente como si fuera un caso de uso especial que no se había documentado anteriormente.

Tuvimos una discusión donde reiteré la necesidad de tratar el problema en el límite, pero también estaba dispuesto a ayudar. Delineé mi plan al otro lado, porque sospechaba que mi posición era vista como excesivamente pedante, y que la solución se percibía como que yo solo tenía que desactivar la validación espuria de datos inofensivos, incluso si era incorrecta. Sin embargo, en realidad, la forma en que trabajo se basa en gran medida en los datos, así que expliqué por qué tiene que ser correcto y cómo el comportamiento es impulsado por él y cómo al adaptar estos datos implementaré una ruta de código especial.

Creo que esto dio peso a mi posición y condujo a una discusión más a fondo de la aversión de la otra parte a la fijación de los datos. Resultó que era más un cansancio lidiar con un sistema heredado propenso a errores que un obstáculo real. Había una solución relativamente simple, era simplemente aterrador hacer un cambio, una mentalidad bastante arraigada.

Pero habiendo expresado todos los desafíos y posibles soluciones, finalmente acordamos arreglar los datos, y hasta ahora parece que han resuelto nuestro problema. Nuestras pruebas de integración ahora están pasando de manera constante, pero también hemos agregado el registro y continuaremos supervisándolo.

En resumen, creo que para mí, la síntesis de ambos principios es que el fracaso rápido es esencial para los problemas de superficie. Pero una vez que salen a la superficie, la solidez significa proporcionar una ruta transparente para continuar la operación de una manera que no comprometa el sistema. Pude ofrecer eso, y al hacerlo, obtuve algo de buena voluntad del otro lado y obtuve los datos al final.

Nuevamente, gracias a todos los que respondieron. Soy demasiado nuevo para calificar los comentarios, pero aprecio todas las perspectivas presentadas.

Answer 2

Yo diría que depende de lo que ocurra si no se detiene. ¿Se procesa incorrectamente el cheque de alguien? ¿Se envía la orden incorrecta? Eso valdría la pena detenerse.

De ser posible, cómase y cómelo también; no informe el error al usuario, haga que el cliente acepte enviar informes de diagnóstico e informe cada falla. Informar al desarrollador (es) que posee el (los) módulo (s) de fallas para arreglarlos. Y por error me refiero a presentar un error en contra de ellos. O bien, si la gerencia no cree que valga la pena el costo de la reparación, no lo haga.

También escribiría pruebas unitarias contra aquellos módulos que fallen, especialmente si puede decir cuál fue la entrada original que provocó que generaran una salida incorrecta.

Sin embargo, lo que realmente se reduce a todo es lo que la persona que revisa tu desempeño desea de ti, especialmente después de que les expliques el problema por correo electrónico.

Answer 3

Eso es complicado. Si su módulo recibe datos incorrectos y está "bien" para que usted simplemente no haga nada con ellos y los devuelva, entonces le sugiero que escriba un registro de errores en lugar de mostrarle un error al usuario.

Answer 4

En pocas palabras, esto suena como "no revises por algo que no puedes manejar". El hecho de que esté detectando el error y pueda informarlo significa que no lo está propagando.Pero también significa que, dado que puede informarlo, tiene algún mecanismo para atrapar el error y, por lo tanto, puede manejarlo usted mismo, y corregirlo en lugar de informarlo.

Mente, supongo que su informe de error es más interesante que una excepción aleatoria que atrapó en algún lugar profundo del sistema. Pero incluso entonces, si es una excepción para la que está probando y está creando (es decir, comprueba si el denominador es cero y envía un error en lugar de simplemente dividir inadvertidamente por cero y captar la excepción más arriba), eso sugiere que bien puede tener una forma de corregir el problema.

Conclusión, necesita ambas cosas. Debe intentar que los datos sean tan libres de errores como sea práctico, pero también informe lo inesperado.

No creo que pueda cerrar con llave la puerta y cruzar los brazos diciendo "no es mi problema". El hecho de que provenga de "sistemas viejos y frágiles" no tiene sentido. Su código no es viejo, es un lugar frágil y claramente eficiente, en términos de todo el sistema integrado, para "arreglar" los datos, una vez que haya detectado el problema. Sí, los módulos antiguos continuarán a GIGO a otros sistemas menores, pero esos módulos antiguos combinados con su nuevo módulo son un todo cohesivo y conforman "el sistema".

El problema real típico aquí es simplemente la ecuación de tiempo/valor de escribir todo este código de reparación frente a las nuevas características. Ese es un debate diferente. Pero si tiene tiempo y sabe cosas que puede hacer para limpiar los datos entrantes, "sea liberal en lo que acepta" es una política sensata.

Answer 5

No entraré en los motivos, pero tiene razón.

En mi experiencia, los PHB carecen de la parte del cerebro necesaria para comprender por qué el fail fast tiene mérito y la "solidez" definida por do-whatever-it-takes-eat-errors-if-necessary es una mala idea . Es inútil Simplemente no tienen el hardware para asimilarlo. Tienden a decir cosas "está bien que hagas una buena observación, pero ¿qué pasa con el usuario?", Es solo su versión de think of the children, y señala el final de una conversión conmigo cada vez que aparece.

Mi consejo es defender su posición. Eternamente.

Answer 6

Comparto la preferencia/principio "fail fast". Sin embargo, no pienses en esto como un conflicto de principios, es más un conflicto de entendimiento. Su contraparte tiene algún requisito no expresado ("no mostrarle al usuario un mal momento") que implica algún requisito perdido. No tuvo la oportunidad de pensar/implementar este requisito de antemano, por lo que el requisito ha dejado un mal sabor de boca. Olvídese de este punto de vista, vuélvalo a abordar como un nuevo proyecto con un requisito fijo contra el que puede trabajar.

Quizás el mejor resultado es dar un mensaje de error como el que se muestra. Pero parece que lo implementó antes de que su homólogo lo aceptara, cuando tuvieron la opción de aceptarlo. La comunicación anterior sobre lo que estabas haciendo podría haber abordado algo así.

Tenga cuidado con la forma de evitar las ideas. Referirse constantemente a los otros sistemas "demasiado complejos y frágiles" podría estar frotando a las personas de la manera equivocada. Exprese simplemente que los sistemas son nuevos para usted y toman más tiempo para comprender. Dedique tiempo a entenderlos, para que no reduzca las expectativas de las personas sobre su capacidad.

Answer 7

Depende de la clase de error que esté recibiendo. Si la forma en que el sistema se está rompiendo significa que puede continuar sin alimentar datos erróneos a ninguna otra parte del sistema, debe hacer todo lo que esté a su alcance para trabajar con las aportaciones que se le den.

En mi opinión, aunque la pureza de los datos supera a los sistemas en funcionamiento, no puede permitir que los datos nocivos se propaguen a otros lugares y corrompan a otros sistemas.En la medida en que pueda dar masajes a los datos para que sean correctos y luego continuar, debe hacerlo con la teoría de que los datos son seguros y debe mantener el sistema funcionando ...

Me gusta pensar las cosas en términos de flujos de datos Transmitir datos erróneos contamina la secuencia completa, y eso es malo porque, al igual que la contaminación real, una gota puede echar a perder todo un río de datos (si un elemento es malo, ¿en qué otra cosa se puede confiar?). Pero igualmente malo es bloquear el flujo, no dejar pasar nada porque has detectado algo que puedes eliminar fácilmente. Filtralo y si todos en cada etapa también son filtros, obtienes datos claros y limpios en el otro extremo incluso si algunas impurezas comienzan en el medio.

Answer 8

La pregunta de sus pares es: "¿Por qué no evitar este problema"

Usted dice que es posible que detecta los datos erróneos, e informar de un error al usuario. Este es el enfoque normal: una vez que sepa que los datos que llegan a sus funciones son malos, debe fallar rápidamente (y esta es la recomendación de las otras respuestas que he leído aquí).

Sin embargo, su pregunta no especifica el dominio en el que está operando su software. Si sabe que los datos que ingresan son erróneos, ¿es posible que vuelva a solicitar esos datos? ¿Es realmente posible recuperarse de la situación?

Mencioné que el "dominio" aquí es importante. Entonces, si tiene una aplicación que muestra datos de video transmitidos, por ejemplo, y tal vez su señal inalámbrica es débil por lo que la transmisión está dañada, ¿debería el sistema "fallar rápidamente" y mostrar un mensaje de error? ¿O debería mostrarse una imagen más pobre y, de ser necesario, intentarse volver a conectar, dependiendo de la magnitud del problema?

Dependiendo de su dominio, es posible que detecte datos incorrectos y realice una segunda solicitud de los datos sin molestar al usuario. (Esto es claramente solo relevante en los casos en los que esperaría que los datos fueran mejores la segunda vez, pero usted dice que los problemas que está experimentando son intermitentes y posiblemente relacionados con la concurrencia) ...

Así, a prueba de fallas es bueno, y definitivamente es algo que debes hacer si no puedes recuperarlo. Y definitivamente no deberías propagar datos malos. Pero si puedes recuperarte, lo que en algunos dominios puedes, entonces fallar de inmediato no es necesariamente lo mejor que puedes hacer.