¿Cuándo la corrección de errores se vuelve excesiva, si alguna vez?

128

Imagina que estás creando un reproductor de video en JavaScript. Este reproductor de video repite el video del usuario repetidamente utilizando una función recursiva y, por eso, el navegador activará un too much recursion RangeErroren algún momento.

Probablemente nadie usará tanto la función de bucle. Su aplicación nunca arrojará este error, ni siquiera si el usuario dejó la aplicación en bucle durante una semana, pero aún existe. Resolver el problema requerirá que rediseñe la forma en que funciona el bucle en su aplicación, lo que tomará una cantidad considerable de tiempo. ¿Qué haces? ¿Por qué?

  • Arreglar el error

  • Deja el error

¿No deberías arreglar solo los errores con los que la gente tropezará? ¿Cuándo la corrección de errores se vuelve excesiva, si alguna vez lo hace?

EDITAR:

Si el enfoque recursivo que no causa un error real es una preocupación para usted, suponga que por cada vez que el reproductor reproduce un video, aumenta una variable 1. Después de 2 53 bucles, esta variable se desbordará y su programa no podrá manejarla, lanzando una excepción.

Tiago Marinho
fuente
95
No te metas con mi compañero de escenario de ejemplo
Tiago Marinho
15
@PlasmaHH Estoy usando este escenario hipotético para explicar mi pregunta. Si el error existe o no, no importa en absoluto
Tiago Marinho
13
@TiagoMarinho: el punto que estoy tratando de hacer es: a veces es lo correcto para definir un escenario como el comportamiento previsto.
PlasmaHH
23
¿Por qué demonios ejecutarías ese bucle usando la recursión en primer lugar? Es posible que no desee corregir el error, pero seguramente debería reconsiderar su proceso de diseño :-)
jamesqf
28
Esto parece más una pregunta de negocios. Debe priorizar según el costo de la reparación y el impacto / frecuencia del error.
Casey Kuball

Respuestas:

164

Tienes que ser pragmático.

Si es poco probable que el error se active en el mundo real y el costo de la reparación es alto, dudo que muchas personas lo consideren un buen uso de los recursos para solucionarlo. Sobre esa base, diría que lo deje, pero asegúrese de que el pirateo esté documentado para usted o su sucesor en unos meses (consulte el último párrafo).

Dicho esto, debe usar este problema como una "experiencia de aprendizaje" y la próxima vez que realice un bucle no use un bucle recursivo innecesariamente.

Además, prepárate para ese informe de error. Se sorprenderá de lo buenos que son los usuarios finales para superar los límites y descubrir defectos. Si se convierte en un problema para los usuarios finales, tendrá que solucionarlo, entonces se alegrará de haber documentado el hack.

mcottle
fuente
119
Totalmente de acuerdo con "Te sorprendería lo buenos que son los usuarios finales para superar los límites y descubrir defectos".
Visto el
74
Los usuarios finales no están restringidos de ninguna manera por lo que usted considera un uso razonable de su software. Habrá usuarios que quieran reproducir un video para siempre. Es una característica que proporciona su software, por lo que la usarán.
gnasher729
36
@ gnasher729 Los videos de "10 horas XXXX" en Youtube son un buen identificador de que, de hecho, algunas personas solo quieren repetir algo para siempre.
Chris Cirefice
23
Otro problema: si su software es popular, entonces alguien encuentra un error que solo ocurre en una situación rara, lo publica en Internet y, de repente, todos y su perro dicen "este software es basura, se bloquea si reproduzco un video para un día". O un competidor lo usa para demostrar lo fácil que es bloquear su aplicación.
gnasher729
44
Énfasis en el último párrafo. ¿Sabía que MacOS Classic se bloquearía si recibiera 32.768 eventos consecutivos de "presión del mouse" sin un evento de "liberación del mouse"?
Mark
79

Hubo un error similar en Windows 95 que hizo que las computadoras se bloqueen después de 49.7 días . Solo se notó algunos años después del lanzamiento, ya que muy pocos sistemas Win95 se mantuvieron así de todos modos. Entonces, hay un punto: los errores pueden volverse irrelevantes por otros errores más importantes.

