¿Cómo protejo el tronco de los novatos desventurados?

Un compañero de trabajo transmitió el siguiente problema, digamos que es ficticio proteger a los culpables:

Un equipo de 5-10 trabaja en un proyecto impulsado por problemas. Es decir, el flujo típico es el siguiente:

  1. un pedazo de trabajo (error, mejora, etc.) se crea como un problema en el rastreador de problemas
  2. El problema se le asigna a un desarrollador
  3. El desarrollador resuelve el problema y confirma sus cambios de código en el enlace
  4. En el momento del lanzamiento, la twig del tronco o de la versión congelada y fuertemente probada, o lo que sea, está construido en modo de lanzamiento y lanzado

El problema que está teniendo es que un par de novatos cometieron varios errores que no fueron detectados debido a una desafortunada cadena de events. Esto fue seguido por un mal lanzamiento con un retroceso o una ráfaga de arreglos rápidos.

Una idea con la que estamos jugando:

Revoque el acceso de commit para los novatos al trunk para que se desarrolle en una twig por desarrollador (estamos usando SVN):

  • Bueno: los novatos están aislados y no pueden dañar a los demás
  • Bueno: los committers fusionan twigs de novatos con el tronco con frecuencia
  • Bueno: esto impone revisiones de códigos rígidos
  • Malo: esto es una carga para los committers (¡pero probablemente no haya forma de evitarlo ya que el código debe ser revisado!)
  • Malo: podría hacer que la trazabilidad de los cambios en el tronco sea un poco más difícil ya que el revisor estaría haciendo el compromiso, no muy seguro de esto.

Actualización: Gracias a todos por su valiosa contribución.

He llegado a la conclusión de que esto es mucho less un problema de código / codificador que el primero que presenté. La raíz del problema es que el procedimiento de publicación no logró capturar y probar algunos cambios de baja calidad en el troncal. Tapar ese agujero es lo más importante. Confiar en la falsa suposition de que el código en el enlace es "bueno" no es la solución.

Una vez que se tapone la testing de hoyos, los errores de todo el mundo (novatos o personas mayores) se detectarán correctamente y se tratarán en consecuencia.

A continuación, un mayor énfasis en las revisiones de los códigos y la tutoría (probablemente impulsada por algunos cambios sistemáticos para fomentarlo) contribuirá en gran medida a mejorar la calidad del código.

Con esas dos correcciones en su lugar, no creo que algo tan rígido o draconiano como lo que propuse anteriormente sea necesario. ¡Gracias!

Estás diciendo explícitamente que no se puede confiar en las personas nuevas, lo que no ayudará a su moral, de hecho la destruirá.

Porque en última instancia, intenta crear un set de desarrolladores "de confianza" y un set de desarrolladores "no confiables".

Voy a dar un paso en falso y decir que definitivamente hay codificadores "nuevos" (nuevos para su empresa) que tendrían less probabilidades de cometer errores que algunos de sus desarrolladores "experimentados".

El fallo en su sistema original fue un error de PRUEBA no es un problema que pueda resolverse segregando desarrolladores.

Necesita un sistema de QA y UAT más sólido para asegurarse de que esos errores, independientemente de quién los haga, se capturen antes del time de deployment. De esta forma, no tienes que culpar a los "novatos desventurados".

Parece que su process actual ya es bastante bueno. El problema no es que el código incorrecto haya ingresado en el enlace troncal, sino que el código incorrecto no se detectó durante la testing o revisión. Tal vez las sesiones semanales de revisión de código serían útiles? Empareje a un principiante con alguien con más experiencia y simplemente revise el código porque en algún momento habrá demasiados cambios para que solo una persona específica o un grupo de personas haga todos los commits / fusionar a trunk.

Por twig de desarrollador también funciona, pero sugeriría dejar que el desarrollador combine los cambios (de nuevo quizás con otro desarrollador).

Um … Esto puede ser obvio, pero ¿qué hay de la fijación de la desafortunada cadena de events que llevaron a los compromisos malos no ser atrapados?

