¿Con qué frecuencia los programadores de tiempo completo se encuentran con un error que tarda un tiempo en solucionarse?

¿Con qué frecuencia? Depende completamente de cuánto código completamente nuevo estoy escribiendo. Si en su mayoría agrego una característica menor que es similar a otras, los errores difíciles de encontrar en su mayoría no aparecen.

Por otro lado, si estoy usando nuevas herramientas, un nuevo lenguaje de programación (o una nueva versión importante de la misma), un nuevo marco, incluso una nueva biblioteca, entonces los errores que consumen mucho tiempo son más probables.

Los peores son las pérdidas de memoria o errores de tiempo. Estos tipos de errores pueden ser difíciles de replicar y, a veces, pueden moverse en el código. He tenido errores que desaparecen cada vez que pongo una declaración impresa tratando de localizarlos. Otros que ocurrieron una vez cada pocas semanas al parecer al azar. Como dijo Moray en otra parte, los errores como estos pueden tardar mucho tiempo en rastrearse, y mucho menos solucionarlos.

A menudo, la solución es simple, aunque he tenido al menos un caso en el que requirió una reelaboración bastante significativa de parte del código para evitar el problema. Ese implicaba una combinación de código multiproceso y una pérdida de memoria causada por una mala sincronización entre subprocesos. Tomó meses localizarlo, porque dependía completamente de que varios usuarios trataran de acceder a pocos valores de datos al mismo tiempo. Esto fue en la reproducción de datos que se ejecutan en miles de muestras de segundo.

Casi todos los desarrolladores se encuentran con problemas como este si realizan una cantidad significativa de trabajo. Nadie está contento con el tiempo dedicado a encontrarlos, pero todos nos damos cuenta de que a veces sucederá.

Ni siquiera un error a veces. Es fácil mirar una característica que se propone y decir “¿En serio? Esa es una historia de 1 punto. ”Hasta que ingrese a las pruebas fallidas, los datos incorrectos, los problemas del entorno y las cosas inesperadas que necesitaba aprender para resolver esa cosa que solo le tomó 1/2 día.

Esta es también una gran razón para realizar buenas pruebas antes de desarrollar fusiones. Cuanto más escribes las pruebas, menos gravosas y más útiles se vuelven. Y soy bastante novato con las pruebas, pero aprecio lo que hace y puede hacer.

Pero la simple corrección de errores, la mayoría de las veces, es cuando encuentras a alguien con quien emparejarte. Nunca he sido suscriptor de la filosofía de programación de 100% de pares, ya que se siente sofocante e intrusiva. ME ENCANTA el emparejamiento y el aprendizaje (incluso a costa de mi propia vergüenza) sobre cosas que no sabía antes, porque puedo usar esa información la próxima vez.

tl; dr Muy a menudo.

Es común.

A veces, los errores pueden tardar meses en solucionarse, no porque sea difícil, sino porque no puedes encontrar la maldita cosa. Obtendrá un informe de error de un cliente, el seguimiento de la pila no le dice nada y no es replicable …

La reparación de un error suele ser muy fácil, es encontrarlo que lleva tiempo.

Sí, he tenido errores causados ​​por cosas realmente tontas, sucedió uno un poco vergonzoso hace unos días …

Un método no devolvía un valor válido, a pesar de que puse una ‘impresión’ que demostraba que era … Resulta que, cuando estaba haciendo clic en Comando en un método en Xcode, para llevarme a ese método, Xcode me estaba llevando al método equivocado ! ¡Estaba poniendo mis declaraciones impresas en el lugar equivocado! Si hubiera movido mis ojos hacia la barra de pestañas, habría visto que no era la clase que había pedido, pero no …

No había nada realmente malo con mi código, una solución de 5 segundos, pero estaba asumiendo que Xcode estaba haciendo lo que le pedí, y no fue así.

La suposición es la madre de todas las cagadas.

Los errores suelen ser muy fáciles de solucionar. Encontrarlos no lo es.

La frecuencia con la que aparece realmente depende de muchas cosas. No creo que estés solo en esos errores que tardan un tiempo en encontrar son una solución muy rápida. Yo diría que en la mayoría de los errores que he solucionado, el 10% del tiempo se dedica a solucionar el error, mientras que el otro 90% se dedica a encontrar, verificar y probar mi solución para garantizar que cubra todos los casos.

La frecuencia también tiene una gran parte que ver con qué tan bien conoce la aplicación, el idioma, el marco, las bibliotecas, etc. que se utilizan en una aplicación.

Como ejemplo, formé parte de un equipo que creó sitios web en una plataforma CMS personalizada y personalizada. Cuando comencé, me encontré con errores como usted describe que me tomó un tiempo solucionar con bastante frecuencia. Sin embargo, a medida que pasó el tiempo, mi tiempo por error disminuyó. Este aumento de eficiencia no se produjo necesariamente porque era un mejor programador, sino porque conocía el sistema, cómo funcionaba y dónde surgían los problemas.