Lo que debe hacer es una evaluación de riesgos para el programa en su conjunto y una evaluación de impacto para errores individuales.

  • ¿Está este software en un límite de seguridad?
  • Si es así, ¿puede este error resultar en un exploit?
  • ¿Es este software "de misión crítica" para los usuarios previstos? (Vea la lista de cosas para las cuales el EULA de Java le prohíbe usarlo )
  • ¿El error puede provocar la pérdida de datos? ¿Perdidas financieras? Pérdida de reputación?
  • ¿Qué tan probable es que ocurra este error? (Has incluido esto en tu escenario)

Y así. Esto afecta la clasificación de errores , el proceso de decidir qué errores corregir. Casi todo el software de envío tiene listas muy largas de errores menores que aún no se han considerado lo suficientemente importantes como para solucionarlos.

pjc50
fuente
2
También recuerdo el error (hardware) en algunas CPU de Intel donde un valor de punto flotante específico salió mal.
55
@WilliamKappler en.wikipedia.org/wiki/Pentium_FDIV_bug es a lo que creo que te refieres. Estuvo despierto un año antes de que alguien lo notara.
Jeutnarg
10
@ gnasher729 - En realidad no, ya estaban en la parte inferior y todavía estaban cavando :) La mayoría de las personas tuvieron que reinstalar Win 95 con más frecuencia que 49.7 días IIRC.
mcottle
44
@Luaan El comentario fue pensado como una excavación alegre en M $, de ahí el smiley después de la primera oración. Estaban detrás del eightball con el '95 porque salió muy tarde en el 95 (probablemente porque tener Win95 lanzado en 1996 hubiera sido un mal aspecto), medio cocido (¿Recuerdas el USB BSOD?) E inclinado a volverse inestable y requerir reinstalaciones regulares de ahí mi segunda oración, que nunca mencionó la ejecución de un servidor en Windows 95, no sé de dónde sacaste ESO (¿flashbacks?). El segundo CD de lanzamiento mejoró las cosas, pero el lanzamiento inicial de '95 fue deslumbrante.
mcottle
55
TBH Creo que fue el fiasco de "Windows for Warships" el que causó más daño a la reputación ( archive.wired.com/science/discoveries/news/1998/07/13987 ) y que estaba usando NT. Las máquinas Unix de esa época podían gestionar tiempos de funcionamiento de varios años, incluso utilizando versiones (muy tempranas) de Linux. Todas las computadoras domésticas también eran capaces de tener un alto tiempo de actividad, aunque rara vez se usaban de esa manera. Vi micros de la BBC incrustados en exhibiciones educativas una década después de que fueran obsoletos.
pjc50
33

Las otras respuestas ya son muy buenas, y sé que su ejemplo es solo un ejemplo, pero quiero señalar una gran parte de este proceso que aún no se ha discutido:

Debe identificar sus suposiciones y luego probar esas suposiciones contra los casos de esquina.

Mirando tu ejemplo, veo un par de suposiciones:

  • El enfoque recursivo eventualmente causará un error.
  • Nadie verá este error porque los videos tardan demasiado en reproducirse para alcanzar el límite de pila.

Otras personas han discutido la primera suposición, pero miren la segunda suposición: ¿qué pasa si mi video es solo una fracción de segundo?

Y claro, tal vez ese no sea un caso de uso muy común. ¿Pero estás realmente seguro de que nadie subirá un video muy corto? Estás asumiendo que los videos tienen una duración mínima, ¡y probablemente ni siquiera te diste cuenta de que estabas asumiendo algo! ¿Podría esta suposición causar otros errores en otros lugares de su aplicación?

Los supuestos no identificados son una gran fuente de errores.

Como dije, sé que su ejemplo es solo un ejemplo, pero este proceso de identificar sus suposiciones (que a menudo es más difícil de lo que parece) y luego pensar en excepciones a esas suposiciones es un factor muy importante para decidir dónde pasar su tiempo.

