¿Debo decirle a alguien que su compromiso causó una regresión?

Si solo te acercas a ellos para contarles sobre un error que cometieron, entonces, a menos que seas el mejor diplomático del mundo, será difícil no sonar como "¡Ja! ¡Mira este error que cometiste!" . Todos somos humanos y la crítica es difícil de tomar.

Por otra parte, a menos que el cambio sea completamente trivial y obviamente , normalmente me parece beneficioso hablar con la persona que cometió el cambio original como parte de mi investigación, solo para asegurarme de que estoy completamente seguro. Entiendo lo que está pasando, por lo tanto, la forma en que normalmente termino manejando estas situaciones es dirigiéndome a dicha persona y teniendo una conversación que es algo así:

  

Yo: Estoy trabajando en este error donde ... resumen de error ... y creo que he rastreado el problema para cambiarlo. hecho. ¿Puedes recordar para qué fue este cambio? / ¿Tienes tiempo para explicar este cambio?

Entonces, ya sea:

  

Ellos: Claro, eso es para manejar ... situación que no conocía ...

O algo parecido a:

  

Ellos: No, lo siento, no me acuerdo, me parece mal.

Al ir e investigar el cambio / error, el interlocutor original aprende de sus errores sin sentir que están siendo criticados *, y también existe una gran posibilidad de que usted también aprenda algo.

Si el interlocutor original no está cerca o está ocupado, siempre puede seguir adelante y descifrarlo todo por sí mismo, normalmente encuentro que hablar con la persona que originalmente hizo el cambio es más rápido.

* Por supuesto, esto solo funcionará si usted está realmente interesado en la ayuda de otras personas. Si solo estás usando esto como un método poco disimulado para decirle a alguien sobre un error que cometió, es probable que este sea peor que solo ser sincero al respecto.

Sé asertivo no agresivo. Siempre favorece decir algo similar a "esta pieza de código no funciona" frente a "tu código no funciona". Critique el código, no a la persona que lo escribió.

Mejor aún, si puedes pensar en una solución, arréglala y preséntala, asumiendo que tienes un sistema de control de versiones distribuido. Luego, pregúnteles si su solución es válida para el error que estaban reparando. En general, trate de aumentar tanto su conocimiento de la programación como el suyo. Pero hazlo sin que tu ego se interponga en el camino.

Por supuesto, deberías estar dispuesto a escuchar a otros desarrolladores que vienen a ti con el mismo problema y actuar como hubieras deseado que lo hicieran.

Sí, siempre . Como programador, tu trabajo es aprender de los errores.

Hacerles saber los errores que cometen les ayudará a convertirse en un mejor programador y reducir sus posibilidades de cometer errores en el futuro. PERO sea cortés y no le dé mucha importancia, todos creamos errores de vez en cuando. Me parece que un correo electrónico cortés es una forma muy poco agresiva de informar a las personas.

La forma constructiva es encontrar el error, corregirlo y tomar medidas para evitar que surjan errores similares en el futuro.

Si se trata de explicar a las personas cómo no introducir errores, inténtalo.

Una vez, trabajé en un equipo donde el gerente del proyecto nunca le dijo a un desarrollador en particular que cometió un error: organizó una reunión con todo el equipo donde explicó que se cometió un error y que se definió un nuevo proceso en Para suprimir ese tipo de errores. De esa manera, nadie fue estigmatizado.

En general, sí .

Nadie debe ponerse a la defensiva si tiene tacto al respecto. Una forma fácil de manejarlo es pedirles que vuelvan a verificar su cambio antes de volver a enviarlo al tronco (o lo que sea relevante para su sistema de control de versiones). La gente lo apreciará si les ahorras unos minutos arreglando errores obvios, pero no lo apreciará si arreglas algo que no se rompió y terminan rompiendo su código. Si les da la oportunidad de revisar su cambio, les dice que no quiere meterse de puntillas y les da la oportunidad de objetar sus cambios.

