Cuándo hacer la revisión de código

Recientemente hemos pasado a un proceso scrum y estamos trabajando en tareas e historias de usuarios dentro de sprints. Nos gustaría hacer revisiones de código con frecuencia para que sean menos desalentadores. Estamos pensando que hacerlo en un nivel de historia de usuario, pero no estamos seguros de cómo ramificar nuestro código para dar cuenta de esto.

Estamos usando VS y TFS 2010 y somos un equipo de 6.

Actualmente ramificamos para funciones pero estamos trabajando para cambiar a ramificación para scrum.

Actualmente no usamos estanterías y realmente no queremos implementarlo si hay otras técnicas disponibles.

¿Cómo recomienda implementar una revisión de código por historia de usuario?

Depende de la naturaleza de las historias de los usuarios.

Puede ser efectivo crear una rama para cada historia de usuario, el progreso en diferentes historias son visibles, se pueden pasar si es necesario, si las historias no se completan en el sprint, el progreso puede permanecer en la rama para el próximo sprint . Las revisiones finales se pueden realizar al final de una historia de usuario en la rama de uso de la historia y fusionarse si el código está a la altura.

Para trabajar de la manera en que las historias deben ser finamente detalladas para evitar tareas de fusión inmanejables al final de un sprint. Las historias pequeñas permitirán una actualización constante de la rama de desarrollo a través del sprint del que los desarrolladores que trabajan en otras historias de usuarios deben obtener constantemente (VCM básico).

Esto crea gastos generales de proceso que tienen que crear y fusionar ramas constantemente, lo que en algunos casos se puede resolver con scripts de automatización, pero el equipo aún debe sentirse muy cómodo con el VCS.

Al final de un sprint, fusionas tu rama de desarrollo en integración / producción, etc.

También he trabajado en equipos donde todos trabajan desde una rama de desarrollo, al completar una historia de usuario, el código se envía a esa rama para su revisión y prueba, y si alguien empuja algo que rompe la construcción del desarrollo, tienen que conseguir las cervezas del equipo.

La forma más efectiva de revisar el código es ponerse de pie, encontrar a alguien y pedirle que venga y discuta el código que acaba de desarrollar.

No use una herramienta a menos que no pueda encontrar a alguien para revisar su código localmente.

Puede evitar las revisiones de código por completo mediante el emparejamiento.

¿Todos los miembros del equipo son locales? Si es así, solo pídale a alguien que venga y eche un vistazo antes de que se registre el código. ¿No es local? Encienda su programa favorito para compartir pantalla y llame a alguien. Yo personalmente hago esto a menudo. A veces lo hago solo para decir "¡Oye, mira lo que hice!"

Prefiero este estilo de revisiones de código ad-hoc al estilo en el que alguien está de pie y presenta su código al equipo. Las revisiones ad-hoc pueden darle muchos (¿todos?) De los beneficios del emparejamiento sin la incomodidad. Además, es más probable que su "revisor" haga preguntas y sugiera mejoras en un entorno informal y personalizado.

Creo que la revisión de código no es una parte formal de SCRUM, pero las revisiones son una táctica independiente para lograr calidad y mejorar sus proyectos / equipo.

Por lo tanto, usaría SCRUM (u otra metodología de desarrollo ágil) para asegurar / mejorar la calidad del PROYECTO y mantener el cronograma. Además, una buena táctica es hacer una revisión del producto (no código) independientemente de sus tareas normales de control de calidad / pruebas. Si esta actividad se pudiera hacer frente a su equipo / socios / clientes / audiencia, sería mejor.

Debe usar revisiones de código (u otras revisiones específicas) principalmente para mejorar su EQUIPO, esperando resultados a medio / largo plazo. Esto afectará sus PROYECTOS, pero a largo plazo como producto de la mejora de su EQUIPO.

Entonces, para responder a su pregunta, creo que está tratando de presionar demasiado a SCRUM, y debería considerar las revisiones solo tal como están.

¿No es obvio hacer revisiones de código antes de registrar su código?

TFS no funciona como GIT, por lo que cada vez que ingresa el código en una rama o troncal, está disponible para todos.

Esto significa que la revisión debe realizarse en el check-in para que los cambios no se propaguen a la copia de trabajo de todos.