Me gustaría saber con qué frecuencia las personas hacen revisiones de código y con qué frecuencia cree que es correcto hacer una revisión. Además, me gustaría saber cómo lleva a cabo las revisiones de su código. Estoy usando TTC por ahora y estoy bastante satisfecho con él, pero no creo que cubra todas las partes del código.¿Con qué frecuencia se deberían hacer las revisiones del código?
Siempre realizamos una revisión del código antes de que se haya cometido el código en el maletero. Estoy de acuerdo con el comentario de Neil Butterworth de que los commits frecuentes son algo que debe alentarse y que requerir una revisión del código antes de cada commit inhibe esto.
Las condiciones exactas que funcionarán dependen del entorno y del proyecto. Nuestro entorno es tal:
En nuestro entorno, esto permite a los desarrolladores a menudo cometen (dentro de los confines de su propia rama) y para revisiones a realizar cada unidad de trabajo (pero no todos los cambios) código.
En cuanto a Cómo realizar una revisión de código, esta es una pregunta mucho más ambiciosa. Uno que merece su propia pregunta en el SO (y en realidad hay ya varios):
https://stackoverflow.com/questions/89163/how-to-conduct-a-successful-code-review Best Peer Code Review Software https://stackoverflow.com/questions/tagged/code-review
Antes del check in. El registro a menudo se conecta con el acabado lógico de la función/módulo (depende del programador), por lo que este es un buen momento. Cuando el código está registrado, ya es difícil rastrear quién codificó qué y cuándo.
estoy totalmente en desacuerdo con que una revisión de código debe tener lugar antes de que un registro de entrada. Los registros frecuentes son algo que debe alentarse, y una revisión del código, aunque es una herramienta esencial, solo puede interferir con esto. –
@ Neil, ¿podría responder con sus alternativas por favor? –
También es una buena idea tener cada revisión de un tamaño con el que su equipo se sienta cómodo. Está buscando un equilibrio entre el tamaño de los cambios y la frecuencia con la que se realizan las revisiones. Los trozos son demasiado grandes y los revisores pierden interés y pueden pasar por alto en lugar de prestar mucha atención. Las revisiones demasiado frecuentes podrían posponerse a favor del trabajo real de los revisores. –
En cualquier momento que se vaya a registrar un código, antes de realizar el check in. Sin embargo, es posible que desee hacerlo más a menudo dependiendo del proyecto.
Si alguien está trabajando en un proyecto que llevará semanas y no verificará ningún código para ese período, el código debería recibirse a medida que se realizan varios componentes del proyecto. El motivo es que se revisará continuamente el código para asegurarse de que no se repita un patrón de diseño incorrecto a lo largo de todo el proyecto y los cambios necesarios de la revisión sean menores.
También sugeriría que cuanto más joven sea un desarrollador, más a menudo se debe revisar el código.
¿No realiza el check-in durante semanas? El código debe registrarse varias veces al día. –
Quizás una mejor manera sea la promoción a la sucursal matriz en lugar de la facturación. –
Enfoque interesante, ¿qué herramientas usas para simplificar esto para que no haya un montón de pasos involucrados al comenzar a trabajar en un error/característica/lo que sea? –
+1: Esta es una práctica bastante común para todos los proyectos en los que he trabajado. Fácil y simple. –
Utilizamos FogBugz para nuestro seguimiento de casos y Subversion para nuestro control de origen. Cuando comenzamos a trabajar en un caso, simplemente nos ramificamos de trunk con TortoiseSVN y cambiamos nuestra copia de trabajo. Luego, cuando el trabajo esté completo y listo para su revisión, simplemente asignaremos el caso al revisor. Cuando se completa la revisión, el desarrollador original la fusiona en el tronco con TortoiseSVN. Creo que FogBugz 7 (todavía estamos en 6) proporciona administración de flujo de trabajo, por lo que podría automatizar un poco del flujo de trabajo, pero no los pasos de SVN. No hemos encontrado que sea difícil o tedioso seguir este flujo de trabajo. –