Entonces, si te encuentras pensando "No debería tener que programar alrededor de esto, ya que nunca sucederá", entonces deberías tomarte un tiempo para examinar realmente esa suposición. A menudo pensará en casos de esquina que podrían ser más comunes de lo que pensaba originalmente.

Dicho esto, hay un punto en el que esto se convierte en un ejercicio inútil. Probablemente no le importe si su aplicación de JavaScript funciona perfectamente en una calculadora TI-89, por lo que gastar cualquier cantidad de tiempo en eso simplemente se desperdicia.

Las otras respuestas ya han cubierto esto, pero llegar a esa línea entre "esto es importante" y "esto es una pérdida de tiempo" no es una ciencia exacta, y depende de muchos factores que pueden ser completamente diferentes de uno persona o empresa a otra.

Pero una gran parte de ese proceso es primero identificar sus supuestos y luego tratar de reconocer las excepciones a esos supuestos.

Kevin Workman
fuente
Muy buen punto Kevin. Tenga en cuenta mi comentario sobre la respuesta seleccionada anteriormente que se centra en la pregunta de análisisWhat's the worst thing that could happen?
OMY
Otra suposición aquí es que una pila cada vez mayor solo generará problemas cuando alcance un tamaño de desbordamiento. De hecho, la pila puede ser un recurso normal, este error se escapa constantemente. Todo el navegador podría volverse más y más lento por pequeños bits en cada iteración ^ H ^ H ^ H ^ H ^ H ^ Hrecursion.
Alfe
1. El OP nunca dijo que el problema era causado por una pila cada vez mayor. Podría ser fácilmente causado por un error en una rutina de contador (dec -> div / 0?). 2. Si el problema es un problema de desbordamiento de pila, ¿no debería publicarse esta pregunta en StackOverflow? <rimshot!> ;-D
OMY
@OMY ¿A quién va dirigido ese comentario?
Kevin Workman
13

Le recomendaría que lea el siguiente documento:

La confiabilidad y sus amenazas: una taxonomía

Entre otras cosas, describe varios tipos de fallas que pueden ocurrir en su programa. Lo que describió se llama falla latente , y en este documento se describe así:

Una falla está activa cuando produce un error; de lo contrario, está inactiva. Una falla activa es a) una falla interna que estuvo inactiva previamente y que ha sido activada por el proceso de cómputo o condiciones ambientales, o b) una falla externa. La activación de fallas es la aplicación de una entrada (el patrón de activación) a un componente que hace que se active una falla inactiva. La mayoría de las fallas internas se alternan entre sus estados inactivo y activo

Habiendo descrito esto, todo se reduce a una relación costo-beneficio. El costo consistiría en tres parámetros:

  • ¿Con qué frecuencia se presentaría el problema?
  • ¿Cuáles serían las consecuencias?
  • ¿Cuánto te molesta personalmente?

Los dos primeros son cruciales. Si se trata de un error que se manifestaría una vez en una luna azul y / o a nadie le importa, o tiene una solución perfectamente buena y práctica, entonces puede documentarlo con seguridad como un problema conocido y pasar a un desafío más y más tareas importantes Sin embargo, si el error ocasiona que algunas transacciones de dinero fallen, o interrumpa un proceso de registro largo, frustrando así al usuario final, entonces debe actuar en consecuencia. El tercer parámetro es algo que desaconsejo encarecidamente. En palabras de Vito Corleone:

No es personal Son negocios.

Si eres un profesional, deja de lado las emociones y actúa de manera óptima. Sin embargo, si la aplicación que está escribiendo es un pasatiempo suyo, entonces está involucrado emocionalmente, y el tercer parámetro es tan válido como cualquiera en términos de decidir si corregir un error o no.

