"¡Estaba funcionando ayer, lo juro!" ¿Qué puedes hacer? [cerrado]

59

Cuando llega por la mañana, descubre que su software ya no funciona, a pesar de que lo hizo cuando salió ayer por la noche.

¿Qué haces? ¿Qué revisas primero? ¿Qué haces para dejar de estar enojado y comenzar a trabajar en tu problema? ¿Culpa a sus colegas e ir directamente a ellos? ¿Qué se puede hacer para evitar estar en tal situación?

Nikko
fuente
10
Culpar nunca es una gran idea. Como no ha elaborado la pregunta o el problema, es imposible adivinar que el programa no produjo el error en sí. Por ejemplo: si un sitio web en un servidor de alojamiento alcanza el límite de ancho de banda, se cae solo. Por lo tanto, no puede culpar a nadie hasta que esté seguro de que el código no se comportó adecuadamente en primer lugar.
Pankaj Upadhyay
1
bueno, eso no está en el desbordamiento de la pila, así que es una pregunta más general La parte de la culpa es una broma :)
Nikko
28
@ Nikko - tampoco funcionó ayer. ESO es lo que sucede mucho en el desarrollo de software :)
Joris Timmermans
44
Para evitar estar en la situación, no apresure las pruebas para poder implementar en los últimos minutos de la tarde. Y quítese las gafas de sol sensibles al rosa / al peligro mientras prueba.
Steve314
18
¿Tiene algo que ver con DateTime.Now () ???
Sarawut Positwinyu

Respuestas:

96

Los sospechosos habituales son:

  • Pensaste que funcionó ayer, pero después de un día completo de trabajo estabas demasiado ciego para darte cuenta de que no funcionó.

  • Esta mañana ya no puede referirse a lo que estaba ayer en la memoria caché IDE.

  • La estación de trabajo se reinició anoche o una operación de mantenimiento nocturno borró los directorios / tmp.

  • Algo ha cambiado en la base del código: verifique si alguien (posiblemente usted) ha cometido cambios entre su última compilación de ayer y su última compilación de hoy.

  • Algo ha cambiado en las bibliotecas de soporte: compruebe si esas bibliotecas se han recompilado o actualizado. La causa puede estar dentro del proyecto para bibliotecas específicas o fuera si se ha implementado una nueva versión de un paquete aparentemente independiente.

  • Algo ha cambiado en el entorno de prueba: nueva versión de una máquina virtual, un trozo que se ha modificado, cambios en un servidor de base de datos remoto ...

  • Algo ha cambiado en la cadena de compilación: cambios en Makefiles, nueva versión de IDE, de compilador, de bibliotecas estándar ...

mouviciel
fuente
82
Olvidó la "intervención divina" y "una partícula de alta energía atravesó el servidor y reordenó bits al azar". Y erupciones solares.
Kheldar
17
Olvidó "está usando <inserte aquí su idioma menos favorito>, lo cual es notoriamente poco confiable.
Configurador
44
@Kheldar: no olvides sprites maliciosos, gremlins y otros.
5arx
55
@configurator: es por eso que siempre debes escribir tu propio idioma. ¡Pregunta a Spolsky sobre Wasabi! comprueba si Atwood está cerca y huye
Kheldar
13
Otro obstáculo clásico es el cambio de fecha. Por supuesto, esto es especialmente cierto para las fechas "límite" (primer o último día del mes / semana, 29 de febrero, etc.).
Brann
49

1) Si no funciona hoy, tampoco funcionó ayer.

Usted pensó que estaba trabajando, pero no lo era.

2) Hay un problema y debe resolverse .

No pienses en quién es responsable de esto o en culpar a otros.

Si nada ha cambiado entre ayer y hoy (como presumo leyendo tu pregunta), significa que deberías hacer un mejor trabajo al probar tu código antes de decir que realmente funciona.

Para evitar esta situación, debe realizar las pruebas y la depuración adecuadas .

Defina "trabajar" y pruebe los límites de sus rutinas de código.

  • Intenta convertirte en uno de los usuarios que utilizarán las funcionalidades de tu programa o código.
  • Empuje su código a los límites permitidos y más allá, y realmente verifique si se rompe.

Una forma de hacerlo es tener un conjunto automatizado de pruebas exhaustivas que se ejecutan durante la noche, para que al día siguiente pueda verificar si algo salió mal y solucionar los problemas.