Si se trata de un gran cambio en lugar de un error tipográfico, es una buena idea darle un aviso al autor antes de que intente solucionarlo. "Joe, ayer estaba combinando mis propias cosas y encontré algo que no estoy seguro de entender. Parece un error, pero quería que lo hicieras tú antes de que juegue con tu código. ¿Podrías echarle un vistazo? yo?

Tu relación con el autor es un factor importante. Si no le importa que el autor arregle su código sin avisarle, y si está bastante seguro de que el sentimiento es mutuo, tal vez no valga la pena mencionarlo. Si es alguien con más experiencia / antigüedad / estatus, querrá decirles que cambiará su código. Si es alguien con menos, entonces considere si es el tipo de cosa que necesitan escuchar para evitar repetir el error o podría avergonzarlos innecesariamente.

Recuerde siempre que si puede averiguar quién verificó el "error", pueden descubrir quién "reparó" su código. Si cree que estarían molestos / enojados / avergonzados al enterarse de su cambio después del hecho, dígales de antemano.

Además, corregir el error no es tu única opción. Siempre puedes informar el error en tu rastreador de problemas. Aquí se requiere nuevamente el tacto: informar el error lo hace más visible para todo el equipo, pero también le da al autor la oportunidad de corregir su propio error. Informar es la mejor opción si no está seguro de cuál es la mejor manera de solucionar el problema o si simplemente no tiene tiempo para solucionarlo.

Si hago un commit que incluya un error, será mejor que me lo digas. Si encuentro una confirmación tuya que incluya un error, seguramente te lo diré.

Solo mejoramos cuando comprendemos nuestros errores. Así es como producimos un mejor código en el futuro.

Estás obteniendo excelentes respuestas aquí.

Solo pude agregar una técnica que aprendí de un gerente una vez cuando cometía un error.

Yo era el consultor de mediana edad con el Ph.D. y ella era la joven gerente sin, por lo que podría haber un gradiente de prestigio percibido. En cualquier caso, ella claramente tenía experiencia con esta situación y sabía cómo manejarla.

Ella me mencionó en tono casi de disculpa que parecía haber un problema, ¿y tendría tiempo para investigarlo?

Con suficiente frecuencia, el error fue mío, y ella lo sabía. Eso es habilidad.

Creo que hay un problema más profundo que subyace a esta pregunta. Sí, el remitente debe estar al tanto de las consecuencias de su cambio, para que puedan entender lo que sucedió y no volver a hacer lo mismo. Sin embargo, el contexto de su pregunta indica que usted preparó y envió una solución sin que el remitente original supiera que incluso causaron un problema. Ahí radica el problema más profundo: ¿por qué el remitente ya no conoce la regresión y por qué no lo arreglaron ellos mismos? La situación que describió puede indicar una falta de Responsabilidad o vigilancia por parte del remitente original, que es una preocupación potencial con respecto a su rendimiento general y motivación.

Mi experiencia en ingeniería de software me ha enseñado a ser responsable de todos los cambios en mi código, no solo de los proyectos de los que soy responsable, hasta el final de la producción, lo que incluye ser consciente de su impacto, incluso en su sistema de compilación y (obviamente) comportamiento del producto.

Si el cambio de alguien ha causado un problema, no significa que la persona sea un mal ingeniero, pero generalmente debe ser responsable e involucrado en la solución de todo lo que haya salido mal. Incluso si no están "en falta", por ejemplo. su código expuso un error subyacente que ha existido en la base de código durante años, deben ser una de las primeras personas en ser conscientes de un problema con su cambio. Incluso si el remitente original no es la persona adecuada para corregir el error, deben estar estrechamente conectados con el ciclo de vida de su cambio.

Buena tracción en tu pregunta! Todos te han dicho lo que haces. ¿Debes decir? ¡SÍ! Cada vez que la pregunta dice "¿Debo comunicarme más?", La respuesta es casi siempre SÍ!

Pero para agregar algo diferente: su premisa es defectuosa.

  