Vladimir Stokic
fuente
'No es personal. Es negocio 'es de Michael, supongo, no Vito. (Se sorprendería de lo buenos que son los usuarios finales para
superar
En realidad, es de Vito, si lees el libro. Incluso en la película, es Tom Hagen quien dice eso primero cuando discute con Sonny sobre si deberían ir a los colchones, y solo después de eso Michael dice la famosa frase: "No es personal, Sonny. Es estrictamente comercial ... ". Pero Hagen lo aprendió de Vito.
Vladimir Stokic
11

Ese error solo permanece sin descubrir hasta el día en que alguien coloca a su jugador en la pantalla del lobby ejecutando una presentación de la compañía 24/7. Entonces sigue siendo un error.

La respuesta a ¿Qué haces? es realmente una decisión comercial, no de ingeniería:

  • Si el error solo afecta al 1% de sus usuarios, y su reproductor carece de soporte para una función requerida por otro 20%, la elección es obvia. Documente el error, luego continúe.
  • Si la corrección de errores está en su lista de tareas pendientes, a menudo es mejor corregirla antes de comenzar a agregar nuevas funciones. Obtendrá los beneficios del proceso de desarrollo de software sin defectos, y no perderá mucho tiempo ya que de todos modos está en su lista.
Dmitry Grigoryev
fuente
5

Especialmente en grandes empresas (o grandes proyectos) hay una forma muy pragmática de establecer qué hacer.

Si el costo de la reparación es mayor que el retorno que traerá la solución, entonces mantenga el error. A la inversa, si la solución devolverá más de su costo, solucione el error.

En su escenario de muestra, depende de la cantidad de usuarios que espera perder frente a la cantidad de usuarios que obtendrá si desarrolla nuevas funciones en lugar de corregir ese costoso error.

JoulinRouge
fuente
66
El retorno de la inversión para corregir un error rara vez es fácil de evaluar, generalmente debe confiar en su criterio.
Ant P
El rendimiento que traerá la solución es principalmente la reputación, que es casi imposible de cuantificar. Si soy el único que sabe que puede haber un error y luego, en un año o dos, cambio de trabajo y la nueva compañía está pensando en incorporar un reproductor de video en su producto (posiblemente vendiendo millones de unidades), recomendaría usar ¿éste?
Jerry Jeremiah
@JerryJeremiah si el error impide que se ejecute un proceso comercial, no se trata de reputación, depende de la importancia del proceso comercial. Y en cada caso y en cada política que aplique para corregir errores o no, debe realizar una evaluación subjetiva basada en su experiencia y conocimiento. Incluso si puede conocer el número exacto de usuarios que se enfrentarán al error, aún tiene que tomar una decisión humana (también la política de ROI también puede incluir estadísticas de aciertos de errores para aumentar los costos). Como hoy no hay una forma mecánica de saber a priori lo que hay que hacer.
JoulinRouge
5

TL; DR Esto es por qué RESOLVED/WONTFIXes una cosa. Simplemente no lo use en exceso: la deuda técnica puede acumularse si no tiene cuidado. ¿Es este un problema fundamental con su diseño, que probablemente cause otros problemas en el futuro? Entonces arréglalo. ¿De otra manera? Déjelo hasta que se convierta en una prioridad (si alguna vez lo hace).

Carreras de ligereza en órbita
fuente
5

En realidad, hay tres errores en la situación que describe:

  1. La falta de un proceso para evaluar todos los errores registrados (usted registró el error en su ticket / trabajo atrasado / cualquier sistema que tenga instalado, ¿verdad?) Para determinar si se debe corregir o no. Esta es una decisión de gestión.

  2. La falta de habilidades en su equipo que lleva al uso de soluciones defectuosas como esta. Es urgente abordar esto para evitar futuros problemas. (Comience a aprender de sus errores).

  3. El problema de que el video puede dejar de mostrarse después de mucho tiempo.

De los tres errores, solo (3) podrían no necesitar ser reparados.

Doblado
fuente
Gracias por señalar los problemas de segundo orden. Demasiadas personas solo tratan el síntoma, y ​​la causa sigue creando más síntomas.
jaxter
4

Aquí hay muchas respuestas que analizan la evaluación del costo de la corrección del error en lugar de dejarlo. Todos contienen buenos consejos, pero me gustaría agregar que el costo de un error a menudo se subestima, posiblemente se subestima enormemente. La razón es que los errores existentes confunden las aguas para un desarrollo y mantenimiento continuos. Hacer que sus evaluadores realicen un seguimiento de varios errores "no solucionarán" mientras navega por su software tratando de encontrar nuevos errores hace que su trabajo sea más lento y más propenso a errores. Unos pocos errores "no solucionarán" que es poco probable que afecten a los usuarios finales aún harán más lento el desarrollo continuo y el resultado será más problemático.

Buhb
fuente
2

Una cosa que aprendí en mis años de codificación es que volverá un error. El usuario final siempre lo descubrirá e informará. Si va a corregir el error o no es "meramente" una cuestión de prioridad y fecha límite.

Hemos tenido errores importantes (en mi opinión, importantes) que se decidieron no corregir en una versión, solo para convertirse en un obstáculo para la próxima versión porque el usuario final tropezó con ella una y otra vez. Lo mismo a la inversa: nos presionaron para corregir un error en una función que nadie usa, pero fue útil para la administración.

Aleksandra
fuente
2

Aquí hay tres cosas:

Principios

Esta es una cara de la moneda. Hasta cierto punto, creo que es bueno insistir en corregir errores (o malas implementaciones, incluso si "funcionan"), incluso si nadie se da cuenta.

Míralo de esta manera: el problema real no es necesariamente el error, en tu ejemplo, sino el hecho de que un programador pensó que era una buena idea implementar el bucle de esta manera, en primer lugar. Era obvio desde el primer momento, que esta no era una buena solución. Ahora hay dos posibilidades:

  • El programador simplemente no se dio cuenta. Bueno ... un programador debe desarrollar una intuición de cómo se ejecuta su código. No es que la recursión sea un concepto muy difícil. Al corregir el error (y sudar a través de todo el trabajo adicional), tal vez aprenda algo y lo recuerde, aunque solo sea para evitar el trabajo adicional en el futuro. Si la razón era que él no tenía el tiempo suficiente, la gestión podría aprender que los programadores no necesitan más tiempo para crear un código de mayor calidad.

  • El programador lo notó, pero lo consideró "no es un problema". Si esto se deja en pie, entonces se desarrolla una cultura de laissez-faire que, en última instancia, conducirá a errores donde realmente duele. En este caso particular, a quién le importa. Pero, ¿qué pasa si ese programador está desarrollando una aplicación bancaria la próxima vez y decide que cierta constelación nunca sucederá? Entonces lo hace. Malos tiempos.

Pragmatismo

Este es el otro lado. Por supuesto, es probable que, en este caso particular, no solucione el error. Pero cuidado: hay pragmatismo y luego hay pragmatismo. Un buen pragmatismo es si encuentra una solución rápida pero sólida pero bien fundada para un problema. Es decir, evitas diseñar cosas en exceso, pero las cosas que implementas todavía están bien pensadas. El pragmatismo malo es cuando simplemente piratea algo que funciona "exactamente" y se romperá en la primera oportunidad.

Falla rápido, falla duro

En caso de duda, falle rápido y fracase duro.

Esto significa, entre otros, que su código nota la condición de error, no el entorno.

En este ejemplo, lo menos que puede hacer es hacerlo para que no ocurra el error de tiempo de ejecución difícil ("profundidad de pila excedida" o algo así), reemplazándolo por una fuerte excepción propia. Podría, por ejemplo, tener un contador global y decidir arbitrariamente que rescatará después de 1000 videos (o cualquier número que sea lo suficientemente alto como para que nunca ocurra en el uso normal, y lo suficientemente bajo como para funcionar en la mayoría de los navegadores). Luego, dale a esa excepción (que puede ser una excepción genérica, por ejemplo, una RuntimeExceptionen Java o una cadena simple en JavaScript o Ruby) un mensaje significativo. No tiene que ir al extremo para crear un nuevo tipo de excepciones o lo que sea que haga en su lenguaje de programación particular.

De esta manera, tienes

  • ... documentado el problema dentro del código.
  • ... lo convirtió en un problema determinista. Usted sabe que su excepción ocurrirá. No le gustan los cambios en la tecnología del navegador subyacente (piense no solo en el navegador de la PC, sino también en los teléfonos inteligentes, las tabletas o la tecnología futura).
  • ... lo hizo fácil de arreglar cuando eventualmente necesitas arreglarlo. La fuente del problema se señala en su mensaje, obtendrá un retroceso significativo y todo eso.
  • ... todavía no perdió tiempo en el manejo de errores "reales" (recuerde, nunca espera que ocurra el error).

Mi convención es prefijar tales mensajes de error con la palabra "Paranoia:". Esta es una señal clara para mí y para todos los demás de que nunca espero que se produzca ese error. Puedo separarlos claramente de las excepciones "reales". Si veo uno así en una GUI o un archivo de registro, sé con certeza que tengo un problema grave: después de todo, nunca esperé que ocurrieran. En este punto, entro en modo crujiente (con una buena posibilidad de resolverlo rápida y fácilmente, ya que sé exactamente dónde ocurrió el problema, salvándome de muchas depuraciones espurias).

AnoE
fuente
2
Lo siento si te sientes así por lo pronto que acepté una respuesta. En mi defensa, simplemente no sabía que la pregunta tendría> 10,000 puntos de vista y tantas respuestas en el momento de la aceptación. De todos modos, todavía no he cambiado de opinión sobre la mejor respuesta.
Tiago Marinho
@TiagoMarinho, no hay problema, el comentario no fue dirigido principalmente a usted personalmente, y no esperaba que lo reconsiderara. ;) Estoy más perplejo por las motivaciones de quien haya votado para borrar mi respuesta ... Además, hay bastante voto negativo para varias respuestas aquí sin ningún comentario. No estoy seguro si esa es la forma en que se hace en esta área particular de SE.
AnoE
Estoy completamente de acuerdo con el voto negativo extraño
Tiago Marinho
Me pregunto si, al menos en este caso, el tratamiento es mejor que la cura. Si decide hacer un manejo especial para un defecto de diseño que ya ha identificado, tiene sentido comparar el costo total del ciclo de vida de a) implementar el manejo de errores y potencialmente actuar sobre el error cuando ocurre al arreglar el diseño, o b) simplemente arreglando el diseño en primer lugar.
jaxter
@jaxter, exactamente. De ahí mi enfoque de abrir la mente a una corrección de errores (incluso si parece excesivo), pero cuando decides no corregir el error, al menos implementa lo rápido. Obviamente, si la solución rápida es más costosa que la corrección de error "real" en primer lugar, entonces evítela y realice la corrección de error real.
AnoE
1

