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

Cuando rastrea y repara una regresión, es decir, un error que causó que el código que funcionaba anteriormente dejara de funcionar, el control de versiones hace posible ver quién cometió el cambio que lo rompió.

¿Vale la pena hacer esto? ¿Es constructivo señalar esto a la persona que hizo el compromiso? ¿La naturaleza del error (en la escala de la simple falta de atención a la incomprensión fundamental del código que cambiaron) cambia si es una buena idea o no?

Si es una buena idea decirles, ¿cuáles son buenas maneras de hacerlo sin ofender o hacer que se pongan a la defensiva?

Supongamos, en aras de la discusión, que el error es lo suficientemente sutil como para que las pruebas automatizadas del servidor CI no puedan detectarlo.

Si solo te acercas a ellos para contarles un error que cometieron, a menos que seas el mejor diplomático del mundo, será difícil que no suene como "¡Ja! ¡Mira este error que cometiste!". Todos somos humanos y las críticas son difíciles de aceptar.

Por otro lado, a menos que el cambio sea completamente trivial y obviamente erróneo, normalmente me resulta benéfico hablar con la persona que cometió el cambio original como parte de mi investigación solo para asegurarme de que entiendo completamente lo que está sucediendo, de ahí la forma en que generalmente terminar manejando esta situación es ir a dicha persona y tener una conversación que se parezca un poco a esto:

Yo: estoy trabajando en este error donde ... resumen del error ... y creo que he rastreado el problema hasta un cambio que hiciste. ¿Puedes recordar para qué fue este cambio? / ¿tienes tiempo para explicar este cambio?

Entonces tambien:

Ellos: Claro, eso es para manejar ... situación de la que no estaba al tanto ...

O algo así como:

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

Al investigar e investigar juntos el cambio / error, el confirmador original puede aprender de sus errores sin sentir que están siendo criticados *, y también hay una buena posibilidad de que también aprendas algo.

Si el confirmador original no está cerca o está ocupado, entonces siempre puede pasar el tiempo y resolverlo usted mismo, normalmente encuentro que hablar con la persona que originalmente realizó el cambio es más rápido.

* Por supuesto, esto solo funcionará si está realmente interesado en la ayuda de otras personas. Si solo está usando esto como un método disfrazado de decirle a alguien sobre un error que cometió, entonces esto probablemente sea peor que simplemente ser abierto al respecto.

Sé asertivo, no agresivo. Siempre favorezca decir algo parecido a "este código no funciona" frente a "su código no funciona". Critique el código, no a la persona que lo escribió.

Mejor aún, si puede pensar en una solución, corríjala y apúntela, suponiendo que tenga un sistema de control de versiones distribuido. Luego pregúnteles si su corrección es válida para el error que estaban reparando. En general, intente aumentar tanto su conocimiento como el de programación. Pero hazlo sin que tu ego se interponga en el camino.

Por supuesto, debe estar dispuesto a escuchar a otros desarrolladores que se acercan a usted con el mismo problema y actuar como hubiera deseado.

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

Hacerles saber los errores que cometen los ayudará a convertirse en mejores programadores y reducirá sus posibilidades de cometer errores en el futuro. PERO sea ​​cortés y no haga gran cosa, todos creamos errores de vez en cuando. Me parece que un correo electrónico educado es una forma muy discreta de informar a la gente.

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

Si implica explicar a las personas cómo no introducir errores, anímate.

Una vez, trabajé en un equipo donde el gerente de 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 para suprimir Ese tipo de errores. De esa manera, nadie fue estigmatizado.

En general si .

Nadie debería ponerse a la defensiva si tienes tacto al respecto. Una manera fácil de manejarlo es pedirles que verifiquen dos veces su cambio antes de volver a enviarlo a la troncal (o lo que sea relevante para su sistema de control de versiones). La gente lo apreciará si los ahorra unos minutos arreglando errores obvios, pero no lo apreciarán si arregla algo que no se rompió y termina rompiendo su código. Darles la oportunidad de revisar su cambio les dice que no desea pisarles los pies y les da la oportunidad de objetar sus cambios.