revs Jose Faeti
fuente
77
Quiero darle dos votos a favor: uno para "Si no funciona hoy, tampoco funcionará ayer". y uno para "hay un problema y hay que resolverlo". Ambas son ideas clave que muchas personas olvidan.
MattBelanger
2
"Si no funciona hoy, tampoco funcionará ayer". -> Esto me sucedió ayer haciendo una codificación frontal que dependía de una cookie. Funcionó muy bien cuando la cookie ya se había configurado. Descubrí que ya no se creaba correctamente al día siguiente una vez que había expirado y estaba tratando de volver a crearlo.
Graham
@Graham: vea "Si nada ha cambiado entre ayer y hoy, [...] significa que debería hacer un mejor trabajo al probar su código antes de decir que realmente está funcionando". Debe ser mejor probando su código, pensar en lo que debería suceder, pensar en lo que PUEDE suceder. Quizás con una mejor comprensión del problema, no hubiera sucedido.
Jose Faeti
En cuanto a 1): Tal vez el cambio radical fue en una biblioteca auxiliar
phresnel
No es estrictamente cierto ...: PI accidentalmente rompió una aplicación, al insertar algunos archivos de caché en mi aplicación que eran objetos que se habían serializado completamente de manera incorrecta. La aplicación estaba bien y funcionaba bien, solo que cuando hice un git pull, porque los archivos de caché estaban ignorados, el programa se actualizó y necesitaba los objetos en un formato diferente. Sin embargo, todavía recibes el
voto positivo
26

Intentar encontrar a alguien a quien culpar no es constructivo y no resuelve los problemas. No lo hagas

Si algo funcionó ayer y no funciona ahora, entonces tienes un comportamiento no determinista (como una condición de carrera) y hacerlo funcionar ayer fue solo suerte, o algo ha cambiado entre entonces y ahora, y necesitas averiguar qué es.

La forma exacta de averiguar cuál es el caso y cómo se puede solucionar depende de los detalles de la situación, pero siempre ayuda a ser metódico para eliminar las causas, es decir, no cambie 5 cosas a la vez y deje de buscar si eso ayuda. descubra qué cosa específica causó el problema y tal vez escriba cómo solucionarlo para que pueda buscarlo cuando vuelva a ocurrir dentro de 3 semanas.

El uso de las herramientas de diagnóstico apropiadas (depurador, perfilador, herramientas de análisis de red) también puede marcar una gran diferencia.

Michael Borgwardt
fuente
También puede ayudar mantener notas escritas mientras se analiza el problema.
Starblue
25

He trabajado con un código que parecía cambiar de la noche a la mañana y después de un tiempo llegué a la conclusión de que esto se debía a que los duendes malévolos se arrastraban hacia mi base de código por la noche y cambiaban las cosas de tal manera que, a pesar del hecho de que funcionaba ayer, ahora no funciona en absoluto De hecho, en el estilo clásico de Schroedinbug , no solo no funciona ahora, está claro que no hay forma de que alguna vez pueda funcionar.

Con el tiempo, me di cuenta de que es posible que, de hecho, los duendes no tengan nada que ver con eso y que posiblemente mi "hora de ir a casa, eso será lo suficientemente bueno" la última compilación no reciba las pruebas detalladas y la atención que tal vez merece .

Mi primera suposición cuando me encuentro con esto por la mañana es que probablemente sea mi culpa, ya que generalmente soy el responsable de mis propias características o rincones de software en los que estoy trabajando. Mi segunda suposición es que bien podría obtener ese café ahora. Si no es algo descaradamente obvio que un mono podría descubrir (que a veces lo es), entonces hay muchas posibilidades de que haya logrado arrastrar una versión anterior de una biblioteca, por error, revirtió un archivo que no necesitaba ser rodado retroceder o tener algo guardado en algún lugar que lo introdujo en la compilación sin verificarlo Al pasar por mi actividad reciente de control de código fuente, tiende a revelar cosas que he hecho, limpiar la compilación a menudo elimina las versiones en caché errantes.

A veces realmente no tiene nada que ver conmigo: alguien actualizó una dependencia sin mencionarlo, WindowsUpdate instaló algo que cambió el entorno para que mi código no funcionara; Hay muchas posibilidades de fondo, pero generalmente es un caso de dotación y aceptación de que, como la mayoría de las personas, soy básicamente un idiota.

