Cuando llega por la mañana, descubre que su software ya no funciona, aunque lo hizo cuando se fue ayer por la noche.
¿Qué haces? ¿Qué compruebas primero? ¿Qué haces para dejar de estar enojado y comenzar a trabajar en tu problema? ¿Culpas a tus colegas y vas directamente a ellos? ¿Qué se puede hacer para evitar estar en una situación así?
Los sospechosos habituales son:
Pensaste que funcionaba ayer, pero después de un día completo de trabajo estabas demasiado ciego para darte cuenta de que no funcionaba.
Esta mañana ya no puede consultar lo que había en la memoria caché del IDE ayer.
La estación de trabajo se reinició la noche anterior o una operación de mantenimiento nocturno borró los directorios / tmp.
Algo ha cambiado en la base del código: verifica si alguien (posiblemente tú) ha realizado cambios entre tu última compilación de ayer y tu última compilación de hoy.
Algo ha cambiado en las bibliotecas de soporte: verifique si esas bibliotecas han sido compiladas o actualizadas. 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: la nueva versión de una máquina virtual, un talón que se ha modificado, los 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 ...
1) Si no funciona hoy, tampoco funcionó ayer.
Usted pensó que estaba funcionando, pero no lo estaba.
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 supongo que leí tu pregunta), significa que deberías hacer un mejor trabajo al probar tu código antes de que realmente indique que está funcionando.
Para evitar esta situación, debes realizar Pruebas y Depuración .
Defina "trabajo" y pruebe los límites de las rutinas de su código.
Una forma de hacer esto es tener un conjunto automatizado de pruebas extensas durante la noche, para que al día siguiente pueda verificar si algo salió mal y solucionar los problemas.
Tratar de encontrar a alguien para pasar la culpa 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 raza) y el hecho de que funcionara ayer fue solo suerte, o algo ha cambiado entre entonces y ahora, y debes encontrarlo. fuera lo que es.
La forma exacta en que descubres cuál es el caso y cómo se puede solucionar depende de los aspectos específicos de la situación, pero siempre ayuda a ser metódico en la eliminación de causas, es decir, no cambies 5 cosas a la vez y dejas de mirar 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, generador de perfiles, herramientas de análisis de red) también puede hacer una gran diferencia.
He trabajado con el código que pareció 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 pícaros malévolos se arrastraban a mi código base por la noche y cambiaban las cosas de tal manera que, a pesar del hecho, funcionó ayer. , ahora no funciona en absoluto. De hecho, en el estilo clásico de Schroedinbug , no solo no funciona ahora, también está claro que no hay forma que alguna vez podría tener.
Con el tiempo me he dado cuenta de que es posible que, de hecho, los duendecillos no tengan nada que ver con eso y que posiblemente mi "tiempo de irse a casa, sea lo suficientemente bueno", la última versión no reciba las pruebas y la atención detalladas que tal vez lo merezca.
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 esquinas de software en las que estoy trabajando. Mi segunda suposición es que bien podría conseguir ese café ahora. Si no es algo obvio que un mono pueda descubrir (lo que a veces es), entonces hay muchas posibilidades de que haya logrado arrastrar una versión antigua de una biblioteca, y por error me he deshecho de un archivo que no era necesario deshacer. Volver o tener algo en caché en algún lugar que lo llevó a la compilación sin comprobarlo. Ir a través de mi actividad reciente de Source Control tiende a revelar cosas que he hecho, al limpiar la compilación a menudo se eliminan 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 por lo general es un caso de gestión y aceptación que, como la mayoría de las personas, soy básicamente un idiota.
Usa el control de versiones. Haz una diferencia o usa la funcionalidad de culpa de tu VCS:
diff : cada VCS. Te muestra las diferencias de, uhm, diferentes versiones blame : por ejemplo git. Le muestra en línea por línea quién ha cambiado qué Si no hay un control de versión, aparte de que es culpa 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: Recompila todo, asegúrate de recompilar también las bibliotecas auxiliares.
Por supuesto: si ha encontrado la fuente del error, mantenga la calma, pregunte por qué se hizo un cambio, explique su problema y proponga una solución que los haga felices a los dos. No le grites a él / ella, eso sería un veneno para tu productividad.
Si no hay cambios, 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.
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 fracasó el 9 de agosto. 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é debe verificar primero es volver a verificar cómo formatea sus fechas, porque si combina los campos día y mes funcionará perfectamente, pero solo en 1 día por mes: - )
Solucione el error (como lo hace normalmente). Luego, si encuentra quién lo causó, envíeles un correo electrónico cortés para informarles qué salió mal.
Todos los programadores cometen errores y, si empiezas a culpar, la próxima vez que hagas lo mismo será contraproducente. (posiblemente incluso este error fue tuyo)
Solo si sospechas que son descuidadas en caso de que hagas un gran problema con un par de errores.
... ejecuta pruebas de regresión y se enfoca en las que fallan.
En realidad es lo que olvidó hacer ayer antes de irse, sucede.
¿No tienes ninguna? Ok .. que dices Blaming ? Bueno ... que podría funcionar, entonces
Lo primero que debe hacer cuando algo deja de funcionar es preguntarse: ¿Qué es diferente? ¿Qué ha cambiado?
Cuando algo funcionó anoche pero falla esta mañana, lo único que obviamente ha cambiado es: la fecha y la hora :)
Lo intentaría y pensaría si hay alguna parte de la lógica en la que estoy trabajando, eso depende de las fechas y podría verse afectado por el paso del tiempo. Es sorprendente cuántas veces esa es la causa de tales problemas.
Si eso no funciona, definitivamente debería hacer un seguimiento de los otros excelentes consejos que se proporcionan aquí.
Una respuesta un poco corta (para escribir), pero un poco larga para entenderlo: Por qué los programas fallan: una guía para Depuración sistemática por Andreas Zeller (que puede parecer demasiado académico pero no lo es)
Usted busca en su buzón de correo después del correo enviado por el motor de Integración Continua cuando las pruebas de la unidad fallaron (o la página de registro si no vio ese problema específico), y ve quién hizo el registro solo antes de esa compilación.
Luego ve y habla con él.
Solo hay dos razones posibles por las que tu código falla hoy, pero funcionó ayer.
Mira los datos
Hay algo en los datos que no probaste y / o cuentas. Cualquiera de los datos no se ha validado correctamente o no se reveló un error en la lógica hasta que se produjo una condición lógica que usted no anticipó. Esto significa que el error estuvo allí ayer, pero se ocultó de usted con datos válidos.
Una vez tuve un código de entrada de orden funcionando bien durante semanas. Me fui a casa un día, 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 cabría en un entero. El sistema falló en el número de pedido 32768.
Mira qué ha cambiado
Mira lo que cambió ya que funcionó. ¿La sección de TI lanzó una actualización del sistema operativo? ¿Otro codificador modificó el código que usa tu programa? ¿Cambió el permiso del usuario? A menudo, si encuentra lo que ha cambiado, encontrará el error.
funciona especialmente bien para errores de JavaScript difíciles. Básicamente comente la mitad del código, vea si recibe el error, si lo hace está en esa mitad del código. La mitad de nuevo y continuar.
Si su código está bien encapsulado, esta es una herramienta fantástica que ahorra tiempo y evita 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.
Y, por supuesto, ¿qué se puede hacer para evitar estar en una situación así?
Para abordar esta pregunta, es posible que desee consultar 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 encuentren rápidamente.
En la práctica, la mayoría de los equipos que emplean CI utilizan un servidor de CI (consulte: Lista de Wikipedia ). El servidor CI generalmente se configura para monitorear el repositorio de SCM e iniciar una compilación cuando ve cambios. Cuando se complete la compilación, se ejecutarán una serie de pruebas automatizadas y se publicarán los resultados por correo electrónico y / o la 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 tienes un pequeño conjunto de cambios que ver, por lo que se resuelve más rápido.
Aquí hay otras preguntas sobre qué servidor de CI debe usar, por lo que le permitiré encontrarlas interesadas. Personalmente, soy un gran fan de Jenkins.
[¿Qué debo hacer acerca de las cosas que se rompen?]
Como ya han dicho otros, averigüe qué se rompió e intente solucionarlo. Pasar tiempo tratando de echarle la culpa es el tiempo empleado en no resolver el problema.
Mi reacción natural es siempre culpar a los demás, pero con el tiempo me he dado cuenta de que, por lo general, soy yo quien tiene la culpa. Además de todos los excelentes comentarios anteriores, es importante que se registre cuál fue la razón final. No importa si utiliza 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 encuentre la respuesta (¡y quiera volver al trabajo!) Es registrar la razón.
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 funciona", lo primero que debe hacer es recopilar más información sobre los síntomas del problema.
Entonces, comienza a buscar posibles causas, ya sea a través de registros o un intento de recreación del problema o una combinación de ambos, depende de cómo esté configurado su sistema, supongo.
Entonces comienzas a descartarlos.
Eso es lo que suele pasar cuando tomo vacaciones :-)
Más en serio, primero les diría:
Lo estudiaré para ver qué está mal y cuál podría ser la raíz
Tocaré la base en 30-60 minutos una vez que haya tenido la oportunidad de ver lo que está pasando
Después de ese tiempo, puedo arriesgar una estimación de lo que podría haber ocurrido y cuánto tiempo tomará la corrección si no está ya arreglada y, si corresponde, qué datos hemos perdido (pero tengo buenas copias de seguridad, así que eso nunca pasa con suerte).
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 miedo del insecto probablemente le enseñó una lección y, con suerte, no lo volverá a hacer.
si intencionalmente hizo algo que le dije que no hiciera (p. ej., dé la contraseña de root del servidor de producción al nuevo usuario y le diga que realice una modificación directamente sin supervisión) (sí, eso ya sucedió. ..), entonces tengo que mencionarlo.
Si sus métodos habituales de seguimiento de errores no funcionan y todo es un desastre, puede ser maravilloso tener una copia de seguridad que pueda restaurar fácilmente.
Esto es lo que ejecuto localmente, automáticamente cada hora de 8:00 am a 6:00 pm:
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. Puedes usar rdiff-backup en Linux, mac y win.
Por supuesto, esta no debería ser tu ú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.
Es posible que el error ya haya existido, pero que haya estado oculto por factores externos o por problemas profundos del sistema.
Esto me pasó a mí. Un error desarrollado entre 2 compilaciones de nuestro proyecto. Literalmente, el único cambio que hicimos fue actualizar a una versión más reciente de la 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 de puntero malicioso que había estado latente en mi código durante años . De alguna manera, nunca se activó hasta que su refactorización haya cambiado la disposición del ejecutable.
estaba funcionando ayer porque se estaba usando correctamente.
encuentras 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 al comienzo del día, ya que esto te deja con un buen entorno de prueba.
Copia de seguridad!
Encuentro la configuración de puntos de interrupción para pausar y revisar mis datos muy útil, para identificar exactamente dónde y cómo va mal.