Si se trata de un gran cambio en lugar de solo un error tipográfico, es una buena idea avisar al autor antes de comenzar a tratar de solucionarlo. "Joe, ayer estaba fusionando mis propias cosas y encontré algo que no estoy seguro de entender. Parece un error, pero quería corregírselo antes de jugar con su código. ¿Podría echarle un vistazo? ¿yo?"

Tu relación con el autor es un gran factor. Si no le importaría que el autor arregle su código sin decírselo, y si está bastante seguro de que el sentimiento es mutuo, entonces quizás no valga la pena mencionarlo. Si se trata de alguien con más experiencia / antigüedad / estado, querrá informarles que va a cambiar su código. Si se trata de alguien con menos, 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 registró el "error", ellos también pueden averiguar quién "reparó" su código. Si crees que estarían molestos / molestos / avergonzados al enterarse de tu cambio después del hecho, díselo de antemano.

Además, arreglar el error no es tu única opción. Siempre puede informar el error en su 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 la mejor manera de solucionar el problema o si simplemente no tiene tiempo para solucionarlo.

Si hago una confirmación que incluye un error, será mejor que me lo digas. Si encuentro una confirmación tuya que incluye 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 cometería un error.

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

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

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

Creo que hay un problema más profundo subyacente a esta pregunta. Sí, el remitente debe ser consciente de las consecuencias de su cambio, para que pueda entender lo que sucedió y no volver a hacer lo mismo. Sin embargo, el contexto de su pregunta indica que se preparó y presentó una solución sin el conocimiento del solicitante original que incluso causaron un problema. Ahí radica el problema más profundo: ¿por qué el remitente ya no sabe acerca de la regresión y por qué no la arreglaron ellos mismos? La situación que describió puede indicar una falta de responsabilidad o vigilancia por parte del remitente original, lo cual 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 dueño de todos mis cambios de código, no solo de los proyectos de los que soy responsable, hasta la producción, lo que incluye ser consciente de su impacto, incluido en su sistema de compilación y (obviamente) el 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 reparación de lo que haya salido mal. Incluso si no son "culpables", por ejemplo, su código expuso un error subyacente que ha existido en la base de código durante años, deberían 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, debe estar estrechamente relacionado con el ciclo de vida de su cambio.

Buena tracción en tu pregunta! Todos te han dicho qué hacer. ¿Deberías decirlo? ¡SI! Cada vez que la pregunta es "¿debería 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ó CI, pero lo llevó a descubrir un problema.

Felicidades! Encontraste un nuevo error, no una regresión. En serio, ¿prueba manualmente cada escenario y línea de código que no está cubierto por las pruebas automatizadas (o manuales estandarizadas) cuando se compromete?

Por supuesto, involucre a su colega en la solución, con pruebas para asegurarse de que no pueda volver a ocurrir. ¡Ustedes dos son héroes! Pero si deja pasar cualquier culpa en palabra o acción, usted es responsable de perpetuar una de las peores enfermedades organizacionales: responsabilidad sin responsabilidad.

Si realmente necesita encontrar un villano, piense en el tipo 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 otras características buenas y siempre sepa que yo también puedo cometer errores.

Diles cuándo son solo ustedes dos.

Si alguien se ofende cuando le dijiste que cometió un error, significa que cree que es el más sabio del mundo y no se equivoca, y cuando se le critica, siente que, como dijimos en Polonia, esa 'corona se está cayendo su cabeza'.

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

Además de lo que otros han dicho, asegúrese de que REALMENTE sea su confirmación lo que causó un error. Ciertamente no culpes a alguien más por tu propio error. No importa cuán tácticamente los abordes, igual los molestarás si los culpas de algo que no hicieron. (Hablando como alguien a quien se ha culpado constantemente por los errores de otras personas; una vez alguien se acercó a mí y me dijo que hice algo completamente estúpido y saqué el registro de confirmación y descubrí que la última persona que tocó esa línea de código fue el persona que me estaba culpando. De alguna manera todavía parecía pensar que era mi culpa porque había escrito la línea originalmente.)

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