glenatron
fuente
1
Esta es una respuesta muy humilde y autocrítica que muchos de nosotros deberíamos adoptar. :) Por lo general, atribuyo este tipo de situaciones a "¡Hola Moe, Hola Larry, estaba tratando de pensar y no pasaba nada!" al final del día. También utilizo el método de "¡Funciona! Rápido, revísalo y vete a casa antes de que tengas ganas de mejorarlo" al final del día, para evitar estas situaciones.
Jennifer S
3
En un lugar donde trabajaba, el código de nadie funcionaría a primera hora de la mañana. Resultó que cuando arrancamos nuestras máquinas, Skype tomaría el puerto que la aplicación quería usar cuando se inició por primera vez.
thepeer
¿Quizás el duendecillo no es más que una variable no inicializada? A veces, la versión de depuración puede funcionar cuando falla la versión de lanzamiento (se bloquea o se comporta de manera diferente).
Jared Updike
20

Utiliza el control de versiones. Haga una diferencia o use la funcionalidad de culpa de su VCS .:

  • diff: Cada VCS. Te muestra las diferencias de, uhm, diferentes versiones
  • blame: por ejemplo git. Le muestra línea por línea quién ha cambiado qué

Si no hay control de versión, además de ser tuya o de tu jefe, puedes ver las fechas de cambio de los archivos y posiblemente ver las instalaciones de registro de tu sistema operativo.

Aparte de eso: recompile todo, asegúrese de recompilar también las bibliotecas auxiliares.

Por supuesto: si ha encontrado la fuente del error, mantenga la calma, pregunte por qué se realizó un cambio, explique su problema y proponga una solución que los haga felices a ambos. No le grites, eso sería un veneno para tu productividad.

Si no hay ningún cambio, es hora de ver qué ha cambiado en el sistema. Por ejemplo, recientemente las computadoras Mac OS se han actualizado a una nueva versión de Apache que ha invalidado algunas configuraciones.

3 revoluciones
fuente
1
Diff Ftw. Eso es lo que siempre hago.
Aditya P
2
@AdityaGameProgrammer: lo uso varias veces al día para ver lo que estaba trabajando ayer o antes de un descanso :)
phresnel
¿Sin control de versiones? Esa es realmente una perspectiva aterradora.
thepeer
+1 por hablarme de git blame... no tenía idea de que existía, pero es INCREÍBLE
Radu Murzea
11

Bueno, aquí hay un ejemplo de código de la vida real que "funcionó ayer" y no hoy ... Es de principios de este mes.

La aplicación en cuestión extrae información de una base de datos por fecha, y el comportamiento predeterminado es obtener datos para el día actual. Esto funcionó bien el 8 de agosto, pero falló el 9. No fue probado antes de esto. También habría funcionado el 9 de septiembre y el 10 de octubre ...

Otra pista es que estamos en el Reino Unido, la base de datos en cuestión estaba en los Estados Unidos ...

Entonces, mi respuesta a su pregunta sobre qué verificar primero es verificar dos veces cómo formatea sus fechas, porque si combina los campos de día y mes funcionará perfectamente, pero solo en 1 día por mes :-)

Steve
fuente
5

Solucione el error (como normalmente lo hace). Luego, si encuentra quién lo causó, envíeles un correo electrónico cortés para informarles qué salió mal.

Cada codificador comete errores y si comienzas a culpar, la próxima vez harás lo mismo. (posiblemente incluso este error era tuyo)

Es solo si sospechas que son descuidadas si haces un gran problema con un par de errores.

Tom Squires
fuente
5

... ejecuta pruebas de regresión y se enfoca en aquellas que fallan

En realidad es lo que olvidaste hacer ayer antes de irte, sucede.

¿No tienes ninguno? Ok .. que estas diciendo? Culpar ? Bueno ... eso podría funcionar, entonces

ZJR
fuente
5

Lo primero que debe hacer cuando algo deja de funcionar es preguntarse: ¿qué es diferente? ¿Que ha cambiado?

Cuando algo funcionó anoche pero falla esta mañana, lo único que obviamente ha cambiado es: la fecha y la hora :)

Intentaría pensar si hay alguna parte de la lógica en la que estoy trabajando que depende de las fechas y podría verse afectada por el paso del tiempo. Es sorprendente cuántas veces es la causa de tales problemas.

Si eso falla, definitivamente debe seguir los otros excelentes consejos que se proporcionan aquí.

revs urig
fuente
2
Los errores que involucran peculiaridades de tiempo, como cambiar dentro / fuera del horario de verano, son los favoritos (en octubre y marzo) ...
Julia Hayward
4

Usted mira en su buzón de correo después del correo enviado por el motor de Integración Continua cuando la (s) prueba (s) de la unidad fallaron (o la página de registro si no observó ese problema específico), y ve quién hizo el check-in justo antes de esa compilación .

