¿Cómo promueves una cultura de revisión de código de pares con tu equipo?

Question

Hemos probado muchos métodos tales como la revisión

• Código requerido antes (para hacer cumplir duras)
• sesiones de revisión de código mensuales de facturación (tienden a lado de la pista, que consume tiempo, un nivel demasiado alto)
• Uno o dos desarrolladores con ciclos gratuito revisión de cambios como se abonen (participación baja)

utilizamos TFS y podría escribir una herramienta para aprovechar la API o construir un flujo de trabajo que podrían ayudar a promover pares de revisión de código.

¿Qué ha encontrado para tener éxito dentro de sus equipos?

No estoy por encima de los trucos y el soborno y prefiero la zanahoria sobre el palo.

Answer 1

Hemos adoptado algunas cosas que ayudan a que las revisiones de códigos sean más beneficiosas.

• nos dejó en claro que los exámenes no son una situación personal y la culpa no. Necesita fomentar la conversación, incluso si no es lo que alguien quiere escuchar.
• Razonablemente informal. Demasiado proceso puede ser su muerte.
• Permitir que los revisores lo hagan en su tiempo .Pase la información y dé una fecha para terminar.
• Tenemos una lista de preguntas frecuentes para el tipo de revisión común preguntas que ayudan a todos a obtener hablando el mismo idioma.
• Tenga tiempo de recursos reales asignado para comentarios. No debe tratarse como una ocurrencia tardía , sino más como un paso.
• Mantenga las revisiones pequeñas/enfocadas y haga con frecuencia. No lo convierta en un evento especial . Esto debería estar sucediendo diariamente/semanalmente.
• Además, no hay demasiados revisores. Esto lleva mucho más tiempo administrarlo. Obviamente incluyen revisores que son familiarizados con el diseño del código (¿quizás estuvieron involucrados en el anterior de alto nivel y/o en el diseño detallado opiniones?).

¡Muchos más, pero una buena lista para empezar!

hilo relacionadas: What is the best way to encourage communication in a team?

Answer 2

¿Qué ha encontrado para ser exitoso dentro de sus equipos? Primero apagado:

Realice un seguimiento del número de defectos que tiene con cada versión. Asegúrese de que sepan qué no funciona en la producción. Esto no es para culpar, pero tienes que ponerlos en la misma página. Deben darse cuenta con un poco de trabajo, pueden reducir este número.

Ahora:

La única cosa que es realmente beneficioso es que usted tiene que demostrar por qué es importante. Una vez que obtienen eso, no querrán vivir sin él. La clave para lograr que lo adopten es permitirles configurarlo en sus términos. Dígales que piensa que sería una buena idea y obtenga sus sugerencias sobre cómo implementarlo. Si intentas decirles cómo va a ser, lo más probable es que lo único que hagas sea agravarlos, y se resistirán a la adopción. Tienen que pasar por una fase de aprendizaje para probarlo y descubrir cómo hacerlo funcionar. Una vez que "poseen" el proceso (piensan que es suyo), comenzarán a aplicarlo, porque fue su decisión.

Answer 3

Ya no puedo encontrar el enlace, pero estaba discutiendo cómo la revisión por pares de los cambios de código podría terminar concentrándose en extraer la base de código existente en lugar de los cambios en sí mismos, no muy productivo cuando se considera cuál es el propósito de la revisión es En cambio, el artículo recomienda hacer una diferencia en el archivo actual y la versión anterior y solo revisar esos cambios. Lo siento, no puedo atribuir el artículo a su autor relevante, pero se me ha quedado grabado.

BTW, para que quede claro que no hay nada de malo en mirar siempre la base de códigos como un todo y obtener retroalimentación de todos/hacer cambios. Sin embargo, ese no es el propósito de una revisión por pares de los cambios de código.

Answer 4

Cuando usted está buscando para hacer algo con el proceso, se puede cambiar el flujo de trabajo de sus elementos de trabajo para incluir el estado "En la revisión de código". (esto podría ser un estado opcional o requerido)

Luego tiene al menos la lista de todos los elementos para ser revisados ​​por código.

También puede echar un vistazo al proyecto TeamReview en CodePlex: http://teamreview.codeplex.com/

Answer 5

Del mismo modo que un punto de datos, la empresa de consultoría de software para la que trabajo hace que la revisión del código de pares parte del proceso de desarrollo normal. Cada parche se envía, en un formato estándar, a la lista de correo del proyecto para su revisión. Los parches solo se pueden comprometer si alguien lo aprueba.

Creo que esta práctica debería ser la norma en todas partes.

Answer 6

Lo siguiente funcionó bien para mis equipos.

1. Cada pieza de código fue revisado antes de entrar en 'la construcción'.
2. Las revisiones fueron mentoreo proceso (mencionado en otras respuestas), no adversarial. Las desviaciones de eso se trataron como oportunidades educativas.
3. Teníamos un sistema de revisión vinculado al control de código fuente para que el incumplimiento pudiera ser monitoreado (muy bien).
4. El sistema de revisión nos permitió hacer estadísticas sobre los revisores y los revisados.
5. Un revisor por revisión, tan a menudo un compañero como una persona "senior".
6. Borrar codificación normas & expectativas.
7. Revisar diffs no es el código completo - evita seleccionar el código existente.
8. Se esperaba que el autor del código revisara sus cosas primero y que se aplicara estrictamente. Entonces, aunque alentamos un proceso de mentoría en su mayor parte, si el codificador simplemente arrojó basura sobre la pared que no se construiría, la arrojamos con un tic-tac.
9. Revisamos todo: construimos el código, verificamos los estándares de codificación, probamos las pruebas de unidad comprobadas para ver si se habían ejecutado y si también habíamos cumplido con los requisitos.
10. Los comentarios se registraron en una base de datos, pero insistimos en que hablo a través de la revisión en lugar de simplemente dejar los comentarios para que los recojamos (ya menudo se malinterpreten) más adelante. Use el teléfono + chat para desarrolladores remotos.

¿Suena caro? En realidad, pagó muchas veces con menores costos de mantenimiento.

¿Imposible implementar en un equipo antiguo? No. Implementamos esto sin ninguna revisión del código, establecimos expectativas y lo mantuvimos hasta que fue la base de nuestro proceso. Eso creó un equipo que era simplemente excelente, que tenía una tasa de defectos fantásticamente baja y absorbía bien a las personas nuevas (normalmente). Cuando ese equipo se separó, fue el día más triste de mi carrera.