Hacer que TODOS los desarrolladores realicen revisiones de código

No elegimos revisores.

En nuestro equipo:

• Todos los cambios de código deben revisarse antes de que se complete la Solicitud de extracción
• Al menos un desarrollador debe revisar el código (dos o más revisores son mejores y tener evaluadores, analistas y otros miembros del equipo que realizan la revisión del código también es extremadamente beneficioso)

Las revisiones de código no están asignadas, las personas las recogen cuando les funciona. El entendimiento es que no podemos empujar historias a través de la tubería. En ocasiones, alguien mencionará que está esperando un CR en el standup, pero eso es todo.

Me gusta este modelo, le permite a la gente recoger lo que puede y evita "dar trabajo a la gente".

Introduzca una regla que indique que se puede asignar un error para corregirlo, no solo a quienes cometieron el cambio, sino a quienes lo revisaron. Eso debería crear la perspectiva correcta para la revisión del código.

En cuanto a,

  

¿Cree que los revisores de códigos deberían ser recompensados por el tiempo que dedican a hacer (buenos) comentarios de códigos?

Bueno, no estoy seguro de qué tan generalmente los desarrolladores son recompensados por hacer su trabajo, excepto obtener un salario y estar un poco orgullosos de lo que han hecho. Pero como el código de revisión es parte de su trabajo, el revisor debe obtener tiempo para la revisión y compartir el crédito de alguna manera.

El principal problema que tiene no es técnico, pero algunas herramientas pueden reducir la cantidad de esfuerzo que requieren las revisiones de código. Hay algunos desafíos que superar:

• Entendiendo que es el cambio. Las solicitudes de extracción de Git en las sucursales de funciones realmente ayudan a este proceso.
• Hacer que el código revise un evento donde las personas tienen que estar en la misma sala. Esto agrega el estrés de la programación, los recursos de la reunión, etc. GitHub, GitLab y BitBucket permiten revisiones asíncronas para que puedan ocurrir cuando el par esté listo.
• La capacidad de proporcionar comentarios significativos cuando se mira el código. Para ser honesto, la función de comentarios línea por línea en GitHub, GitLab, Bitbucket, las solicitudes de extracción realmente son más útiles que una reunión cara a cara. Se siente menos político.

Eso no quiere decir que no pueda usar SubVersion u otras herramientas (como Fisheye) para ayudar, pero la integración integrada en el canal de Git con ramas de características realmente hace que el trabajo sea menos que una tarea.

Fuera de las herramientas, debe considerar más desafíos sociales:

• Haga que sus desarrolladores comiencen el día revisando cualquier solicitud de extracción abierta para firmarla.
• Haga que sus desarrolladores revisen cualquier solicitud de extracción abierta antes de comenzar una nueva tarea
• Requiera la aprobación de más de una persona para sus solicitudes de extracción.

También podría valer la pena comprobar qué tipos de tareas están siendo revisadas por el código de las personas más comprometidas. Podrían estar tomando todas las revisiones fáciles, lo que hace que las cosas sean más dolorosas para todos los demás.

Una buena idea es hacerlo por turnos: elige a alguien que haya realizado el menor número de revisiones para su código. Con el tiempo, todos los miembros del equipo deberían haber realizado aproximadamente un número igual de revisiones. Difunde el conocimiento también.

Obviamente, habrá excepciones ocasionales, como los días festivos, donde habrá picos y valles.

No debe haber distinción entre juniors y seniors / leads. Las revisiones de códigos se deben realizar para el código de todos, sin importar qué tan avanzados sean. Reduce la fricción y ayuda a compartir diferentes enfoques.

Si todavía está preocupado por la calidad de las revisiones después de todo esto, considere la posibilidad de introducir un conjunto de estándares mínimos para que pase una revisión de código. Lo que incluya depende totalmente de usted, pero algunas cosas que debería considerar son: cobertura de código, pruebas unitarias, eliminación de código comentado, métricas, comentarios suficientes, calidad de construcción, principios SOLID, SECO, KISS, etc.

En cuanto a incentivar las revisiones de códigos, el código de calidad es la recompensa. Todos estamos seguros de que hemos trabajado en bases de código subóptimas en las que el dolor podría haber disminuido considerablemente si otro desarrollador hubiera dado el código una vez más desde el principio y sugiriera cambios constructivos.

Parece que el equipo carece de un proceso formal para las revisiones de código.

No estoy hablando de crear un documento de Word de 350 páginas, sino de algunos puntos simples sobre lo que implica el proceso.

Los bits importantes:

1. Defina un conjunto básico de revisores. No hay declaraciones generales. Nombrar personas.

   Estos deberían ser tus desarrolladores senior.

2. Requieren que más de un revisor principal se firme en la revisión.

3. Identifique al menos otro revisor no central por cada sprint o lanzamiento que sea un revisor central temporal. Solicite su firma en todas las revisiones de código durante este tiempo.

El artículo # 3 permite que los otros desarrolladores giren hacia el grupo de revisores principales. Algunas semanas pasarán más tiempo en revisiones que otras. Es un acto de equilibrio.

¿En cuanto a recompensar a las personas? Muchas veces, reconocer el esfuerzo que hace una persona durante la revisión del código frente a todo el equipo puede funcionar, pero no se preocupe por esto.

En caso de duda, defina el proceso y dígale al equipo que debe seguirlo.

Y hay una última cosa que puedes probar, por más controversial que sea: deja que el @ # $% golpee al fanático, si puedo usar un modismo.

Deje que el equipo falle, porque no se está siguiendo el proceso de revisión del código. La gerencia se involucrará y la gente cambiará. Esta es realmente solo una buena idea en los casos más extremos en los que ya definió un proceso y el equipo se negó a cumplirlo. Si no tiene la autoridad para despedir a las personas o disciplinarlas (como la mayoría de los desarrolladores líderes no ), entonces necesita involucrar a alguien que pueda hacer esto.

Y no hay nada como el fracaso para que las cosas cambien. A pesar de lo que la gente pueda decir, usted puede dirigir el Titanic, pero no antes de que llegue a la plataforma de hielo.

A veces solo necesitas dejar que el Titanic golpee la plataforma de hielo.