Un programador realizó algunos trabajos en el repositorio de SVN y luego se fue a casa. Después de que se fue, la compilación automática de Hudson falló. Otro programador vio esto y, después de revisar los cambios de código, detectó que el problema era la ausencia de una biblioteca. Añadió esta biblioteca a SVN y la siguiente compilación se completó con éxito.
¿El segundo programador hizo lo correcto o debería haber esperado hasta que el primer programador solucionó el problema?
Depende en cierta medida de cómo funcione normalmente tu equipo, pero diría que estuvo bien. Mantener la compilación en funcionamiento ahorra tiempo a todos los demás.
Es educado para el segundo programador dejar caer el primer correo electrónico para explicar lo que ha hecho, en caso de que se necesite una versión específica de la biblioteca o haya alguna otra complicación. También es una forma un poco más sutil de señalar que habían roto la compilación.
Depende.
¿El error es tan obvio que agregar una biblioteca es la forma de solucionarlo? A veces, la solución es encontrar una solución alternativa para no necesitar esa biblioteca.
¿Está el proyecto en una fase en la que todos los cambios deben estar vinculados a un ticket existente? Si es así, ¿archivó un boleto? ¿Te ha sido asignado ese boleto?
De todos modos, concéntrate en corregir el error, no en culpar a los responsables.
Sí, está bien. Sin embargo, no es profesional que el programador original se vaya a casa antes de probar si la compilación se compilaría.
Tu reputación está 100% bajo tu control. Cosas como esta empañan tu reputación y tratar de pulir una reputación empañada es muy difícil.
Comunicar
No hay reglas estrictas (aparte de las reglas de tu propio equipo) para esos escenarios.
Dev2 debería poder decirle a dev1 que puede corregir su error, ninguno de los dos debe temer algo que resulte de este intercambio, son parte de un equipo.
¿Por qué no? Si su producto es más importante que reparar culpas, ciertamente está bien. Aunque una compilación que falla debido a un cambio en la biblioteca es bastante escasa y necesitas reprender al desarrollador por no probarlo.
Los fallos de compilación ocurren. Si es importante que se realice una compilación diaria, la arreglaré y luego le pediré al desarrollador que revisó el código dañado que revise la revisión al día siguiente y se asegure de que el código sea el correcto.
Como se ha dicho, el tipo que lo arregló probablemente debería enviar un correo electrónico al tipo que lo rompió y detallar cuál fue la solución.
Mi lema, es que no se comprometa con SVN después de las 3pm, de esa manera siempre podrá corregir sus propios fallos de compilación.
Si no arreglas la falla de su compilación, la compilación de todos los demás también fallará. Lo arreglaría para ahorrar tiempo a largo plazo, pero asegúrate de que sean conscientes de que tenías que arreglarlo.
¡Tener una especie de guión de "señalar con el dedo de la culpa" es una buena manera de hacer esto, o hacer que la persona que rompe las donas compre!
Alguien necesita arreglarlo y el primer programador no debería haberse ido a casa sin asegurarse primero de que no había roto la compilación. Sin embargo, para un problema tan fácil de solucionar, devolverlo para solucionarlo por sí mismo sería extremo.
Estoy de acuerdo con la sugerencia de Luke Graham de enviar un correo electrónico explicativo, aunque diría que es más que cortés, es una comunicación básica.
Sí, sí, sí! Fomenta la propiedad de código colectivo y establece una especie de presión de grupo saludable en el equipo para mantener un alto nivel y no permitir que se desarrolle un escenario de ventana rota. Un poco de comunicación para que el otro desarrollador sepa es una buena idea.
Creo que está bien arreglar las cosas obvias, es decir, si está 100% seguro de que la persona cuyo código está corrigiendo haría la misma corrección, o sustancialmente la misma. Si la solución es más compleja, por lo general es educado hablar con la persona cuyo código está corrigiendo; es posible que usted haya entendido mal la intención o que la razón por la que se rompió no es lo que pensó que era, o tal vez intentó otra solución. pero por alguna razón no podría cometerlo todavía (la vida pasa, ya sabes :).
En general, la regla generalmente es: usted rompe la compilación, corrige la compilación, pero hay excepciones, especialmente si la solución es obvia y / o la persona responsable es inaccesible.
Por supuesto, si tiene el caso del interruptor de compilación en serie, especialmente con el patrón "registrado, se fue a casa, se rompió durante varios días", la persona responsable necesita hablar sobre por qué existen los sistemas y las pruebas de CI. cómo se debe verificar antes de registrarse :)
Las cosas pasan. La falla en agregar un nuevo archivo de código (ya sea fuente o compilado) a Subversion es probablemente la causa más común de compilaciones dañadas, asumiendo que funcionó en la computadora del desarrollador. En mi último trabajo con un entorno de CI, a veces incluso los tipos más veteranos lo olvidaban.
Creo que, si otra persona pudo arreglar la compilación y así mantener al equipo trabajando, eso está bien. Creo que el programador que fue a su casa necesita al menos un correo electrónico amigable que indique lo que sucedió, y recordarle que se asegure de que se agregue un nuevo código antes de cometer. Si esto sucede con frecuencia, tal vez sea una ofensa menor punible por el "baile de la vergüenza", para ayudar a reducir las ocurrencias (y aligerar el estado de ánimo).
Depende de la dinámica del equipo, pero en un mundo ideal, todos en el equipo "poseerían" todo el proyecto, todo el código y, en consecuencia, todos los errores de forma conjunta. Entonces, si encuentra un problema, lo soluciona y se comunica con el creador del error solo si hay algún valor agregado específico al código al hacerlo.
Está bien arreglarlo, a menos que esto ocurra con frecuencia, en cuyo caso el jefe lo llamaría y lo haría regresar y repararlo él mismo.
Depende, depende ...
Como programadores, nuestro trabajo es hacer que las cosas funcionen, no juzgar a las personas. Así que diría que lo mejor que puedes hacer es solucionarlo, o si no es obvio, simplemente restaura los cambios y avisa al primer programador para que pueda corregirlo más tarde.
De todos modos, tener al último chico que rompió la construcción para usar un sombrero extraño es suficiente para prestar más atención la próxima vez que ^ _ ^
En algunos entornos, esto es muy grosero y por buenas razones. En otros entornos, se espera, y por buenas razones.
En otros entornos, es muy grosero o se espera por muy malas razones.
Depende en gran medida de cuán crítica sea una compilación dañada en comparación con qué tan crítica sea una compilación correcta verificada. Y hasta cierto punto, depende de qué tan obvio fue que la solución fue la solución correcta y la única necesaria.
Primero, 'se fue a casa' es un anacronismo. Los programadores ya no se van a casa, simplemente están en línea o fuera de línea. Podrías hacer ping y esperar.
Más en serio, en realidad hay dos partes de la pregunta. 'mirar a través de los cambios de código' está bien; El descanso puede no ser lo correcto. ¿Qué pasaría si su juicio de una biblioteca perdida estuviera equivocado?
Lea otras preguntas en las etiquetas teamwork continuous-integration