Un post-it en el escritorio de un desarrollador senior en mi lugar de trabajo dice

¿Ayuda a alguien?

Creo que a menudo es un buen punto de partida para el proceso de pensamiento. Siempre hay muchas cosas que arreglar y mejorar, pero ¿cuánto valor estás agregando realmente? ... ya sea en usabilidad, confiabilidad, mantenibilidad, legibilidad, rendimiento ... o cualquier otro aspecto.

topo morto
fuente
0

Se me ocurren tres cosas:

Primero , el impacto de un error identificado debe investigarse a fondo antes de que la decisión de dejar el error en el código se pueda tomar de manera responsable. (En el ejemplo que a la vez pensé en la pérdida de memoria de la pila cada vez mayor y representa lo que podría hacer que su navegador más lento y más lento con cada recursividad.) Esta exhaustiva investigación a menudo lleva más tiempo que iba a corregir el error, por lo que preferiría fijación El error en la mayoría de los casos.

En segundo lugar , los errores tienden a tener más impacto de lo que uno piensa al principio. Todos estamos muy familiarizados con el código de trabajo porque este es el caso "normal". Los errores, por otro lado, son una "excepción". Por supuesto, todos hemos visto muchos errores, pero hemos visto mucho más código de trabajo en general. Por lo tanto, tenemos más experiencia con el comportamiento del código de trabajo que con el comportamiento del código defectuoso. Hay miles de millones de libros sobre el código de trabajo y lo que hará en qué situaciones. Hay casi nada sobre el comportamiento del código con errores.