Sí, cuéntales absolutamente sobre eso, pero no lo hagas frente a todo el equipo

Acércate al desarrollador 1: 1 y señala el error. No hagas gran cosa al respecto. 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 respuesta más votada, usted aprende de sus errores

Por lo general, encuentro que funciona mejor cuando comienzas 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 por hacer un , b, c, PERO parece estar causando x, y, z "

Respuesta simple: sí.

Respuesta más larga: mi último trabajo fue en una empresa Agile que usaba TDD con herramientas de CI para garantizar que lo que estaba en nuestro repositorio SVN fuera bueno, el código de trabajo en todo momento. Cuando se cometió algo, nuestro servidor TeamCity obtuvo una copia, compiló y ejecutó pruebas unitarias. También ejecutó pruebas de integración cada hora. Si se cometió algo que hizo que fallara el CI, todos recibieron un correo electrónico indicando que la compilación se había roto en función de un compromiso realizado por una persona en particular.

Eso no siempre atrapaba todo; Ay de nosotros, no aplicamos la cobertura del código, e incluso si algo estaba cubierto por pruebas unitarias o de integración, es posible que no ejerzan ese código lo suficiente. Cuando eso sucediera, quien tuviera la tarea de solucionar el problema conocido (si QA lo descubrió) o el defecto (si, dun-dun-dun, los clientes lo hicieron), correrí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 roto no es necesariamente algo malo. No han podido hacer su trabajo correctamente, y ellos o alguien más tuvieron que regresar y arreglar el error. Esto sucede todo el tiempo; lo importante que debería ser depende de lo fácil que fue 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 el asunto es que la persona que cometió el error aprende 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.

Si. Pídale a la persona que revise la corrección que realizó al código. A veces he descubierto que el error de otra persona era en realidad una parte difícil del código con 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 interruptor?
• ¿Qué tan ocupado / estresado está el equipo?
• ¿Estaba funcionando el interruptor en su parte de la base de código o en la tuya?
• ¿Qué tan seguro está de que fue un error real y qué tan seguro está de que su solución es correcta?

Si el problema fue menor (un error tipográfico / thinko / cut & paste) y el interruptor es un par ocupado, y usted confía en su evaluación del problema, probablemente 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 graves, no necesita interrumpir lo que están haciendo; espere y hágalo durante el almuerzo o cuando se encuentre con ellos en la sala de descanso.

Sin embargo, si la naturaleza del error indica un malentendido grave (de la plataforma de implementación, las políticas locales o las especificaciones del proyecto), mencione 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 que su equipo de desarrollo adopte una política de 'código amigo' donde todos los cambios sean revisados ​​por otra persona antes de registrarse, de todos modos).

¿Qué pasa si no les cuentas?

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 puedes aprender de los errores que desconoces.

Segundo, piensan 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 lo están haciendo bien cuando no lo están. Incluso cuando el problema es un error descuidado, las personas hacen menos de ellos cuando son conscientes de que los errores se notan.

Luego, si alguien no mira quién lo hizo, ¿cómo sabrá si tiene un problema en particular empleado que siempre es descuidado o tiene malentendidos básicos del producto? ¿Una persona responsable quiere que continúe en un equipo en el que está asociado?

Si arreglas y sigues sin discutirlo, ¿estás seguro de que lo arreglaste correctamente? A veces son las pruebas las que deben cambiar cuando cambia un requisito. Si se trata de algo más que un error tipográfico menor, ¿puede estar seguro de que alguno de ustedes tiene la solución correcta? Puede estar rompiendo su código a cambio sin consultarlo.

Los profesionales

La gente no se avergüenza o molesta con usted por señalar sus errores.

Supongo que vengo fuertemente al lado de decírselo pero haciéndolo bien y en privado. No hay necesidad de humillación pública. Si la persona comete repetidamente los mismos errores o comete errores críticos que muestran una falta de comprensión, entonces el supervisor también debe ser informado.