Incluso con la experiencia difícil de corregir, los errores a veces surgen, aunque es menos que antes.

La complejidad y la calidad de una aplicación también jugarán un papel importante en el tiempo que tardan en solucionarse los errores. Algo con muchas piezas será más difícil de razonar que una aplicación más simple. Si está trabajando en una aplicación grande con muchas piezas, es mejor dedicar un poco más de tiempo y verificar que una solución no afecte a otras partes que empujar apresuradamente una solución.

La calidad del código también juega un papel importante. Las aplicaciones creadas sin ningún tipo de separación de preocupaciones o estándares de codificación son una pesadilla para trabajar. El código de mala calidad puede agregar horas o días a lo que habría sido una solución simple.

Hay muchas cosas que influyen en la respuesta a su pregunta, por lo que es difícil dar una respuesta definitiva. Sin embargo, en general, los errores pueden tardar un tiempo en darse cuenta, especialmente si eres nuevo en ese sistema en particular.

No soy un programador a tiempo completo (tal vez el 10%), pero trabajo con muchos proyectos.

Si encuentro (o me dicen) un error que no puedo localizar de inmediato (generalmente puedo), entro en pánico un poco y luego trato de separarlo para ver cuál puede ser o no la causa.

El comportamiento similar a un error desagradable más reciente fue una situación en la que hacer ciertas cosas en una aplicación web provocaba el cierre de sesión. No se hicieron preguntas. Lo peor era que ni siquiera estaba en mi propio código, sino más bien al hacer ciertas cosas en TinyMce.

Noté que todas las variables de sesión desaparecieron cuando esto sucedió, por lo que claramente de alguna manera usó una sesión diferente, ya que no había nada de malo en el código.

Primero, cuando revisé la fuente HTML, vi información de Barniz que difería entre las páginas. Al principio pensé que eso podría estar perfectamente bien, y tal vez lo estaba, pero de todos modos desactivé a Varnish para estar seguro. El problema se fue.

A pesar de la oscuridad, esto quizás tomó una hora para localizarlo y arreglarlo.

Todavía encuentro el barniz un poco opaco, así que decidí no usarlo por el momento. Cuando entiendo su filosofía de almacenamiento en caché, podría usarlo nuevamente.

También recientemente descubrí que las solicitudes a una API en mi sistema comenzaron a fallar. Después de buscar errores, descubrí que la información de OAuth había desaparecido del encabezado HTTP.

Después de rascarme la cabeza, descubrí que WordPress (que se ejecuta en el mismo dominio que mi aplicación) había sobrescrito una configuración en .htaccess que asignaba el encabezado de autenticación al insertar configuraciones relacionadas con la caché. Por alguna razón, esto es necesario en los VPS, y sin esa asignación, los datos de OAuth simplemente desaparecieron. Reescribí .htaccess y cambié al almacenamiento en caché basado en PHP, para que WordPress dejara de jugar con .htaccess. Problema desaparecido

En cuanto al tiempo de entrega, esto tomó una semana, ya que incluso la empresa que realizó la solicitud de API pensó que era su culpa. El tiempo del hombre tomó algunas horas, principalmente para localizar el problema. Ahora el código se registra cada vez que desaparece la autenticación.

El tiempo de corrección de errores es inversamente proporcional a la experiencia de trabajar en esa aplicación y directamente proporcional a la complejidad y la naturaleza siempre cambiante de la aplicación.

Dejame explicar:

Motivo de la primera parte (inversamente proporcional a la experiencia de trabajar en esa aplicación):

• Siempre que nos tome mucho tiempo arreglar un error, recordaremos lo que nos ayudó muy bien. Puede ser una declaración impresa, depuración, no depuración, mala ubicación del código, sobrescrituras inesperadas, conocimiento específico de la aplicación, etc. Cada una es un arma. Cuando tenemos más de esas armas, solo es cuestión de elegir el orden correcto de las armas para matar rápidamente el error.

Motivo de la segunda parte (directamente proporcional a la complejidad y la naturaleza cambiante de la aplicación):

• Vamos, ya sabes esto …

¡Feliz corrección de errores!

Ayer resolví un error que llevó a un equipo de 3 personas en 2 compañías a diagnosticar aproximadamente 10 horas cada una.

En general, sin embargo, a medida que las aplicaciones maduran, las instancias de este tipo de cosas se desvanecen. Estoy trabajando en una nueva aplicación que tiene errores difíciles, probablemente una vez cada semana o dos. Mientras tanto, tengo otra aplicación que tiene casi 3 años. Si bien tiene errores de vez en cuando a medida que agregamos funciones, la gran mayoría de los errores son correcciones de 10 a 15 minutos.