Cómo mejorar nuestros code review
Hace casi veinte años, comencé como desarrollador en una empresa que implementaban code review. En ese momento, nunca había hecho una revisión de código ni mi código nunca había sido revisado.
Para mi primer proyecto, tuve que crear un componente COM en C ++ usando el marco ATL. ATL utiliza el recuento de referencias para administrar la vida útil de un objeto. El recuento de referencias significa que debe llamar a Release () cuando haya terminado de usar el objeto. Si olvida llamarlo, se produce una pérdida de memoria.
Recuerdo el resultado de mi primera revisión de código como si fuera ayer. Fue dramático.
No recuerdo el número exacto, pero estoy seguro de que hubo más de 100 comentarios de revisión. El revisor mencionó cada Release () que olvidé. El tono de la crítica fue duro. Luché con eso.
¿Fui un desarrollador tan terrible?
Actualmente, llevo más de una década haciendo revisiones de código. Realizar revisiones de código es el mejor método para mejorar la calidad del código y crear una cultura de aprendizaje y respeto.
Sin embargo, hay una receta específica para revisiones de código exitosas.
¿Por qué son críticas las revisiones de código?
Abra el último libro que leyó sobre programación u otro tema técnico y busque un párrafo titulado Agradecimientos al comienzo del libro.
Estoy seguro de que en este párrafo, el autor agradece a su editor por ayudar a crear una mejor versión del libro. La edición y revisión es el procedimiento estándar al escribir un libro.
¿Por qué no es lo mismo para el desarrollo de software?
Durante una revisión de código, otro desarrollador verifica su trabajo en busca de errores. El desarrollador señalará mejoras, tales como:
- código difícil de entender
- nombres poco claros
- código comentado
- código no probado
Además de buscar mejoras, el revisor aprende de la solución. Debería ver las revisiones de códigos como una oportunidad para crecer y como una red de seguridad, no como una oportunidad para criticar.
Las revisiones de código también son conocidas para prevenir errores. La investigación realizada por IBM² encontró que cada hora de inspección evitaba aproximadamente 100 horas de trabajo relacionado (prueba y corrección de defectos).
Automatizar lo que se puede automatizar
Antes de continuar y mirar mi receta para revisiones de código exitosas, tenemos que hablar sobre la automatización.
No pierda el tiempo durante las revisiones de código para comprobar si hay errores de estilo. En su lugar, acuerde una guía de estilo y use un linter o una herramienta de análisis estático para verificar ese estilo.
Además, asegúrese de que es posible ejecutar una compilación completa para verificar que todo sigue compilando correctamente y que todas las pruebas unitarias tienen éxito.
La automatización de todas estas tareas hará que la contribución de un revisor sea más valiosa. El revisor puede centrarse más en otros aspectos, como errores funcionales y legibilidad.
Receta para revisiones de código
Mi receta para una revisión exitosa del código consiste en dos conjuntos de ingredientes, uno para el autor de los cambios y otro conjunto para el revisor.
Ingredientes para el autor
Como autor de los cambios, usted tiene la responsabilidad de facilitar que el revisor comprenda la revisión de su código.
El tamaño del conjunto de cambios debe ser pequeño.
A nadie le gusta hacer revisiones de código que consisten en miles de líneas de cambios de código. Tomará mucho tiempo y existe una alta probabilidad de que sea necesaria una nueva revisión debido a una gran cantidad de cambios. Investigaciones han demostrado que el tamaño del conjunto de cambios influye en la utilidad de los comentarios. A medida que el conjunto de cambios aumenta, el número de comentarios útiles disminuye.
Así que asegúrese de que el tamaño de su conjunto de cambios sea pequeño, digamos, menos de 250 líneas de código. La revisión será de mayor calidad.
Revisa tu diff
No puedo decirte cuántas veces encontré errores simples al corregir mis pull request. La mayoría de las herramientas como GitHub, Bitbucket o Azure DevOps contienen herramientas para corregir su diferencia antes de enviar su pull request.
Como autor, siempre debe corregir los cambios en su código para encontrar errores comunes para que el revisor pueda centrarse en otros puntos.
Ingredientes para el revisor
Apunta a mejorar, no a la perfección
Intenta mejorar el código una muesca en lugar de hacerlo perfecto. Me ayuda a pensar en términos de calificaciones. Cuando recibo un pull request que comienza en una D, ayudo al autor a llevarla a una C, no perfecta pero mejor de lo que era.
¿Esto no degradará toda la base de código a una C? No lo creo. Me parece que cuando ayudo a un desarrollador a pasar de una D a una C, la próxima solicitud de extracción que envían comenzará en una C. Dentro de un par de pull request, me envían reviews que comienzan como Bs, que se convierten en As al final de la revisión.
Respetar el alcance de la revisión.
Simplemente, solo revise el código que se modificó. Si ve algo cerca del código modificado que cree que debería arreglarse, puede pedirle al autor que lo arregle. Pero recuerde que no está dentro del alcance de la revisión.
Si el pull request no cambió una línea, está fuera de alcance.
El tono de la reseña.
El tono de la revisión me parece uno de los aspectos más importantes de una revisión de código. Siempre trate de hacer preguntas abiertas en lugar de hacer declaraciones con opiniones. Ofrezca otras alternativas o posibles soluciones alternativas. Pero no insista en esas alternativas o soluciones alternativas.
Si no comprende algo, suponga que, como revisor, le falta algo y solicite una aclaración. Intente usar la palabra considerar. Por ejemplo: «¿Consideró refactorizar esto en un solo método?» o «Considere cambiar el nombre de este método por legibilidad».
Revisar de manera oportuna
Intente revisar la solicitud de extracción lo antes posible. Si primero tiene que terminar su tarea, informe al autor cuándo comenzará la revisión.
Use una lista de revisión
Debería intentar crear una lista de verificación que pueda usarse como referencia al realizar la revisión del código. Eche un vistazo a las siguientes categorías para obtener inspiración sobre los elementos que debe incluir en su lista de verificación:
- Robustez
- Corrección
- Diseño
- Mantenibilidad
- Diseño de API REST
- Globalización
- Actuación
- Seguridad
- Escalabilidad
- Testabilidad
Otra fuente de inspiración es ISO 25010, un estándar que define las características de calidad de un sistema de software.
