Buena canalización

La mayoría de los equipos tienen algún tipo de reglas de estilo de código y recomendaciones sobre cómo uniformar su base de código. Hagas lo que hagas, no fuerces a los revisores de código a verificar siempre que la solicitud de extracción cumpla con esas reglas. Hay herramientas para hacer eso en eslint, SonarQube. Estas herramientas deben ejecutarse como parte de su canal de relaciones públicas.

SonarQube es una de esas herramientas que mejorará las code reviews (revisiones de códigos) para todos los miembros de su equipo. Puede encontrar problemas de estilo, pero puede hacer mucho más. Con su análisis de código, pueden encontrar los errores más comunes que puede cometer en su código. ¿Nunca cerraste tu recurso? Sonar te lo hará saber. Personalmente, nunca reviso el código antes de que Sonar termine su trabajo.

Necesita tener un proceso concreto que se ejecute cada vez que alguien crea un PR o empuja nuevos cambios allí. Los pasos pueden tener este aspecto.

• Compila el código
• Ejecuta las pruebas
• Ejecutar pelusa
• Ejecute SonarQube
• Hacer el proceso de revisión manual
• Fusionar con la base de código principal

Trasvolar

Como primera cosa, en el code review, haremos una descripción general rápida de todos los archivos modificados. Esto lo hacemos dentro de la interfaz de usuario de la solicitud de extracción. Nos estamos enfocando en algunas cosas durante esta etapa.

Primero está la legibilidad del código. ¿Cómo es la experiencia de lectura? ¿Es evidente lo que se está haciendo? Un buen código debería poder transmitir su propósito a primera vista. Luego estoy tratando de averiguar si este cambio es lo que requiere la solicitud de cambio correspondiente. Leeremos el ticket e intentaremos cumplir con todos los requisitos en la solicitud de extracción.

Durante esta etapa, no profundizo en los detalles de implementación. Los identifico para etapas posteriores.

Posibles puntos transmitidos en esta etapa:

• el cambio no es muy legible
• el cambio no cubre los requisitos, o el ticket de solicitud de cambio no se cambió a medida que cambiaron los requisitos
• pruebas faltantes

Vaya en profundidad

Después del breve paso elevado del código, haga una lista de archivos modificados en los que necesite profundizar. Por lo general, haga esto en IDE para poder ver mejor las conexiones entre archivos, pero para la mayoría de los cambios, está bien hacerlo en la interfaz de usuario web de la solicitud de extracción.

Empiece por hacer la pregunta de cómo resolvería el problema y parta de ahí. ¿Hay algún fragmento de código en nuestra base de código que haga algo similar (o lo mismo)? ¿Existe una biblioteca (que usamos actualmente) que se pueda usar para esto? Si hay una biblioteca que no usamos actualmente, ¿vale la pena agregarla para resolver este problema?

Revisión de la prueba

No olvide revisar las pruebas. ¿Todos los casos son válidos? ¿Tienen esas pruebas la posibilidad de encontrar algo? ¿Son legibles las afirmaciones? ¿Están presentes las pruebas?

No tenga miedo de contraatacar para agregar más pruebas si, como revisor, cree que existe la posibilidad de agregarlas para mejorar el código base.

Sea amable y eduque

Haga lo que haga, no sea arrogante, sarcástico y/o suene como un sabelotodo. Si la solución propuesta es válida, pero lo haría de manera diferente, puede decirlo pero también aprobar la solicitud. Puede dejar comentarios educativos, pero demasiados pueden ser perjudiciales. Considere lo que se siente importante. No discutas por pequeñas cosas, las personas son diferentes y tienen opiniones diferentes.

Aprobación

Sea rápido en la aprobación, no perfecto está bien.

Esta es la regla de oro que debes seguir.