Tu process parece razonable; pero si va a realizar la continuous integration, debe verificar que el troncal integrado no esté roto. Parece que ese process fue derrotado de alguna manera; me parece que necesita encontrar y solucionar el problema que derrotó ese process.

Integración continua y testings unitarias automatizadas, quizás como un requisito del process de verificación. Configure la continuous integration en el código registrado. Configura notifications o indicadores públicos del estado de compilation (luces rojas / verdes). Haga que las testings de su unidad (y las testings de integración, etc., si es posible) se ejecuten durante el process de compilation. Las personas que rompen la compilation no pueden trabajar en ninguna característica nueva hasta que se corrija la compilation. Si unimos esto con una vergüenza pública de buen carácter. 🙂

Además, sostenga a los novatos a través del process las primeras veces para que no tengan miedo de cometer nada.

Mi primer consejo sería contratar mejores novatos, seguido de contratar un mejor departamento de control de calidad. El enfoque que sugiere podría funcionar, pero trata el síntoma y no el problema. Las revisiones de código y las testings unitarias ayudarían mucho.

ejem, usa mercurial? entonces tus novatos pueden dañar su propio file tanto como quieran …

Hay varias otras cosas que podrías hacer:

  • Gestión de proyectos : comunica el problema al equipo, haciendo hincapié en la responsabilidad que conlleva el compromiso con el tronco

  • Estructura del equipo : asigne un mentor a los novatos, que hará una revisión del código antes de la confirmación. Esa es también una buena oportunidad para que los novatos conozcan el proyecto, los estándares de encoding vigentes y se familiaricen con la cultura del equipo.

  • Pruebas Unitarias : Requerir que todos también escriban una testing unitaria para su código.

  • Comstackciones y comstackciones regulares : establezca un server de compilation y comstackciones nocturnas (incluida la testing unitaria) para detectar problemas con anticipación.

  • Revisión de código Establezca un enganche post-commit en su server SVN para enviar una notificación por correo electrónico sobre nuevas confirmaciones, y haga que alguien experimentado haga una revisión rápida con anticipación.

Podría poner un sistema de revisión por etapas como ReviewBoard . Ver también la charla de google en Mondrian . Estamos comenzando a usar la tabla de revisión aquí, pero de una manera "posterior a la confirmación", para la cual no está diseñada directamente.

Emparejado incluso con un sistema de compilation frecuente (activado en el compromiso), esto le dará mucha más confianza en el código. (Hacemos esto ahora)

Agregue testings unitarias automatizadas y / o testings funcionales automatizadas y obtendrá aún más confianza. (Hemos hecho esto en el pasado, pero ha sucumbido a un poco de putrefacción).

Incluso puede llegar tan lejos como un server de construcción de continuous integration (como varios otros han mencionado).

En un extremo, el process de confirmación podría ser:

  • publicar un parche (o URL de sucursal) en ReviewBoard; si no es así, solicite uno o más compañeros para una revisión
  • tenerlo revisado y aceptado
  • haga que el sistema de construcción CI lo construya y ejecute testings funcionales y de unidades
  • haga que el sistema de construcción CI lo comprometa solo si tuvo éxito
  • (entonces quizás ejecute análisis de código estático, como Gimpel PC-Lint, también antes o después de la confirmación).

(Nuestro process aquí en este momento es "revisión por pares guiada", "compromiso", "autoconstrucción con testing de arranque / funcionalidad realmente simple", potencialmente "revisión por pares formal" y, finalmente, "resultados de análisis de código estático de dirección").

En algún punto de una organización determinada, esto puede ser "excesivo", por lo que se aplica el típico "YMMV". Mire su process de construcción existente y descubra cuál es la "fruta más fácil", lo que será relativamente fácil de implementar, le dará buenos resultados y será fácil para que la gente se acostumbre. Siempre puede agregar más tarde, el time y los resources lo permitan.

Y ++ para todas las personas que mencionaron el enfoque de "abrazar al novato". Es mucho más importante que los recién llegados sientan que tienen una tonelada de resources de aprendizaje y herramientas para estar mejor a su disposition que tenerlos "castigados" o restringidos.

