Agrupación de errores en el código fuente

8

Hay muchas afirmaciones sobre la existencia de grupos de errores o defectos. Una búsqueda simple revela múltiples resultados, por ejemplo: 1 , 2 , 3 , 4 , 5 .

Sin embargo, toda la evidencia citada es anecdótica y no pude encontrar ningún dato concreto que respalde esto. Si bien mi propia experiencia no contradice estas afirmaciones, a las personas les encanta ver patrones incluso cuando no hay ninguno (incluso la distribución uniforme de errores producirá grupos, y podría ser más fácil recordar cuándo debe corregir 10 errores en un lugar en lugar de 10 cosas no relacionadas en toda la base de código).

Realmente tengo curiosidad por saber si este fenómeno existe, pero no pude encontrar ninguna fuente objetiva o incluso semiobjetiva (como en pruebas, experimentos, estudios, etc.) que mostraría que la agrupación de defectos realmente ocurre.

Por supuesto, estoy de acuerdo con asumir la hipótesis de agrupación de errores como una buena práctica (incluso si es falsa, no dolerá demasiado). Por otro lado, los datos concretos podrían arrojar algo de luz sobre por qué sucede. ¿Es por esos días que uno tiene un terrible dolor de cabeza (por alguna razón)? ¿O tal vez porque algunas partes del código son simplemente difíciles y otras son fáciles? ¿O tal vez es el lugar de responsabilidad de esos dos ingenieros que no se quieren?

Mi pregunta: ¿existe el efecto de agrupamiento de defectos? ¿Existe algún dato concreto no anecdótico que se explique mejor con esta hipótesis?

testing debugging maintenance engineering dtldarek
fuente
La razón es porque un error puede generar otros errores, esto sucede porque el código está interrelacionado, por lo que si bien el probador se siente bien al encontrar muchos errores, a veces no saben que el programador solo necesita corregir ese error y desaparecer el otro.
kirie
Estoy de acuerdo con @kirie aquí, que un error en una pieza de funcionalidad generalmente tiene un efecto en cascada en otras piezas de funcionalidad. El probador puede pensar que son errores distintos, pero en realidad todos provienen del único problema. Además, los humanos están bien diseñados para encontrar patrones, por eso lo hacemos en todo.
Marshall Tigerus
Muy raramente tengo un error que puede sobrescribir un bit aleatorio de información, en cualquier lugar. Con ese tipo de error en el código fuente, el software podría comportarse mal en miles de millones de formas posibles.
gnasher729
2
Creo que esta es una pregunta válida y no me gustaría verla cerrada, ya que el OP solicitó específicamente "datos no anecdóticos concretos". Sin embargo, las respuestas dadas hasta ahora no proporcionan esto. Prefiero verlo protegido y respuestas sin enlaces a la investigación rechazada.
mattnz
@ gnasher729 No sé qué tipo de información de sobrescritura menciona, pero esto es común cuando usa el principio DRY en una etapa temprana cuando muchas funciones no se han probado completamente pero ya se han usado muchas veces.
kirie

Respuestas:

3

No tengo ningún dato a mano, pero estoy bastante seguro de que la hipótesis de agrupación es cierta. La mejor suposición es que estos dos casos ocurren con mayor o menor frecuencia:

  • un fragmento de código o algoritmo es complejo (tal vez la implementación es más compleja de lo necesario) y el programador original no entendió completamente lo que su código podría hacer debido a la complejidad.

  • el código no se probó bien

Y, por supuesto, una combinación de ambos. Las pruebas son difíciles, pero probar un código complejo es mucho más difícil en un orden de magnitud. Y con el aumento de la complejidad, especialmente cuando el código no está bien probado, en mi experiencia, el número de errores potenciales en un fragmento de código aumenta desproporcionadamente alto.

Entonces, si encuentra varios errores en un código dado, es muy probable que sea un código complejo y mal probado, lo que le brinda una alta posibilidad de encontrar más en la misma área.

Doc Brown
fuente
2

Los estudios formales como este rara vez existen en el desarrollo de software, probablemente porque la programación (a pesar de su asociación con las máquinas) es principalmente un esfuerzo humano, no una máquina.

Ayer estaba arreglando un error en una declaración SQL que involucraba dos declaraciones SELECT y una UNION. Ambos SELECT estaban devolviendo el mismo resultado debido a un simple error en un JOIN. Sin embargo, al solucionar el problema, se descubrió otro error que estaba siendo enmascarado por el primer error.

Robert Harvey
fuente
2

En mi experiencia:

La agrupación ocurre cuando el trabajo se interrumpe. Digamos que alguien se retira del proyecto para que su trabajo no se pruebe completamente, o tal vez ni siquiera se complete, y / o los resultados no se entiendan completamente.

La agrupación también ocurre debido al problema del "mal programador". Digamos que 5 personas trabajaron en algo y una de ellas estaba por debajo del estándar. Los errores estarán asociados con su trabajo.

Se aplica el Principio de Pareto (también conocido como la regla 80/20). Aproximadamente el 80% de los efectos provienen del 20% de las causas. https://en.wikipedia.org/wiki/Pareto_principle Tenga en cuenta que esta observación se remonta a antes de las computadoras.

Materia oscura
fuente
0

No hay paradoja en la agrupación de errores. Y nuestros prejuicios cognitivos avivan la llama.

Según la distribución normal en cualquier momento dado, algunas partes de la base de código son significativamente más defectuosas que otras. Cualquier error nuevo es más probable que se encuentre en la parte con errores.
Entonces, el que está a punto de arreglar ya está condenado a una buena oportunidad de tener una empresa.

Es lo mismo que "las desgracias nunca llegan solas".

Vlad
fuente
1
No estoy seguro de que la distribución normal nos permita hacer una inferencia como usted sugiere. Supongo que estamos analizando la densidad de defectos por unidad de código. Para cualquier distribución de probabilidad no uniforme, podemos ver que algunas unidades tendrán más errores que otras. Para distribuciones simétricas como la distribución normal, ¡exactamente la mitad de todos los módulos tendrán una densidad de defectos superior a la media! Por supuesto, eso es una consecuencia de asumir un riesgo constante de errores en todas las unidades, pero ¿no es eso lo contrario de lo que trata esta pregunta, que los errores engendran más errores? Quizás entendí mal esta respuesta.
amon
"exactamente la mitad de ..." sí, pero no tiene ningún valor en el contexto actual. Lo siento, no te entendí, Amon. No estoy de acuerdo con la frase exacta "los errores crían más errores". Mi punto es que un error encontrado es [con probabilidad que no podemos ignorar] destinado a estar entre otros.
Vlad