Hilo random para variar de las peticiones de ayuda: ¿cuál fue el primer bug que os enseñó algo de verdad sobre programar, no solo «cuídate de este error concreto», sino algo más general sobre cómo pensar el código?

El mío: pasé una tarde entera convencida de que un bucle tenía un error de lógica, cuando en realidad el bucle estaba perfecto, el problema era que estaba modificando la lista sobre la que iteraba mientras iteraba sobre ella (quitando elementos dentro del propio for each). El código «parecía» saltarse elementos al azar, y no fue hasta que imprimí el índice en cada vuelta que entendí lo que pasaba. Desde entonces, cuando algo se comporta de forma «aleatoria» sin explicación aparente, lo primero que reviso es si estoy modificando una colección mientras la recorro.

Contad la vuestra, con o sin código.

Cristina

El mío fue un bug de condición de carrera en uno de mis primeros trabajos, con dos procesos escribiendo en el mismo fichero de log sin ningún tipo de bloqueo. Funcionaba perfectamente en local, en pruebas, en todos los sitios donde lo probé... y fallaba de forma completamente esporádica en producción, quizás una vez cada varios miles de ejecuciones, con líneas del log mezcladas o truncadas a medias.

Lo que me enseñó de verdad, más allá de la solución técnica concreta (que al final fue trivial, un lock de fichero), fue algo sobre cómo pensar en los bugs: que "funciona en mis pruebas" no significa "es correcto", significa "no he conseguido reproducir el problema en las condiciones que he probado". Un bug de concurrencia puede estar ahí desde el primer día, agazapado, esperando justo la combinación de timing que tus pruebas normales nunca generan porque tú, como desarrollador probando solo, casi nunca disparas dos ejecuciones exactamente al mismo tiempo.

Desde entonces, cualquier cosa que toque estado compartido (ficheros, variables globales, recursos externos) la trato con sospecha por defecto, aunque "en mis pruebas funcione perfecto todo el rato".

Pablo