debugging - google tag manager preview mode
Corregir un error bajo severas restricciones de tiempo (14)
Recientemente tuve que corregir un error que se informó desde el campo. Mientras el equipo de prueba intentaba reproducir el problema, el cliente nos estaba aliviando el cuello y teníamos que tener el código de producción listo en solo una semana. Cuando finalmente pudimos reproducir el problema, nos quedaban solo 3 días. Mi colega y yo tuvimos que realizar casi 30 horas de esfuerzo continuo para encontrar la causa y tener la corrección en el lugar en el código que no fue escrito por nosotros. Afortunadamente lo hicimos Sin embargo, mi preocupación es que el equipo de prueba no tuvo suficiente tiempo para ejecutar sus casos de prueba habituales. Y tuvimos que pasar por alto otros errores triviales en el código para limitar los cambios en el código.
Me gustaría saber de parte de la comunidad cuáles son las mejores prácticas a seguir en esas condiciones de tiempo crítico. ¿Está bien descuidar otros problemas (que no son la causa del error en el que está trabajando)? Cómo limitar los cambios de código, también en el código heredado, tanto como sea posible, de manera que no tenga que preocuparse de que solo sea posible realizar pruebas mínimas. El trabajo continuo sin descansos suficientes también puede agregar sus problemas. Por favor comparte tus pensamientos y experiencia.
Creo que, por supuesto, está bien ignorar otros errores (más problemáticos) que pueda encontrar al intentar solucionar el crítico. Pero, por supuesto, no debe olvidarse e informarse en algún sistema de tickets.
Creo que la mayor parte del trabajo para obtener un resultado sin problemas en tal caso (que por supuesto sucede) debe ser anticipado para tener un buen conjunto de pruebas automáticas. De esa forma, al menos puedes asegurarte un poco más de que no introduces nuevos errores mientras arreglas ese. Revisiones de código y similares agregan a eso.
Entonces, al escribir software, quizás siempre piense en ese caso cuando necesite reaccionar rápidamente y prepararse para eso.
Cuando estás bajo presión extrema de tiempo, entonces tienes que hacerlo funcionar. Aún así, es crucial revisar su solución para asegurarse de que realmente soluciona el problema. Debe comprender el código involucrado, saber cómo sucedió el problema y asegurarse de que su solución sea la correcta. Con demasiada frecuencia, los parches se apresuran solo para que sean incorrectos y causan otro parche rápido.
En cuanto a los problemas encontrados en el camino ... tome nota de ellos y siga adelante. Asegúrese de volver a ellos, pero déjelos por ahora a menos que tengan una relación con el problema actual.
En general, es una situación desagradable y no hay una solución elegante. Solo asegúrate de moverte en una dirección en la que no tengas problemas.
Hay una serie de preocupaciones que esta pregunta plantea para mí.
He "estado allí, hecho eso" en lo que se refiere a trabajar toda la noche para intentar solucionar problemas. Puedo decirte de forma gratuita lo que probablemente ya sabes, a las 3 a. M. No estás pensando con claridad, y tus correcciones pueden estar causando más problemas de los que resuelven.
No solo esto, sino que en una cultura de trabajo que promueve esta locura, normalmente se espera que se presente al día siguiente a las 8 a.m., listo para continuar dando el 100%. Cuando eres joven, tu cuerpo puede hacer frente a una cierta cantidad de esto, pero en la mitad de los 20 vas a tener efectos secundarios graves. Diablos, incluso cuando eres joven, solo puedes dormir sin dormir durante tanto tiempo. Si conduce en un estado privado de sueño, puede terminar costándole la vida.
Espero que pueda presentar un buen caso de negocios a la administración de su empresa para prácticas más sensatas. Casi cualquier cliente (no importa cuán agresivo) pueda convencerse de que es mejor esperar una semana que arriesgar su negocio en un software con una falla destacada. El maratón de codificación de toda la noche podría estar bien para una situación rara, pero cuando se vuelve un lugar común, todos sufren.
La aplicación ha sido probada con sus casos de prueba habituales antes de comenzar a trabajar en ella. Entonces, si solo tiene un marco de tiempo pequeño para realizar un cambio específico, ese es el único cambio que debe hacer. Si bien deberías probar ese caso a fondo, y hacer tantas pruebas de regresión como sea posible, probablemente estarás bien.
Una de las cosas que tal vez quiera recomendar a su jefe es que, al haber visto el código heredado, mencionar que descubrió otros defectos menores en el código, y quizás deba ejecutar una versión de mantenimiento en la aplicación. De esta forma, puede regresar y con más cuidado, limpiar los otros problemas que descubrió y tener tiempo para una ronda completa de pruebas.
No hay nada que le impida continuar trabajando para que la solución sea lo más estable posible después de que se haya realizado la versión de reparación de errores inicial.
Lo más importante es detener el fuego y hacer feliz al cliente.
Una vez hecho esto, tendrá que programar trabajo adicional para que todo funcione; arregle los errores de "entorno", haga que el control de calidad pase por los planes de prueba, y luego puede crear otro lanzamiento "oficial" que solucione oficialmente el problema inicial y con un mayor nivel de seguridad.
No importa lo que hagas, tu software contendrá errores .
Todo lo que puede hacer es lo mejor posible dentro de las limitaciones de tiempo que su jefe / compañía especifique.
Realmente depende del problema en cuestión.
Recientemente hablé con un desarrollador que trabajaba en una empresa de marcapasos. Por muy crítico que fuera, simplemente no podían apurar las cosas. Pero si surge la necesidad, tenían algún hardware que verificara el comportamiento del software y restablecieran el marcapasos a un estado de "guardar".
Por otra parte, si se pierde dinero real, la necesidad de repararlo rápidamente podría ser mayor, es decir, la necesidad de repararlo de manera segura y completa.
Haga lo que haga y solucione, asegúrese de registrar todos sus cambios y revisarlos en cámara lenta para verificar posibles errores.
Si nota algo incorrecto en la fuente, que nunca ha producido un problema, ¡no lo arregle sin una extensa prueba!
Puede que descubras que nunca se invocó el código incorrecto, pero también podría haber algo mal en otro lugar, que es ''arreglar'' este error, ¡y cambiar la fuente para hacer lo correcto podría romper la aplicación!
Entonces, si no tienes suficiente tiempo para las pruebas, ¡no arregles cosas que no estén relacionadas con tu problema actual! Tenga en cuenta esto, corríjalo más tarde con pruebas exhaustivas.
Si siente que la presión del cliente lo está forzando a corregir un error y a implementarlo sin suficientes pruebas / escrutinio, le sugiero que le informe al cliente que el error está solucionado, pero no se ha probado completamente. Dígales cuánto tiempo les tomará evaluar completamente y darles la opción. Si el error es tan importante como lo han descubierto, es casi seguro que se utilizarán inmediatamente, pero será su elección y habrá más posibilidades de que entiendan lo que sucede si las cosas van mal más tarde. Si estuvieran ejerciendo presión sobre algo que en realidad no era tan importante, es de esperar que te permitan probarlo primero.
Si trabajas en un plazo ajustado, necesitas concentrarte. Entonces, si ve algún código que grita " límpiame" , pero no tiene nada que ver con el problema en cuestión, haga una breve nota para volver a visitar este lugar más adelante, pero no lo refaccione ahora. No solo está bien hacerlo, es obligatorio.
Una buena práctica es obvia: "Trabajar continuamente sin suficientes interrupciones"
Otro es ponerle comercialmente de cabeza y usar algo de sentido común, ¿cuál es el riesgo de que haya introducido a otro como un error serio o más serio? ¿Cómo reaccionará el cliente ante eso? ¿Cómo reaccionará el cliente si explica su necesidad de más tiempo? Pondere las respuestas y tome una decisión comercial / ejecutiva.
Ya hay algunos buenos consejos aquí, pero me gustaría agregar algo más:
Si solo logras corregir un error bajo una presión extrema de tiempo, recuerda volver y ver esa solución cuando la presión esté baja para asegurarte de que no se trata simplemente de un hack horrible que es una tirita sobre un problema real.
Allá por la década de 1980, arreglé un error que estaba muy abajo en un programa muy antiguo. Pero no funcionaba bien en un caso que solía funcionar. Cuando investigué más, descubrí que se había implementado un trabajo "temporal". El comentario dijo:
C TEMPORARY WORK-AROUND UNTIL I FIND THE REAL CAUSE. I CHARNY, SUMMER STUDENT, AUG 1971
Irv Charny era mi jefe cuando encontré este "trabajo temporal temporal" de más de 15 años.
En primer lugar, creo que debe separar el "drama emocional" y tomar una decisión desapasionada sobre si corregir el error es de hecho una prioridad más alta que lograr el lanzamiento. Espero que ese sea el trabajo de otra persona. Deberían evitarle a los desarrolladores la presión de todos los que "el cliente está respirando por nuestros cuellos". Si el cliente también está esperando el lanzamiento, tal vez pueda devolverse a ellos, que arreglar este error retrasará el lanzamiento.
Luego, cuando Daniel dijo "trabaja lo más rápido posible, pero no más rápido". Si el cliente se está quejando, o incluso está perdiendo ingresos, eso realmente no afecta su capacidad para corregir el error, ni lo soluciona rápidamente.
En cuanto a la solución, haría el mínimo indispensable para solucionar ese error específico. De ser posible, escribiría un bloque de código aparte para manejar la (con suerte) una condición que causa la falla, y dejaré todo lo demás en paz. La idea es aislar ese problema y saber (algo así como) que nada más va a romperse debido a los cambios. Y para poder probar fácilmente esa única condición.
La respuesta altamente calificada de AnthonyWJones está en lo cierto, básicamente
Otro es ponerle comercialmente de cabeza y usar algo de sentido común, ¿cuál es el riesgo de que haya introducido a otro como un error serio o más serio? ¿Cómo reaccionará el cliente ante eso? ¿Cómo reaccionará el cliente si explica su necesidad de más tiempo? Pondere las respuestas y tome una decisión comercial / ejecutiva
Pero, ¿qué significa "pesar" las respuestas? Significa que empiezas a asignar pesos a las cosas literalmente: te detienes, tomas un descanso, haces una lista y lo piensas bien. ¿Deberías decirle al cliente que es imposible? ¿Cuál es el riesgo de que un pequeño error sea un impedimento para el espectáculo que haya introducido en su carrera frenética de una semana?
Obviamente, no hay respuestas establecidas, pero en general, trabajo lo más rápido posible pero no más rápido. Algunos clientes solo respiran por el cuello por diversión, pero otros errores son tan importantes que no importa qué más se rompa y los arregla. No puede determinar eso sin la ayuda de su cliente. Recuerde, todos están trabajando hacia el mismo objetivo.
Si el cliente está demasiado ocupado para hablar con usted, debe explicar (en el correo electrónico, o en las manchas de sangre, lo que sea) que va a cortocircuitar la garantía de calidad y tal vez introducir otros errores en el proceso. Tendrá que hablar, brevemente, sobre la probabilidad de que esos sean más importantes que el error en cuestión. Usted tiene experiencia y sabe lo que está haciendo (hasta cierto punto), por lo que debe ayudar al cliente a comprender cuán enojado (o no) es lo que está pidiendo.
De todos modos, después de divagar un poco, este es mi punto: su trabajo es mantener la calma y hacer su trabajo. Dudo que al trabajar muchos días sin descansos encontraras el error más rápido : probablemente intentabas ir demasiado rápido. Su trabajo también es informar a su cliente sobre qué es posible, qué no, y qué riesgos se incurren con cada decisión. Pero ir más rápido que tu más rápido, como no tomar descansos, no tiene sentido y no ayuda a nadie.