La razón de esto es simple: los errores no son orden sino caos . A menudo les queda un rastro de orden (o al revés: no destruyen el orden por completo), pero su naturaleza defectuosa es una destrucción del orden que el programador quería. El propio caos tiende a desafiar la estimación correcta. Es mucho más difícil decir qué hará un programa con un error que lo que hará un programa correcto solo porque ya no se ajusta a nuestros patrones mentales.

Tercero , su ejemplo contenía el aspecto de que corregir el error significaría tener que rediseñar el programa. (Si elimina este aspecto, la respuesta es simple: corrija el error, no debería tomar demasiado tiempo porque no es necesario rediseñarlo. De lo contrario :) En tal caso, perdería la confianza en el programa tal como está diseñado actualmente. El rediseño sería una forma de restaurar esa confianza.

Dicho todo esto , los programas son cosas que la gente usa, y una característica faltante o un segundo error realmente engorroso en otros lugares puede tener prioridad sobre la corrección de su error. Por supuesto, luego tome el camino pragmático y haga otras cosas primero. Pero nunca olvide que una primera estimación rápida del impacto de un error puede ser completamente errónea.

Alfe
fuente
2
Por favor, deje un comentario cuando haga un voto negativo. Deberíamos saber cuál es la crítica para mejorar la respuesta.
Alfe
0

