Suponiendo que su código ya probado (y particularmente si se lanzó) absolutamente.
Hay varias razones para esto:
Memoria : es muy poco probable que el sistema olvide el error, cualquier desarrollador puede.
Métricas : la cantidad de errores encontrados, cerrados y el tiempo empleado pueden ser buenas métricas fáciles de capturar para decirle cómo está progresando la calidad de su código
Urgencia : puede parecer la cosa más importante para el desarrollador en el mundo, sin embargo, el tiempo empleado en solucionar este problema puede ser mejor empleado en algo que los usuarios finales desean primero (consulte también la memoria ).
Duplicación : tal vez ya haya sido detectado y esté siendo examinado / arreglado por otra persona. Alternativamente, tal vez se haya apartado de la regla de urgencia y se haya pospuesto. Por supuesto, el hecho de que lo haya encontrado de nuevo no solo significa que no se debe hacer, sino que puede significar que (a medida que sigue apareciendo) eso es ahora más urgente de solucionar.
Análisis de causa raíz : el error más fácil de corregir es el que nunca estuvo allí. Puede ser que el equipo deba estar observando este error para descubrir cómo llegó a ser. Definitivamente, esto no es para castigar al responsable (que nunca ayuda) sino para averiguar cómo se puede evitar la situación en el futuro.
Análisis de impacto más amplio : el error más barato de encontrar es el que conocía antes de encontrarlo. Al observar este error (especialmente después de hacer el análisis de la causa raíz), puede quedar claro que este problema podría existir en otros lugares del código. Como resultado, el equipo puede elegir encontrarlo antes de que levante su fea cabeza en un momento más embarazoso.
La cantidad de tiempo que se gasta en estos (si corresponde) depende en gran medida de la madurez y el nivel de calidad del código. Es probable que el análisis de la causa raíz sea excesivo para un pequeño equipo que trabaja en el código de demostración, pero es probable que un equipo grande en desarrollo empresarial crítico necesite aprender las lecciones de manera efectiva y eficiente.
Por experiencia, hay dos razones generales por las que los desarrolladores evitan usar la herramienta:
- La herramienta de manejo de errores y / o el proceso se perciben como demasiado pesados para el desarrollo
- Los desarrolladores encuentran que el desafío mental de arreglar el error es más interesante que las cosas en las que están trabajando actualmente.
El artículo 1 implica que puede requerirse un sistema mejor / más simple; o alternativamente, podría ser necesaria una justificación más convincente del sistema existente.
El elemento 2 debe ser una señal de advertencia útil para el líder de desarrollo sobre las asignaciones de tareas actuales.