Cuando agregamos PC-Lint aquí la respuesta fue abrumadoramente positiva, al less una vez que descubrimos cómo mostrarle a la gente solo las advertencias de las que probablemente eran responsables. Se volvió less una responsabilidad y más un recurso de superación personal. (Ayuda si hyperlink ejemplos y explicaciones de estos informes).

  • Los desarrolladores deben ejecutar las testings unitarias antes de comprometerse, para que puedan evitar fácilmente los errores.

  • CI debe ejecutar las testings unitarias nuevamente después de confirmar, solo para asegurarse.

  • Los desarrolladores deberían comprometerse con las sucursales, que deberían fusionarse después de haber sido revisadas. Para un progtwigdor sénior que sea de confianza, esa "revisión" podría ser simplemente "¿Pasan las testings? ¿El código parece razonable?" Para los "novatos", puede ser más extenso.

En cuanto a la trazabilidad, una vez que está en el maletero, ¿a quién le importa? Si el código se rompe, el revisor que lo dejó pasar tiene mucha culpa, si no MÁS culpa, que el desarrollador (dado que SABEN que el desarrollador es un "novato desafortunado" y "no es confiable", deben saber mirar más cuidadosamente).

Revise los cambios en el tronco y pídales que apliquen las correcciones (si las hay). Eventualmente mejorarán y todos estarán felices.

Todos los proyectos de código abierto que he visto impiden los commits en el tronco, y nadie lo percibe como "draconiano". En cambio, se percibe como una necesidad obvia para proteger la integridad del código. Creo que las sucursales de desarrolladores son una solución perfectamente aceptable, con la clara intención de mover a los nuevos desarrolladores a "committers" tan rápido como puedan demostrarse a sí mismos.

Karl Fogel analiza esta situación y varias similares en su famoso libro, Produciendo Software de Código Abierto – Cómo ejecutar un proyecto de software libre exitoso , y llega a la misma conclusión: las testings estrictas y la revisión del código son más útiles que la autorización estricta.

Creo que es demasiado rígido. Si realiza revisiones de código, puede hacerlo en el enlace troncal. En lugar de fusionar la twig de desarrollador (que es tediosa), que es mucho trabajo, puedes echar un vistazo a lo que hicieron los desarrolladores. Esa es la idea de un sistema de revisión. Incluso puedes retroceder. Pero luego lo haces si algo es malo. No necesitas muchas acciones si el código es bueno. El resultado es que es less trabajo cuando el código es bueno. Puedes pasar ese time extra enseñando a tus novatos. El otro enfoque es puramente desmotivante para sus compañeros de trabajo.

La "cadena de events desafortunados";). Para ser honesto, parece que su Q & A no es tan rígida como su propuesta. Una mejor cobertura de testing y quizás un server de CI ayudará. Personalmente me gusta svn commit messages. Me mantiene actualizado con facilidad. Recibo un correo electrónico con una diferencia que alguien cometió. Fácil de hacer y los correos de compromiso no leídos también son una list de tareas pendientes.

Por lo tanto, es mejor aceptar principiantes y cambios. No dedique time y esfuerzo a las estructuras de control. Lo pasé mejor en la enseñanza de novatos y en la mejora del process.

Puede que me esté haciendo eco de cosas que otras personas dijeron, pero …

El process de entrevista debe ser lo suficientemente intenso como para eliminar a aquellos que no pueden manejar lo que requiere el puesto. Entonces, esa es mi solución preventiva.

Otra solución sería tener un progtwig tipo Mentoring / Sponsoring para pasantes / cooperativas / novatos, donde la política y los procedimientos de la compañía no solo se revisan en principio, sino en la práctica. Entonces, por ejemplo, el novato trabajaría codo a codo con el Patrocinador por un período de time para que él o ella pueda familiarizarse con la forma en que el negocio funciona día a día. De esta forma, además de adquirir experiencia, puede sentirse cómodo y acostumbrado a realizar su trabajo de la manera en que se supone que debe hacerse.