Probabilidad baja / consecuencias leves = arreglo de baja prioridad

  • Si la probabilidad de ocurrencia es muy baja
  • Si las consecuencias de la ocurrencia son leves
  • Entonces el error no representa una amenaza, entonces no es una solución prioritaria.

Pero esto no puede convertirse en una muleta para los desarrolladores perezosos ...

  • ¿Qué significa "ocurrencia muy baja"?
  • ¿Qué significan "consecuencias leves"?

Para establecer que la probabilidad de ocurrencia es muy baja y las consecuencias son leves, el equipo de desarrollo debe comprender el código, los patrones de uso y la seguridad.

La mayoría de los desarrolladores se sorprenden de que las cosas que pensaban originalmente nunca sucederán, en realidad suceden mucho

Nuestro sistema educativo no enseña muy bien la probabilidad y la lógica. La mayoría de las personas, incluida la mayoría de los ingenieros de software, tienen una lógica y una intuición de proabilidad rotas. La experiencia con problemas del mundo real y la experiencia con simulaciones extensas son la única forma en que sé solucionar esto.

Enfrenta tu intuición con datos del mundo real

Es importante hacer varios registros para poder seguir los patrones de uso. Rellene el código con afirmaciones de cosas que cree que no deberían suceder. Te sorprenderá que lo hagan. De esa manera podrá confrontar su intuición con datos duros y refinarlos.

Mi ejemplo de un problema leve y una medida de control

En un sitio de comercio electrónico en el que trabajé hace mucho tiempo, otro programador cometió un error: en una condición oscura, el sistema le cobraba al cliente un centavo menos de lo registrado en los registros. Descubrí el error porque hice informes para identificar las diferencias entre los registros y los saldos de cuentas para hacer que el sistema contable sea más resistente. Nunca solucioné este error porque la diferencia era muy pequeña. La diferencia se calculó diariamente y fue inferior a US $ 2,00 mensuales. Ocurre que estábamos desarrollando un sistema completamente nuevo que en un año debería reemplazar al actual. No tiene sentido desviar recursos de proyectos potencialmente rentables para arreglar algo que cuesta US $ 2.00 mensuales y fue sometido a una medida de control apropiada.

Conclusión

Sí, hay errores que no necesitan ser reparados de inmediato, que no son lo suficientemente importantes como para retrasar el desarrollo de nuevas funciones. Sin embargo, el sistema debe tener el control de la aparición de este error para asegurarse de que sea pequeño porque no podemos confiar en nuestra propia intuición.

Lucas
fuente
-1

Creo que esto es una pregunta equivocada desde el principio.

La pregunta no es "¿debería solucionar este error o no debería solucionarlo?". Cualquier desarrollador tiene una cantidad de tiempo limitada. Entonces la pregunta es "¿qué es lo más útil que puedo hacer en una hora, cuatro horas o una semana"?