Luego ve a hablar con él o ella.

usuario1249
fuente
4

Solo hay dos posibles razones por las cuales su código falla hoy, pero funcionó ayer.

Mira los datos

Hay algo en los datos que no probó y / o no tuvo en cuenta. O los datos no se validan correctamente o no se revela un error en la lógica hasta que ocurre una condición lógica que no anticipó. Esto significa que el error estuvo allí ayer, pero se estaba escondiendo bajo datos válidos.

Una vez tuve un código de entrada de orden funcionando bien durante semanas. Un día fui a casa y murió. La investigación al día siguiente reveló que tenía un error oculto en una cadena de llamadas a funciones. En un lenguaje débilmente escrito, declaró un número entero cuando debería haber usado un int largo. El idioma hizo la conversión entre los dos automáticamente hasta que no pudo porque el número excedía lo que cabía en un número entero. El sistema falló en el número de pedido 32768.

Mira lo que cambió

Mira lo que cambió desde que funcionó. ¿La sección de TI lanzó una actualización del sistema operativo? ¿Otro codificador modificó el código que usa su programa? ¿Ha cambiado el permiso del usuario? A menudo, si encuentra lo que cambió, encontrará el error.

Andrew Neely
fuente
3

Chuleta binaria

funciona especialmente bien para errores difíciles de JavaScript. Básicamente comente la mitad del código, vea si obtiene el error, si lo hace está en esa mitad del código. La mitad otra vez y continúa.

Si su código está bien encapsulado, esta es una herramienta fantástica, que ahorra tiempo y elimina el estrés.

Una vez que haya encontrado el código de culpabilidad, a menudo vale la pena aislar el error en su propia página de prueba.

chim
fuente
por supuesto, si su proyecto abarca varios archivos, esto puede extenderse * tos al azar * borrando la mitad de los archivos de su proyecto, definitivamente es una herramienta eficaz para eliminar el estrés (asegúrese de tener una copia de seguridad).
Lie Ryan
Sí, definitivamente asegúrate de tener una copia de seguridad.
chim
3

Y, por supuesto, ¿qué se puede hacer para evitar estar en una situación así?

Al abordar esta pregunta, es posible que desee examinar la Integración continua (CI) . En pocas palabras: CI es un proceso donde los desarrolladores con frecuencia (hasta varias veces al día) integran y prueban todo el código. La idea es que los cambios en un módulo que rompen otro módulo se encuentran rápidamente.

En la práctica, la mayoría de los equipos que emplean CI utilizan un servidor CI (ver: lista de Wikipedia ). El servidor CI generalmente está configurado para monitorear el repositorio SCM e iniciar una compilación cuando ve cambios. Cuando se complete la compilación, ejecutará una serie de pruebas automatizadas y publicará los resultados por correo electrónico y / o página web de la compilación y las pruebas, junto con los cambios que causaron la compilación. Con suerte, cuando algo rompe la compilación o las pruebas, solo tiene que ver un cambio muy pequeño, por lo que se resuelve más rápido.

Aquí hay otras preguntas sobre qué servidor CI usar, por lo que le dejaré encontrarlas interesadas. Personalmente, soy un gran admirador de Jenkins.

[¿Qué debo hacer para que las cosas se rompan?]

Como ya han dicho otros, descubra qué se rompió e intente solucionarlo. Pasar tiempo tratando de culpar es tiempo dedicado a no resolver el problema.

jwernerny
fuente
Sí, en el trabajo usamos Jenkins y es realmente útil. Podemos monitorear las compilaciones en diferentes sistemas y ver de inmediato qué falla. Incluso tenemos una baliza de garaje real que comienza a parpadear cuando falla una construcción.
Nikko
3

Mi reacción natural es siempre culpar a otros, pero con el tiempo me he dado cuenta de que generalmente soy yo quien tiene la culpa. Además de todos los excelentes comentarios anteriores, es importante que registre usted mismo cuál fue el motivo final. No importa si usa un Wiki que se comparte con otros miembros del equipo, un Twiki privado, Evernote, un libro de registro o una buena memoria. Lo importante, en el momento en que encuentra la respuesta (¡y desea volver al trabajo!) Es registrar el motivo.

Hormiga
fuente
2

Presumiblemente, si ya no funciona, ha identificado los síntomas de que no funciona, es decir, se cuelga o devuelve un cuadro de diálogo de error particular al usuario.