Un compañero de trabajo hizo un compromiso que no rompió el IC, pero que lo llevó a   descubre un problema.

Felicitaciones! Encontraste un nuevo error, no una regresión. En serio, ¿prueba manualmente todos los escenarios y líneas de código que no están cubiertos por las pruebas automatizadas (o manuales estandarizados) cuando se compromete?

De todos modos, haga que su colega participe en la revisión, con pruebas para asegurarse de que no vuelva a suceder. ¡Ambos son héroes! Pero si deja escapar cualquier culpa en palabra o acción, usted es responsable de perpetuar una de las peores enfermedades organizativas: la responsabilidad sin responsabilidad.

Si realmente necesita encontrar a un villano, piense en la persona que cometió el código original que se rompió y dejó una trampa para su amigo desprevenido (obviamente sin suficiente cobertura de prueba). ¡Ojalá no fueras tú!

Siempre considere a la otra persona como alguien mejor que usted, siempre vea las buenas características de los demás y siempre sepa que yo también puedo cometer errores.

Dígales cuando solo están ustedes dos.

Si alguien se ofende cuando usted le dice que cometió un error, significa que piensa que es el más sabio de la tierra y no se equivoca, y cuando se le critica, tiene la sensación, como dijimos en Polonia, de que "corona". está cayendo de su cabeza '.

Así que no debes dudar en decir que alguien ha cometido un error. Es normal. Todos cometemos errores, incluso los mejores! Solo aquellos que no hacen nada no cometen errores;)

