Revisiones de código efectivas

Las revisiones de código son una parte esencial de cualquier equipo de desarrollo de software, lo ayudan a reducir las posibilidades de tener un código con errores.

Yo mismo he estado haciendo revisiones de código durante más de 6 años y en ese tiempo he revisado más de 600 solicitudes de extracción. Ahora estoy escribiendo esta publicación para compartir mis aprendizajes, con la esperanza de que ayude tanto al revisor como al revisor.

Antes de entrar en la madriguera del conejo de qué y qué no hacer durante las revisiones de código, quiero resaltar la importancia de las revisiones de código.

La gente suele pensar en las revisiones de código como una tarea de baja categoría que solo aumenta el tiempo entre "Desarrollado" y "Listo para el control de calidad". La afirmación anterior es “verdadera” cuando las revisiones del Código se están haciendo “ No con las intenciones correctas ”.

Aquí hay algunos escenarios que se agregan a la revisión del código que se está realizando pero que no ayudan a nadie:

1. El revisor está revisando el código por el simple hecho de hacerlo. Está aprobando solicitudes sin mirar o simplemente desplazándose por ellas una vez.
   Este tipo de revisores pronto se etiquetan como revisores fáciles y luego son seleccionados para obtener el código más rápido.
2. El revisor está revisando el código sin comprender los requisitos de la tarea.
3. El revisor está agregando comentarios sin el razonamiento real detrás de por qué se requiere el cambio
4. El revisor solo está comprobando la sintaxis y no la lógica real.
   Si un revisor piensa que el revisor sabe más que él, es probable que esto suceda.
5. El Revisor no está tratando de entender el razonamiento detrás de un comentario. Entonces, o simplemente sigue los comentarios a ciegas o los ignora.

¿Por qué debería revisar el código de otra persona?
Uno podría pensar que no hay ventajas en revisar el código de otra persona, ya que podría creer que no está aprendiendo nada nuevo. De lo contrario-

1. Los revisores obtienen una comprensión de las tareas que se están llevando a cabo dentro del equipo.
2. Llegan a conocer los servicios que existen dentro del sistema. Lo que mejora la reutilización
3. Aprenden nueva sintaxis o formas de codificar y hacer cosas.

Sin embargo, seguiría enumerando algunas cosas que la gente suele pasar por alto al hacer revisiones de código.

Reglas generales

1. Se debe prestar especial atención a la "legibilidad del código" y la "reutilización del código".
   Los nombres de variables y funciones son descriptivos y significativos. No se deben usar nombres como i.a
2. El código no debe ser redundante (las herramientas de calidad de código como "sonarlint" son muy útiles en estos casos)
3. Los casos de prueba unitaria son imprescindibles para las funciones de utilidad.
4. El trabajo de cada función debe estar claramente definido y debe seguir el principio de responsabilidad única.
5. Verifique los niveles de registro. El contenido del registro debe tener información procesable
   Algo así como: "obtuve un error del caché" no tiene ninguna información procesable
6. Deberíamos tener métricas en su lugar donde sea necesario
7. Compruebe si el proceso (registro, llamadas externas, base de datos, caché) debe estar sincronizado o asincrónico
8. Por lo general, la gente no presta mucha atención a los casos de prueba unitaria. Se debe pensar si todos los escenarios están cubiertos o no.
9. Para una característica crucial que podría afectar el viaje del usuario, uno siempre debe tener una alternativa para volver al flujo anterior.
10. El revisor debe tratar de dividir los cambios en varios componentes más pequeños y crear solicitudes de extracción para ellos de forma independiente y lo antes posible. Esto no solo le da al revisor más tiempo, sino que también asegura que los problemas (si los hay) o los escenarios extremos se detecten temprano.
11. No confíes en nadie. Cuestionar todo. A veces, si confiamos en el autor, no profundizamos en su código.
12. El revisor debe revisar su solicitud de incorporación de cambios al menos una vez antes de compartirla para su revisión. Esto garantiza que las cosas básicas como: código comentado, TODO pendientes, cambios de espacios en blanco, etc. se solucionen incluso antes de compartir el PR
13. Verifique las sucursales de origen y destino, si son correctas o no.

1. Si la llamada externa está altamente acoplada o no (altamente acoplada significa que un error en la llamada externa provocará un error en este flujo)
2. Tiempos de espera y mecanismos de reintento
3. Requisitos de muestreo y limitación de velocidad
4. Métricas de llamadas externas (latencia, tasa de éxito)

1. Verifique el TTL predeterminado y la lógica de actualización de caché
2. También deberíamos estimar el número de nuevas entradas y la proporción de aciertos de caché al agregar un caché
3. Qué sucede en caso de un error del caché
4. En caso de un nuevo clúster de caché, si existe conectividad entre el servidor y la instancia de caché
5. Métricas para la proporción de aciertos de caché
6. Una estimación de la cantidad de claves de caché, el tamaño promedio del valor y asegurarse de que Infra tenga suficiente capacidad.

1. Compruebe si hay un índice correcto en la base de datos para la nueva consulta
2. En el caso de una nueva base de datos, ya sea que exista conectividad o no
3. Política de depuración de tablas, para evitar tablas grandes con el tiempo, en caso de inserciones de datos
4. Métricas para las nuevas consultas

1. Eliminar los cambios de espacios en blanco de la solicitud de extracción
   ¿Cómo? Puedes referirte a esto
2. Si no estoy al tanto del requisito, generalmente verifico la tarea o me sincronizo con el desarrollador una vez para comprender el requisito.
3. Abra la solicitud de extracción en GitHub/BitBucket y el editor de código local simultáneamente.
   Tener el código localmente tiene múltiples ventajas:
   - Puede usar herramientas de escaneo de código estático para encontrar algunos de los problemas comunes
   - La navegación por el código es mucho más fácil
   - Si es necesario, puede ejecutar el código para ver cómo se comporta
4. Comience desde el punto en el que se ve afectado el flujo de negocios y luego revise el código desde allí. Cada vez que me muevo a un archivo diferente, verifico si ese archivo ha cambiado o no en la solicitud de extracción en Github.
5. En caso de cualquier problema, agregue ese comentario en GitHub mientras menciona qué debe cambiarse y por qué. Junto con algún material de referencia.
6. En caso de que haya terminado de revisar un archivo, márquelo como visto, para que también obtenga claridad sobre el progreso de la revisión y también pueda evitar el archivo durante la segunda revisión del código (si no hay cambios)
7. Si los cambios en la diferencia son pequeños, lo reviso de una vez. De lo contrario, divido la revisión en pequeñas fases. Esto garantiza que la calidad de la revisión no se vea afectada. En general, lo que sucede es que, si la diferencia es grande, después de un punto, comenzamos a aceptar los cambios sin pensar mucho en ellos.

Espero que haya al menos una cosa que hayas aprendido de esto. En caso afirmativo, vote a favor y también mencione los puntos que podría haber pasado por alto. Los agregaré a la publicación también.

¡Saludos y feliz revisión!