¿Cómo se revisan los bloques grandes del nuevo código

Question

? Soy un firme defensor de las revisiones de código, sea lo que sea que eso signifique. Sé que significa diferentes cosas para diferentes individuos y grupos y se puede aplicar de manera diferente en diferentes fases de desarrollo.

Cuando realizo un cambio de una línea a #define para corregir un error tipográfico en una cadena de aviso visible para el usuario, "Oye, Joe, ¿he deletreado 'FooBar' verdad?" es fácil. Cuando realiza algunos cambios relacionados en varias funciones relacionadas, un control de cordura sobre el hombro es de 10-15 minutos de trabajo.

Pero, ¿qué pasa con un nuevo proyecto con decenas de miles de líneas de nuevo código de marca? No sucede tan a menudo así que no estoy tan cómodo con eso. ¿Cómo revisas eso? ¿Uno a uno? Entregar y revisar "fuera de línea" con comentarios posteriores? En una configuración de grupo?

Para los diferentes enfoques, ¿hay reglas generales para las líneas/horas revisadas para que pueda estimar el tiempo para permitirlo?

Answer 1

Creo que se recomienda hacer la revisión de código antes de alcanza las mil líneas de código nuevo. Después de eso, se convierte en el problema al que te enfrentas.

Answer 2

Personalmente, cuando soy responsable de otro programador; Reviso la verificación del código fuente en diffs lo más cercano posible al diario

Esto está proporcionando todo está en un estado de trabajo. Si sus cambios no están en buen estado, esperaré hasta que lo hagan.

Si tardan más de 3 días en cambiar el estado de funcionamiento ... lo tomo como una advertencia que debe ser investigada. Esto suele ser algo simple, como hacer demasiados cambios al mismo tiempo o una refactorización importante con demasiadas implicaciones.

Answer 3

Si el código es bastante complejo, me gusta revisarlo con el desarrollador original de uno a uno. De esa manera puedo pedirles que expliquen cómo funciona en lugar de tomarse el tiempo necesario para resolverlo solo. Utilizo una herramienta de diferencias para ver qué ha cambiado en varios archivos y caminamos juntos por el flujo prestando mucha atención a los cambios.

Si el código es bastante sencillo, normalmente lo reviso yo solo. Solo llamo al desarrollador original si tengo preguntas o inquietudes. Una vez más, utilizo una herramienta diff para ver qué ha cambiado y recorrer el flujo.

Si hay un montón de nuevos códigos/cambios, entonces normalmente solo reviso la ruta crítica y comprobo el lugar de otras partes del código. En esta situación, no estoy tratando de encontrar todo lo que pueda estar mal con el código. Mi suposición es que las pruebas atraparán la mayoría de los errores. Mi revisión es principalmente para detectar errores importantes, para asegurarme de que el código siga las buenas prácticas básicas de software y que sea fácil de mantener.

Answer 4

Lo ideal sería hacer una revisión del código cuando se está construyendo, por lo que puede proporcionar comentarios y reducir los problemas de manera significativa.

Dicho esto, usaría herramientas de análisis estático. Eso puede verificar problemas regulares e incluso hacer un análisis general de las dependencias en el código.

Y lo primero sería: ¿tiene pruebas unitarias? Comience allí, compruebe que se entienden bien, puede revelar rápidamente algunos problemas de acoplamiento.

Si el código es para un sistema existente que está trabajando como un equipo, se debe considerar:

• La integración continua + cometer pequeños trozos de cambio (en vez de hacer un gran compromiso después de varios días)
• TDD: concéntrese en las pruebas unitarias del equipo, especialmente para evitar el acoplamiento apretado
• No solo se realizan pruebas unitarias, sino que se ejecutan periódicamente otro tipo de pruebas. Tenga diferentes tipos de pruebas separadas, por ejemplo, no desea que se activen las pruebas de carga en cada compilación.
• Tener herramientas de análisis estático ejecutándose con la compilación
• Analice la información de compilación como primer paso, antes de ir más allá con la revisión del código.

Answer 5

Mi enfoque es descomponer el trabajo en trozos más pequeños y revisar los cambios lo antes posible. Es mucho más fácil revisar 100-200 líneas de código que revisar varios miles y puede propagar los cambios que necesite realizar al código posterior.

Answer 6

integrar código de revisión con facilidad en sus proyectos:

• Introducir una regla obligatoria para la revisión de código antes de cualquier registro de entrada.
• Deje que el revisor escriba el comentario de check-in.
• Mencione al revisor en checkins de forma formal (por ejemplo, agregando un campo obligatorio de comentarios en su VCS) o de manera informal
• Cree un premio por reviwers, p. algunos sistemas de puntuación como en SO :-) (en serio, de lo contrario ninguno lo hará)

Answer 7

Si no puede hacer revisiones incrementales en el camino como otros han sugerido, aún puede gestionar una revisión post-facto de nueva funcionalidad dividiéndola en fragmentos manejables. Puede hacerlo clase por clase, módulo por módulo, función por característica o lo que mejor funcione para su sistema.

Una herramienta como Code Collaborator le permitirá agregar archivos seleccionados manualmente a una revisión del código, para que pueda descomponerlos de esa manera. Al carecer de una herramienta, también podría enviar al revisor varios "paquetes" de revisión de archivos relacionados.