Si la única descripción del problema es "no está funcionando", lo primero que debe hacer es reunir más información sobre los síntomas del problema.

Luego, comienza a buscar posibles causas, ya sea a través de registros o intentos de recreación del problema o una combinación de ambos, depende de cómo esté configurado su sistema, supongo.

Entonces comienzas a descartarlos.

temptar
fuente
2

Eso es lo que suele pasar cuando tomo vacaciones :-)

Más en serio, primero les diría:

  • Lo investigaré para ver qué está mal y cuál podría ser la raíz

  • Tocaré la base en 30-60 minutos una vez que tenga la oportunidad de ver qué está pasando

Después de ese tiempo, puedo arriesgar una estimación de lo que podría haber sucedido y cuánto tiempo llevará solucionarlo si aún no está arreglado y, si corresponde, qué datos podríamos haber perdido (pero tengo buenas copias de seguridad, para que eso nunca suceda Ojalá).


En cuanto a la parte culpable:

  • si es solo un error tipográfico de un colega, no hay necesidad de mencionarlo: sucede una mierda y el susto del error probablemente le enseñó una lección y, con suerte, no lo volverá a hacer.

  • si intencionalmente hizo algo que le dije que no hiciera (por ejemplo, darle la contraseña de root del servidor de producción al nuevo chico y decirle que haga una modificación directamente sin supervisión) (sí, eso ya sucedió ...), entonces yo Tengo que mencionarlo.

picos salvajes
fuente
2

Si sus métodos habituales de rastreo de errores no funcionan y todo es un desastre total, puede ser maravilloso tener una copia de seguridad que pueda restaurar fácilmente.

Esto es lo que ejecuto localmente, automáticamente cada hora de 8am a 6pm:

rdiff-backup /path/to/mystuff /path/to/mybackup

Simple, ¿eh?

Si alguna vez tiene que restaurar algo, use

rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored

rdiff-backup solo almacena archivos que difieren. Puede usar rdiff-backup en Linux, mac y win.

Por supuesto, esta no debería ser su única copia de seguridad. Pero es una forma extremadamente fácil y económica de tener una copia de seguridad local.

Ahora, no recomendaría esto como un método normal de corrección de errores, pero si todo lo demás falla, es una alternativa.

olafure
fuente
3
el control de versión es más fácil
2011
@thepeer: absolutamente de acuerdo. Sin embargo, hay cosas que resisten el control de la fuente (especialmente en la programación de microcompromiso), como archivos binarios grandes. Estoy feliz de poder evitar tales proyectos la mayor parte del tiempo
Sehe
@thepeer: Realmente no pensé que alguien consideraría esto como una alternativa al control de versiones. Esa sería mi idea de un caos organizado :) De esta manera tienes una copia de tus cosas como si fuera ayer. No importa quién haya comprometido qué y cuándo al sistema de control de versiones. Su última confirmación también podría haber sido hace más de 2 días. Algunos proyectos tienen ciertos archivos ignorados del control de versiones.
olafure
@sehe: con git, que estoy usando actualmente, tienes tu propio repositorio personal, así que no hay excusa para no comprometerte en cada paso del camino.
thepeer
@olafure: cualquier sistema de control de versiones decente debería permitirle pagar / clonar el estado completo del sistema en cualquier punto dado.
thepeer
2

Es posible que el error ya haya existido, pero haya estado oculto por factores externos o problemas profundos del sistema.

Esto me paso a mi. Un error desarrollado entre 2 compilaciones de nuestro proyecto. Literalmente, el único cambio que habíamos hecho era actualizar a una compilación más reciente de una de las bibliotecas subyacentes.

Naturalmente los culpamos. Pero el único cambio que hicieron fue refactorizar algunos encabezados para una compilación más rápida. Estuve de acuerdo en que eso no debería haber roto el sistema.

Después de mucha depuración resultó que el problema era un error puntero falso que había estado latente en mi código durante años . De alguna manera, nunca se activó hasta que su refactorización había cambiado la disposición del ejecutable.

Matthew Scouten
fuente
1

funcionaba ayer porque se estaba utilizando correctamente.

usted encuentra que otras personas usan las cosas de una manera que no se supone que es una buena manera de romper cosas.

siempre es bueno actualizar el código temprano en el día ya que esto te deja con un buen entorno de prueba.

¡Apoyo!

Robert
fuente
-2

Considero que configurar puntos de interrupción para pausar y verificar mis datos es muy útil, para determinar exactamente dónde y cómo va mal.

DKC
fuente