¿Cuál será la mejor manera de administrar el código fuente revisado en un repositorio de control de fuente? ¿Debería el código fuente pasar por un proceso de revisión antes de ser registrado, o la revisión del código debe ocurrir después de que se confirme el código? Si la revisión ocurre después de que el código se haya registrado en el repositorio, ¿cómo se debe rastrear?
Respuestas:
Google tiene las mejores prácticas de revisión de código de cualquier lugar que haya visto. Todos los que conocí allí están totalmente de acuerdo sobre cómo hacer revisiones de código. El mantra es "revisar temprano y con frecuencia".
Suponga que usa un proceso que se parece a lo que sugirió Graham Lee. (Que es un proceso que yo mismo había utilizado anteriormente). El problema es que se les pide a los revisores que observen grandes fragmentos de código. Eso es mucho más esfuerzo y es más difícil lograr que los revisores lo hagan. Y cuando lo hacen, es más difícil lograr que hagan un trabajo completo. Además, cuando notan problemas de diseño, es más difícil lograr que los desarrolladores retrocedan y rehagan todo su código de trabajo para mejorarlo. Todavía atrapa cosas, y todavía es valioso, pero no notará que le falta más del 90% del beneficio.
Por el contrario, Google tiene una revisión de código en cada confirmación antes de que pueda pasar al control de fuente. Ingenuamente, muchas personas piensan que este sería un proceso pesado. Pero no funciona así en la práctica. Resulta enormemente más fácil revisar pequeños fragmentos de código de forma aislada. Cuando se encuentran problemas, es mucho menos trabajo cambiar el diseño porque todavía no ha escrito un montón de código en torno a ese diseño. El resultado es que es mucho más fácil hacer una revisión exhaustiva del código, y mucho más fácil solucionar los problemas modificados.
Si desea hacer una revisión de código como lo hace Google (lo cual realmente, realmente recomiendo), hay un software para ayudarlo a hacerlo. Google ha lanzado su herramienta integrada con Subversion como Rietveld . Go (el lenguaje) está desarrollado con una versión de Rietveld que se modifica para usar con Mercurial. Hay una reescritura para las personas que usan git llamado Gerrit . También he visto dos herramientas comerciales recomendadas para esto, Crucible y Review Board .
El único que he usado es la versión interna de Google de Rietveld, y quedé muy satisfecho.
Una técnica que he usado en varios equipos es esta:
Es responsabilidad del autor del código buscar la revisión, y es responsabilidad del responsable del lanzamiento de la sucursal asegurarse de que solo el código revisado se fusione.
Hay herramientas que admiten la revisión de código, pero nunca las he usado. El seguimiento de quién realizó la revisión para cualquier fusión se puede hacer dentro del repositorio. He utilizado las propiedades de svn y los trabajos de ejecución adjuntos a las confirmaciones para mostrar quién revisó qué.
Nunca he separado el código para su revisión por criterios comprometidos / no comprometidos; el único criterio que he encontrado es que las pruebas unitarias y las pruebas de integración son verdes.
En cuanto al seguimiento, recomendaría actualizar el flujo en su rastreador de problemas favorito. Por ejemplo en lugar de:
Es posible que desee presentar una etapa más (revisión):
Por lo tanto, para cada boleto en estado Implementado , puede asignar un revisor y solo los boletos Revisados avanzarán al control de calidad.
Solo tengo una experiencia de revisiones de código, así que no puedo decir qué tan bueno es.
Estaba trabajando con un pequeño grupo (~ 10-15) de codificadores, y estábamos usando VS Team Foundation Studio. Se nos solicitó el código de confirmación aproximadamente una vez al día, y antes de que cada código de confirmación fuera revisado por otra persona del grupo (con suerte, también por alguien involucrado en el proyecto). Durante la confirmación, el nombre de la persona también se incluyó en un campo.
Trabajé en un equipo que revisó por código todo lo que se verificó cambio por cambio durante un par de revisiones por semana. Esto significaba que no siempre estábamos al día con las revisiones de código, pero logró lo que nos propusimos lograr.
Primero, pregunte qué quiere lograr revisando el código. En nuestro caso, no fue para atrapar desarrolladores idiotas, hubo una suposición de competencia en lugar de una suposición de incompetencia. Permitió que el equipo obtuviera una visión general de otras áreas del sistema, y permitió que algunas decisiones de diseño cuestionables se corrigieran antes de convertirse en piedra. Por cuestionable, quiero decir que siempre hay más de una forma de desollar a un gato, y no todos saben que ya hay un cuchillo para desollar en la caja de herramientas, por así decirlo.
La forma en que abordamos las revisiones de código fue que se revisaron todas las tareas de nuestro software de seguimiento de proyectos. En ese momento estábamos usando Mantis y SVN. Los compromisos de nuestro proyecto estaban vinculados a ambos sistemas. Cada compromiso tenía que estar vinculado a una tarea en mantis. Una vez que se completó la tarea, se le asignó un estado de "Listo para revisión".
Los artículos de RFR fueron recogidos por cualquiera que tuviera algo de tiempo libre para revisiones o fue asignado a una persona específica para revisión. Los viernes, todos los artículos de RFR debían revisarse antes del final del día para que no quedaran remanentes a la semana siguiente.
Los únicos problemas que tuvimos con este proceso fueron elementos grandes que tenían una tonelada de archivos. Para manejar esto, el codificador y el revisor se reunirían y el codificador revisaría los cambios hasta que el revisor los entendiera. Harían la revisión del código juntos.
Este proceso se interrumpió cuando la administración dictaminó que si se realizaba la programación entre pares, una revisión de código por separado era innecesaria. Los desarrolladores se volvieron laxos sobre el proceso y comenzaron a introducirse pequeños errores estúpidos. Finalmente volvimos al proceso original y las cosas volvieron a estar juntas.
En mi equipo hemos estado usando una práctica durante el año pasado más o menos que parece funcionar muy bien.
Nuestra organización utiliza Perforce para el control de versiones. Perforce (desde hace un año) incluye una característica llamada Shelving. Con estanterías, puedo "archivar" mis cambios para un problema en particular. Se almacenan en el sistema de control de versiones pero no se registran. Luego le pido a otro desarrollador de mi equipo que revise el código.
El otro desarrollador puede ver mis cambios pendientes en Perforce desde su propia computadora y comparar los cambios con las revisiones más recientes. También puede "dejar de lado" su máquina local si quiere probar mis cambios. Cuando completa la revisión, me avisa. Luego verifico mi código con "Revisado por Bob" al final del comentario.
Esto ha funcionado realmente bien para nosotros. En primer lugar, las revisiones de código en general han demostrado ser extremadamente útiles. Además, la función de estantería de Perforce nos permite hacer las revisiones sin registrarnos ni ninguna dificultad importante a pesar de que nuestro equipo está geográficamente extendido, eso es muy importante. Y funciona muy bien.