Revisión de código: la guía definitiva

La guía definitiva para crear el proceso de revisión de código de su equipo

Después de realizar cientos de revisiones de código, liderar equipos de I + D e impulsar varios errores involuntarios yo mismo, he decidido compartir mis conclusiones para crear el proceso de revisión de código definitivo para su equipo.

Este artículo asume que sabe qué es una revisión de código. Entonces, si no lo hace, haga clic aquí para obtener una excelente introducción.

Indiquemos rápidamente algunas razones sencillas de por qué debería hacer revisiones de código:

  1. Puede ayudar a reducir errores en el código.
  2. Valide que se hayan cumplido todos los requisitos de codificación.
  3. Una forma eficaz de aprender de sus compañeros y familiarizarse con el código base.
  4. Ayuda a mantener el estilo del código en todo el equipo.
  5. Cohesión del equipo: anime a los desarrolladores a hablar entre ellos sobre las mejores prácticas y los estándares de codificación.
  6. Mejora la calidad general del código debido a la presión de los compañeros.

Sin embargo, las revisiones de código pueden ser una de las partes más difíciles y que requieren más tiempo del proceso de desarrollo de software.

Todos hemos estado allí. Es posible que haya esperado días hasta que se revisó su código. Una vez que se revisó, inició una mesa de ping pong con el revisor para volver a enviar su solicitud de extracción. De repente, pasas semanas yendo y viniendo. Estás cambiando de contexto entre nuevas funciones y antiguas confirmaciones que aún necesitan pulirse.

Si el proceso de revisión del código no se planifica correctamente, podría tener más costo que valor.

Por eso es extremadamente importante estructurar y construir un proceso bien definido para revisiones de código dentro de su equipo de ingeniería.

En general, deberá contar con pautas bien definidas tanto para el revisor como para el examinado, antes de crear una solicitud de extracción y mientras se revisa. Más específicamente:

Defina las ventajas para crear solicitudes de extracción.

Descubrí que lo siguiente reduce en gran medida la fricción:

  1. Asegúrese de que el código se compile correctamente.
  2. Lea y anote su código.
  3. Cree y ejecute pruebas que validen el alcance de su código.
  4. Se debe probar todo el código en la base de código.
  5. Vincule tickets / elementos relevantes en su herramienta de administración de tareas (por ejemplo, JIRA) a su solicitud de extracción.
  6. No asigne un revisor hasta que haya finalizado lo anterior.

Definir las responsabilidades del examinado

Si bien el revisor es el último en la cadena de fusión de su PR, cuanto mejor sea entregado por el revisor, menos riesgos correrá a largo plazo. Aquí hay algunas pautas que pueden ser de gran ayuda:

  1. Comuníquese con su revisor : proporcione a sus revisores los antecedentes sobre su tarea. Dado que la mayoría de los autores de solicitudes de extracción probablemente ya hemos sido revisores, simplemente póngase en el lugar del revisor y pregunte: "¿Cómo podría ser más fácil para mí?"
  2. Realice solicitudes de extracción más pequeñas: realizar solicitudes de extracción más pequeñas es la mejor manera de acelerar el tiempo de revisión. Mantenga sus solicitudes de extracción pequeñas para que pueda iterar de manera más rápida y precisa. En general, los cambios de código más pequeños también son más fáciles de probar y verificar como estables. Cuando una solicitud de extracción es pequeña, es más fácil para los revisores comprender el contexto y razonar con la lógica.
  3. Evite cambios durante la revisión del código : los cambios importantes en medio de la revisión del código básicamente restablecen todo el proceso de revisión. Si necesita realizar cambios importantes después de enviar una revisión, es posible que desee enviar su revisión existente y hacer un seguimiento con cambios adicionales. Si necesita realizar cambios importantes después de comenzar el proceso de revisión del código, asegúrese de comunicárselo al revisor lo antes posible en el proceso.
  4. Responda a todos los comentarios de revisión de código procesables : incluso si no implementa sus comentarios, responda y explique su razonamiento. Si hay algo que no comprende, haga preguntas dentro o fuera de la revisión del código.
  5. Las revisiones de código son discusiones, no dictados : puede pensar en la mayoría de los comentarios de revisión de código como una sugerencia más que como un pedido. Está bien no estar de acuerdo con los comentarios de un revisor, pero debe explicar por qué y darles la oportunidad de responder.

Definir las responsabilidades del revisor

Dado que el revisor es el último en la cadena antes de fusionar el código, una gran parte de la responsabilidad recae en él para reducir los errores. El revisor debe:

  1. Tenga en cuenta la descripción y los requisitos de la tarea.
  2. Asegúrese de comprender completamente el código.
  3. Evalúe todas las compensaciones de la arquitectura.
  4. Divida sus comentarios en 3 categorías: Crítico, Opcional y Positivo. Los primeros son comentarios que el desarrollador debe aceptar para cambiar, y los segundos son comentarios que le hacen saber al desarrollador su apreciación por buenos fragmentos de código.

Además, evite muchos comentarios y use la revisión de Github en su lugar (vea el ejemplo a continuación).

Cuando tenga varios comentarios, debe usar la opción de revisión en Github, en lugar de comentar cada uno de ellos por separado, y notificar al desarrollador (propietario de relaciones públicas) cuando haya terminado.

Finalmente, descubrí que hacer las siguientes preguntas es una gran herramienta para un proceso de revisión general mejor y más fácil:

  • ¿Tengo dificultades para entender este código?
  • ¿Existe alguna complejidad en el código que podría reducirse mediante la refactorización?
  • ¿Está el código bien organizado en una estructura de paquete que tenga sentido?
  • ¿Son intuitivos los nombres de las clases y es obvio lo que hacen?
  • ¿Hay clases que sean notablemente grandes?
  • ¿Existen métodos particularmente largos?
  • ¿Todos los nombres de los métodos parecen claros e intuitivos?
  • ¿Está bien documentado el código?
  • ¿Está bien probado el código?
  • ¿Existen formas en las que este código podría hacerse más eficiente?
  • ¿El código cumple con los estándares de estilo de nuestros equipos?

Hay varias prácticas de revisión de código diferentes y efectivas que varían según las necesidades del equipo. Así que asuma que esta es mi opinión personal y que hay otras formas que podrían funcionar para su equipo. Al final, la construcción de un proceso tan sensible debería ser subjetivo para los objetivos de su empresa, la cultura del equipo y la estructura general de I + D.

Si tiene alguna pregunta o comentario para mejorar estas pautas, ¡no dude en agregar un comentario a continuación!