performance - winsorizada - tipos de robustez
Fallo rápido contra robustez (8)
Comparto la preferencia / principio de "falla rápido". Sin embargo, no piense en esto como un conflicto de principios, es más un conflicto de entendimiento. Su contraparte tiene algún requisito tácito ("no le muestre 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, vuelva a abordarlo como un nuevo proyecto con un requisito fijo en el que puede trabajar.
Tal vez el mejor resultado sea mostrar un mensaje de error como el que has mostrado. Pero parece que lo implementó antes de comprarle a su contraparte, cuando tuvieron la opción de aceptarlo. La comunicación anterior sobre lo que estaba haciendo podría haber abordado algo así.
Ten cuidado en cómo impides las ideas. Refiriéndose constantemente a los otros sistemas "demasiado complejos y frágiles" podría estar frotando a las personas de manera incorrecta. Exprese simplemente que los sistemas son nuevos para usted y demoran más en entenderse. Dedique tiempo a comprenderlos, de modo que no reduzca las expectativas de las personas sobre su capacidad.
Nuestro producto es un sistema distribuido. Los módulos en los que trabajo son bastante nuevos, bastante rigurosos y bien probados. Fueron desarrollados con las mejores prácticas recientes en mente. Otros módulos pueden ser considerados como software heredado.
Mientras estoy atento a todo lo que sucede dentro de los módulos de los que soy responsable, estoy bajo una presión constante para trabajar con los datos erróneos que me envían desde los otros módulos. En el fondo, soy un desarrollador de principios "Fail Fast" y, como resultado, cuando surgen problemas, generalmente puedo eliminar la posibilidad de error en mis módulos. No se trata tanto de la culpa, sino de ahorrar el esfuerzo desperdiciado en la búsqueda de errores en los lugares equivocados.
Pero el argumento al que 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 a favor de la solidez: sé liberal en lo que aceptas, conservador en lo que envías.
También debo señalar que estos son en su mayoría problemas intermitentes. Los vemos en las 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 comienzo a permitir y difundir datos excepcionales, estoy invitando a problemas y no tendré tanta confianza en mi sistema. Pero no puedo argumentar en contra de mantener el sistema en funcionamiento incluso si otros módulos me envían datos incorrectos. La razón por la que otros módulos no se están arreglando es que son demasiado complejos y frágiles, mientras que los míos todavía 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á "fallando" en producción, pero mi módulo puede simplemente mostrar un error al operador y pedirle que se ponga en contacto con el soporte. Un choque sería un gran problema, pero si informo 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 opinión del cliente. Entonces me parece que no estamos abordando los problemas.
Entonces, ¿necesito ser más pragmático o mantener mi posición?
Depende de la clase de error que esté recibiendo. Si la forma en que el sistema se está rompiendo significa que puede seguir sin alimentar datos erróneos a otras partes del sistema, debe hacer todo lo posible para trabajar con cualquier entrada.
En mi opinión, aunque la pureza de los datos supera a los sistemas de trabajo, no se puede permitir que los datos incorrectos se propaguen en otros lugares y corrompan otros sistemas. En la medida en que pueda dar masajes a los datos para que sean correctos y luego continuar, debe seguir la teoría de que los datos son seguros y debe mantener el sistema en funcionamiento ...
Me gusta pensar en cosas en términos de flujos de datos. Transmitir datos erróneos está contaminando todo el flujo, y eso es malo porque, al igual que la contaminación real, una gota puede arruinar todo un río de datos (si un elemento es malo, ¿en qué más puede confiar?). Pero igualmente malo es bloquear el flujo, sin dejar pasar nada porque viste algo que podrías eliminar fácilmente. Filtra y si todos en cada etapa también son filtros, obtendrás datos claros y claros del otro extremo, incluso si se iniciaran algunas impurezas en el medio.
Diría que depende de lo que pase si no te detienes. ¿El cheque de alguien se procesa mal? ¿Se envía la orden incorrecta? Valdría la pena parar por eso.
Si es posible, haga su pastel y cómalo también. No informe el error al usuario, haga que el cliente acepte enviar informes de diagnóstico e informe cada falla. Corrija los desarrolladores que poseen los módulos defectuosos para solucionarlos. Y por error me refiero a presentar un error contra ellos. O, si la administración no cree que valga la pena el costo de la reparación, no lo haga.
También escribía pruebas unitarias contra aquellos módulos que fallan, especialmente si puedes decir cuál fue la entrada original que causó que generaran la salida incorrecta.
Sin embargo, a lo que realmente se reduce es a lo que la persona que revisa su desempeño quiere de usted, especialmente después de explicarles el problema, por correo electrónico.
En pocas palabras, esto suena como un "no compruebe si hay algo que no puede manejar". El hecho de que esté detectando el error y sea capaz de notificarlo significa que no lo está propagando. Pero también significa que, dado que puede reportarlo, tiene algún mecanismo para atrapar el error y, por lo tanto, puede manejarlo usted mismo y corregirlo en lugar de reportarlo.
Tenga en cuenta que supongo que su informe de errores es más interesante que una excepción aleatoria en la que se ubicó en algún lugar del sistema. Pero incluso entonces, si está probando una excepción y está creando (es decir, comprueba si el denominador es cero y envía un error en lugar de simplemente dividirlo inadvertidamente por cero y capturando la excepción más arriba), eso sugiere que Bien podría tener una manera de corregir el problema.
En pocas palabras, necesita ambos. Debe intentar que los datos sean tan libres de errores como sea práctico, pero también informar lo inesperado.
No creo que puedas cerrar la puerta y cruzar los brazos diciendo "no es mi problema". El hecho de que venga 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 GIGO a otros sistemas menores, pero esos módulos heredados combinados con su nuevo módulo son un todo cohesivo y, por lo tanto, conforman "el sistema".
El problema real típico aquí es simplemente la ecuación de tiempo / valor de escribir todo este código de correcció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, "ser liberal en lo que acepta" es una política acertada.
Esa es una trampa difícil. Si su módulo recibe datos erróneos y está "bien" para que no haga nada con ellos y regrese, le sugeriría que escriba en un registro de errores en lugar de mostrar un error al usuario.
Gracias a todos. El caso que motivó esta pregunta terminó bien, y en parte gracias a la información que obtuve de las respuestas anteriores.
Mi primera reacción fue apegarme a fallar rápido, pero pensé en esto un poco más, y llegué a la conclusión de que uno de los roles de mi módulo es proporcionar un ancla estabilizadora al resto del sistema. Eso no significa necesariamente aceptar datos erróneos, sino problemas emergentes, aislarlos y manejarlos de manera transparente hasta que encontremos una solución.
Planifiqué 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 anteriormente no estaba documentado.
Tuvimos una discusión en la que reiteré la necesidad de abordar el problema en la frontera, pero también estaba dispuesto a ayudar. Describí mi plan al otro lado, porque tenía la sospecha de que mi posición era vista como demasiado pedante, y que la solución se percibía como que solo tenía que desactivar la validación falsa de datos inofensivos, incluso si era incorrecta. Sin embargo, en realidad, la forma en que trabajo depende en gran medida de los datos, por lo que expliqué por qué es correcta y cómo se comporta el comportamiento y cómo al acomodar 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 exhaustiva de la aversión del otro lado para arreglar los datos. Resultó que era más un cansancio de tratar con un sistema heredado propenso a errores que un obstáculo real. Había una solución relativamente simple, daba miedo hacer un cambio, una mentalidad bastante arraigada.
Pero habiendo aireado todos los desafíos y posibles soluciones, finalmente acordamos arreglar los datos, y hasta ahora parece haber resuelto nuestro problema. Nuestras pruebas de integración ahora pasan 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 fallar rápidamente es esencial para los problemas emergentes. Pero una vez que salen a la superficie, la solidez significa proporcionar un camino transparente para continuar la operación de una manera que no comprometa el sistema. Pude ofrecer eso, y al hacerlo, gané algo de buena voluntad del otro lado y conseguí que los datos se corrigieran al final.
Nuevamente, gracias a todos los que respondieron. Soy demasiado nuevo para calificar los comentarios, pero aprecio todas las perspectivas presentadas.
La pregunta de tus compañeros es: "¿por qué no solucionas este problema?"
Usted dice que es posible detectar los datos incorrectos e informar 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 opera su software. Si sabe que los datos que ingresan son erróneos, ¿es posible que vuelva a solicitarlos? ¿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 sea débil y la transmisión esté dañada, ¿debería el sistema "fallar rápido" y mostrar un mensaje de error? ¿O debería mostrarse una imagen más pobre y hacer un intento de reconectarse si es necesario, dependiendo de la magnitud del problema?
Dependiendo de su dominio, es posible que pueda detectar datos erróneos y realizar una segunda solicitud de los datos sin incomodar al usuario. (Claramente, esto solo es relevante en los casos en los que se espera que los datos sean mejores la segunda vez, pero sí dice que los problemas que está experimentando son intermitentes y están relacionados con la posible concurrencia) ...
Por lo tanto, fallar rápido es bueno y definitivamente es algo que debe hacer si no puede recuperarse. Y definitivamente no deberías propagar malos datos. Pero si puede recuperarse, lo que en algunos dominios puede hacer, entonces fallar de inmediato no es necesariamente lo mejor que puede hacer.
No voy a entrar en las razones, pero tienes razón.
En mi experiencia, a los PHB les falta la parte del cerebro que se necesita para comprender por qué fallar rápidamente tiene mérito y "robustez", tal como se define por hacer lo que sea necesario, comerse los errores si es necesario, es una mala idea. Es inútil. Simplemente no tienen el hardware para asimilarlo. Tienden a decir cosas "está bien, haces un buen punto, pero ¿qué pasa con el usuario?", Es solo su versión de pensar en los niños , y señala el final de una conversión conmigo cada vez que aparece.
Mi consejo es que te mantengas firme. Eternamente.