¿Cómo manejar cuando otro desarrollador arruinó un proyecto?

Definitivamente deberías hablar con él al respecto. Tal vez no comprometió completamente todos sus códigos/cambios, o tal vez lo hizo por accidente.

Si cometió todo y fue plenamente consciente de ello, debe preguntarle sobre los errores y tal vez incluso ofrecerle ayuda para solucionarlos si no sabe cómo hacerlo él mismo.

Siempre puede dirigirse directamente a su gerente si resulta que no le importa la calidad de su código o si siente que su incompetencia le impide hacer su trabajo.

Hablar con calma con él al respecto debería ser el primer paso, después de todo, son colegas.

Debo pensar que el control de versiones le basta al gerente u otro ve quien jodio el proyecto?

Quizás, pero esa no debería ser tu principal preocupación. No quieres jugar el juego de la culpa; eso no mejorará las relaciones laborales y ciertamente no ayudará a solucionar el problema.

¿O debería hablar con él y preguntarle sobre los cambios que hizo?

Hablale. No lo culpes. Señale por qué está roto y luego pregunte "¿cómo podemos arreglar esto?" Enfatiza que lo único que te importa es llevar el proyecto a buen término.

Soy nuevo en esta empresa, y él también. Pero parece ser menos hábil que yo.

¿Así que lo que? No es una competencia. Habrá otros más hábiles que tú.

Hablale. No acuda al gerente cada vez que algo no funcione.

¿Estás seguro de que tu entorno está configurado correctamente? ¿Hay alguna posibilidad de que te estés perdiendo algo? Verifique dos veces antes de acercarse a su colega. Cuando se acerque a él, le sugiero que enmarque la pregunta como una solicitud de ayuda para construir el proyecto.

Algo como "Desactivé el repositorio pero no se compila. No estoy seguro si configuré algo mal, ¿podría ayudarme?"

Esto le dará la oportunidad de ver que su cambio rompió el código. ¡Ambos son nuevos, por lo que es válido pedir su ayuda para configurarlo de todos modos! Déle la oportunidad de arreglarlo él mismo primero, antes de escalar algo que sucede en todos los entornos de desarrollo de software.

Si tiene control de versiones, que espero que tenga, debería poder ver qué cambios hizo. Le sugiero que hable con su supervisor sobre la creación de algún tipo de sistema de revisión de código en el futuro.

¿Cómo puedo manejar esto?

Implemente un flujo de trabajo de solicitud de extracción (o como lo llame) que permitirá que otro desarrollador revise los cambios antes de que se agreguen

Los desarrolladores, incluso los experimentados, rompen la construcción. Parece que no eres el líder técnico. Da un paso al frente y muéstrale al líder técnico que te encargarás de implementar el (muy necesario) proceso.

Ve a hablar con él 1 a 1 sobre los cambios. Vea si se trata de un problema de configuración de su parte. Si es así, problema resuelto.

Si no, mira cómo puedes usar un flujo de trabajo para evitar que esto vuelva a suceder.

Después de revisar cómo activar las revisiones y las compilaciones automáticas en su sistema actual, comuníquese con el líder técnico. Di algo como

Me di cuenta de que a veces las personas revisan los cambios que rompen el sistema, y ​​si activamos las revisiones de relaciones públicas, eso debería disminuir significativamente. También podemos construir el sistema cada vez que alguien se registra, lo que también debería reducir eso.

Con suerte, el líder técnico estará encantado de que alguien quiera dar un paso al frente y hacer esto. Si odian con vehemencia la idea, corre por tu vida.

Paso 1: habla con él. Mencione que la compilación está rota y que la última confirmación fue su confirmación, así que pregúntele qué sucedió (es importante no decir "¡rompió la compilación!" porque a) eso es acusatorio yb) tal vez su cambio no fue en realidad el cambio que rompió la compilación, por ejemplo, tal vez fue un cambio de configuración, o tal vez se olvidó de un cambio que usted mismo hizo, etc., en cuyo caso parece muy abrasivo y acusatorio).

Paso 2: Si él es receptivo a su declaración, trabaje con él para arreglarlo y si no entiende qué salió mal, explíqueselo. Explicárselo le enseñará cómo no volver a cometer el mismo error. Eso se llama tutoría y es muy importante entre colegas, particularmente entre los más experimentados (hacia los menos experimentados). Sus superiores lo mirarán muy bien si puede participar productivamente en la tutoría.

Paso 2a: en el caso extremadamente improbable de que no sea receptivo a su declaración, entonces es hora de luchar: verifique dos veces su trabajo para asegurarse de que rompió la construcción, luego vaya a su gerente y muéstrele que la construcción está rota. y que el colega lo hizo. Entonces es problema del gerente, no tuyo, y ahí termina tu responsabilidad.

Paso 3: La próxima vez que este colega en particular rompa la construcción, enjuague y repita. Si sucede varias veces y cree que es un patrón de irresponsabilidad, entonces puede dirigirse a su gerente y decirle: "Oye, Bob, sabes que Joe ha roto la construcción varias veces y he tratado de hablar con él sobre pero parece que a él no le importa, ¿te importaría hablar con él al respecto? o algo así. No entre agresivo o acusador; haga que el problema sea romper la compilación, no sobre el colega. Su gerente decidirá cuál es el mejor curso de acción a partir de ahí.

Esto es exactamente para lo que están los servidores de compilación. Verifican la fuente después de cada confirmación y ven si se compila y envían un correo electrónico a quien rompió la compilación para que puedan solucionar el problema.

Algunos servidores de compilación pueden incluso servir los artefactos creados si es necesario.

Si no tienes uno, consigue uno. Un buen lugar para comenzar es Jenkins, que es muy fácil de usar.

En este caso particular, el problema probablemente se habría solucionado antes de que se fuera a casa sin necesidad de hablar o señalar con el dedo.