Además de lo que otros han dicho, asegúrese de que sea REALMENTE su compromiso lo que causó un error. Ciertamente, no culpes a nadie más por tu propio error. No importa cuán discretamente te acerques a ellos, todavía los vas a enojar si los culpas por algo que no hicieron. (Hablando como alguien que ha sido culpado por los errores de otras personas constantemente; una vez alguien se me acercó y me dijo que había hecho algo completamente estúpido, saqué el registro de confirmación y encontré que la última persona en tocar esa línea de código fue la Persona que me estaba culpando. De alguna manera, todavía parecía pensar que era mi culpa porque originalmente había escrito la línea.

¿Por qué no veo una sola respuesta aquí que refleje el comentario más votado sobre la pregunta?

Sí, dísoslo absolutamente, pero no lo hagas frente a todo el equipo

Acérquese al desarrollador 1: 1 y señale el error. No lo hagas mucho. Siempre pensé que señalar el error frente a todo el equipo era una mala idea. Puede funcionar para algunos desarrolladores, pero no es para todos y puede tener un efecto negativo. Recuerde, todos hemos estado en su lugar en algún momento u otro, y como dice la segunda mejor respuesta votada, usted aprende de sus errores

Por lo general, encuentro que funciona mejor cuando empiezas con un cumplido y luego llegas al error ... algo así como "la solución que implementaste funciona muy bien, PERO parece haber roto x, y, z" o "gracias para hacer a, b, c, PERO parece estar causando x, y, z "

Respuesta simple: sí.

Respuesta más larga: mi último trabajo fue en una compañía Agile que usaba TDD con herramientas de CI para garantizar que lo que había en nuestro repositorio de SVN era bueno, el código de trabajo en todo momento. Cuando se confirmó algo, nuestro servidor TeamCity obtuvo una copia, compiló y realizó pruebas de unidad. También se realizaron pruebas de integración cada hora. Si se cometió algo que causó que el IC fallara, todos recibieron un correo electrónico indicando que la compilación se había roto en base a un compromiso por parte de una persona en particular.

Eso no siempre atrapó todo; ay de nosotros, no aplicamos la cobertura del código, e incluso si algo estuviera cubierto por las pruebas de unidad o de integración, no podrían ejercer ese código lo suficiente. Cuando eso sucediera, quienquiera que tuviera la tarea de solucionar el problema conocido (si QA lo detectaba) o un defecto (si dun-dun-dun, los clientes lo hacían), tendría una "culpa" (muestra quién modificó por última vez cada línea de un archivo de código) y determinar el culpable.

Llamar a alguien para verificar el código dañado no es necesariamente algo malo. No han podido hacer su trabajo correctamente, y tanto ellos como alguien más tuvieron que regresar y corregir el error. Esto sucede todo el tiempo; la importancia de la transacción depende de qué tan fácil sea la solución, si el error indica que la persona ni siquiera compiló o ejecutó el código en cuestión, y la cultura corporativa general. Lo importante en todo esto es que la persona que cometió el error aprendió algo; si la construcción se rompe debido al mismo tipo una y otra vez, hay un problema más profundo con esa persona que debe abordarse. Las construcciones que se rompen todo el tiempo indican un problema con la comunicación del equipo o el conocimiento del proceso.

Sí. Pídale a la persona que revise la corrección que hizo al código. A veces me he dado cuenta de que el error de otra persona era en realidad una parte difícil del código con algunas otras consecuencias invisibles si el error simplemente se solucionaba.

Hay muchos factores en juego.

• ¿Qué tan grave es el error?
• ¿Cuál es la relación de antigüedad entre usted y el que rompe?
• ¿Qué tan ocupado / estresado está el equipo?
• ¿Estaba el interruptor trabajando en su parte del código base o en el suyo?
• ¿Qué tan seguro está de que fue un error real y qué tan seguro está de que su corrección es correcta?

Si el problema era menor: un error tipográfico / thinko / cut & pegue un error, y el que rompe está muy ocupado, y confía en su evaluación del problema, es probable que no necesite llamar su atención. (por ejemplo, foo.x = bar.x; foo.y = bar.y, foo.z = bar.y ).

En la mayoría de los otros casos, es una buena idea mencionar el problema. En casos no serios, no es necesario interrumpir lo que están haciendo; espera y hazlo durante el almuerzo o cuando te encuentres en la sala de descanso.

Si la naturaleza del error indica un malentendido grave (de la plataforma de implementación, las políticas locales o la especificación del proyecto), cámbielo lo antes posible.

Si no está seguro de su evaluación, pídales que revisen su corrección, especialmente si no está en el código con el que está muy familiarizado. (Recomiendo encarecidamente a su equipo de desarrolladores que adopte una política de "amigo del código" en la que todos los cambios sean revisados por otra persona antes de registrarse, de todos modos).

¿Qué pasa si no les dices?

Los contras

Pueden cometer el mismo error en otros lugares porque no entienden que está causando un problema. No solo eso, sino que habrá tiempo adicional innecesario para corregir repetidamente el mismo error. No puede aprender de los errores que desconoce que nade.

Segundo, creen que están haciendo un mejor trabajo que ellos. Cuando las personas no son conscientes de sus problemas, difícilmente se les puede culpar por pensar que les va bien cuando no lo están. Incluso cuando el problema es un error por descuido, las personas cometen menos cuando están conscientes de que se notan los errores.

A continuación, si alguien no mira quién lo hizo, ¿cómo sabrá si tiene un empleado problemático en particular que siempre es descuidado o tiene malentendidos básicos sobre el producto? ¿Querría una persona responsable que continúe en un equipo en el que está asociada?

Si lo arreglas y sigues sin discutirlo, ¿estás seguro de que lo arreglaste correctamente? A veces son las pruebas las que tienen que cambiar cuando cambia un requisito. Si es algo más que un error tipográfico bastante menor, ¿puede realmente estar seguro de que alguno de los dos tiene la solución correcta? Podrías estar rompiendo su código a cambio sin consultar.

Los pros

La gente no se avergüenza ni se molesta contigo por señalar sus errores.

Supongo que me inclino fuertemente por decirles, pero haciéndolo bien y en privado. No hay necesidad de humillación pública. Si la persona comete repetidamente los mismos errores o está cometiendo errores críticos que muestran una falta de comprensión, entonces también se debe informar al supervisor.