Si corregir el error es lo más útil, ya que mejora el software en la mayor cantidad posible para la mayoría de las personas, entonces corríjalo. Si puede realizar mejoras más importantes en otros lugares, agregando características que faltan personas o solucionando un error más importante, haga estas otras cosas. Y puntos de bonificación adicionales por cualquier cosa que haga que su desarrollo futuro sea más eficiente.

gnasher729
fuente
No estoy seguro de que la métrica utilitaria funcione mejor aquí. Claramente, el ejemplo del reproductor de video fue diseñado para ser de bajo impacto, pero incluso eso no es infalible. Un respondedor ya citó el ciclo de promoción 24/7 en un caso de uso del lobby, y otro podría ser un quiosco en una convención de ventas / tecnología que dura una semana. Ambos costarían representante y / o dinero para el negocio, por lo que no es trivial.
jaxter
Eso significaría que solucionar el error proporciona más beneficios de los esperados originalmente, por lo que debería ir más arriba en prioridades. Por lo tanto, tendrá más éxito en la vida si su opinión sobre lo que es más útil concuerda con la realidad tanto como sea posible.
gnasher729
-2

La corrección de errores siempre es una exageración

Vamos a clasificar insecto primera parte.

¿Es un error honesto , por ejemplo, un error único o una sombra variable que escapó de las pruebas? En este caso, espero que, además de "solucionar" el problema, también escribiste nuevas pruebas unitarias, aproveché la oportunidad para refactorizar el código cercano, donde todo lo último es un trabajo útil .

Sin embargo, si en realidad es una falla de diseño como lo es en su caso, debe reevaluar el diseño o, en el peor de los casos, deshabilitar esta función.

Entonces, por favor no intentes arreglarlo .

Podría hacerlo peor, por supuesto, podría probar la metodología de hack-on-hack . El bucle de video es un truco (mala arquitectura y se conoce una rotura). Puede agregar un límite de bucle , de modo que después de N iteraciones (que ha probado está por debajo del límite del navegador) el bucle termina.

Las ramificaciones son obvias, ahora debe admitir tanto el código roto como el nuevo límite de bucle.

PD disculpas por la visión extrema.

PPS Una nota sobre terminología: no se puede "arreglar" un error. Bueno, quizás un veterinario podría, pero no vayamos allí ;-). Los problemas se resuelven o "arreglan", mientras que los errores se eliminan o se solucionan.

Dima Tisnek
fuente
¿Realmente quisiste decir que siempre es "excesivo"? Creo que podría haber confundido definiciones en alguna parte. Exagerar significa "trabajar en exceso de lo que se requería", o en otras palabras, es más de lo que cualquiera debería estar haciendo. Estás afirmando que la corrección de errores siempre es exagerada, mientras que simultáneamente imploras a las personas que no es suficiente trabajo y que debemos hacer más trabajo además de eso, lo que no tiene sentido.
Doppelgreener
@doppelgreener Veo cómo eso puede ser confuso. La corrección de errores es una práctica terrible y nunca debe hacerse. Por otro lado, adaptar el diseño o la arquitectura del software a los requisitos cambiantes es una buena práctica que debe seguirse. Lo mismo para corregir errores honestos, suponiendo que se haga bien.
Dima Tisnek
2
No sé de qué tipo de corrección de errores estás hablando, pero en mi mundo cotidiano, "cambiar la arquitectura" es un método de corrección de errores. Es posible que desee definir lo que está recopilando bajo el término "corrección de errores".
doppelgreener
@doppelgreener: el término "arreglo" tiene un significado especial en algunas formas de gestión de calidad y muchos gerentes de programación han adoptado un uso especializado. Una " solución " es solo una solución o solución temporal , mientras que una " solución " verdadera al problema requiere la identificación y eliminación de la " causa raíz ". En el software, un error puede ser tan simple como una coma fuera de lugar donde la solución (corregir la coma) ES la solución, pero si el error es causado por algo más grande, entonces la solución (ej .: limitadores de bucle) no será la misma que la solución (rediseño / reescritura).
OMY
2
@ OMY Gracias por la explicación. Siento que como la definición de "arreglo" no está siendo utilizada por la pregunta, la respuesta debería responder al sentido de la palabra que se está utilizando.
Doppelgreener