La guía de revisión de código.

Las revisiones de código son una práctica común en la industria tecnológica. Cuando haces un Pull Request / Merge Request, alguien tiene que revisar, dar comentarios y aprobar cuando esté listo para ser parte de la rama maestra, si esa es la rama a la que se dirige el RP, por supuesto.

Cuando es la primera vez que eres revisor, tal vez ya hayas aprendido un poco de los comentarios que has recibido. No tengas miedo, no es gran cosa. Las revisiones de código también se hacen para aprender. No estás atacando a tus compañeros de equipo, no es algo personal. Estás cuestionando su código, buscando cómo mejorarlo.

Recuerda que las revisiones de código no solo sirven para ver qué está mal, sino también para aprender de los demás.

Con esta mentalidad, veamos cómo hacerlo:

Tener contexto‍

Cada RP tiene un propósito. Podría ser parte de una propuesta, una corrección de errores, una nueva característica, etc. Asegúrate de leer y comprender el título del PR antes de mirar el código. Esto te dará una mejor imagen de lo que va a revisar, y puedes ayudarte mirando qué archivos se modificaron para darle más contexto de su alcance.

Asegúrate de que los archivos modificados sean parte de lo que se supone que debe hacer el RP (tal vez de repente cargó un archivo por error)

También puedes leer: Habilidades blandas que no son tan blandas

Ok, ya sabemos lo que se supone que debe hacer el PR. Veamos el código. Puedes revisarlo mediante dos enfoques: legibilidad y funcionalidad.

Independientemente del enfoque que elijas, ten siempre en cuenta estas dos preguntas:

• ¿Cómo podría mejorar eso?
• ¿Qué puede salir mal?‍

‍Revisión por legibilidad

Quizás esta sea la forma más superficial de comenzar a revisarlo, pero asegura que el código se mantenga fácilmente a lo largo del tiempo. Si no puede entender ese código ahora, en un año tampoco lo obtendrá.

Cada código que escribes tiene un precio: mantenimiento. Hazle un favor a los demás y compruébalo con cuidado.

Estas son algunas de las cosas que puedes revisar:

• Busca errores tipográficos, ocurren todo el tiempo, en los nombres de las variables y funciones, en las descripciones de los comentarios o incluso en los nombres de los archivos.
• Que la clase y las funciones están bien nombradas. La responsabilidad de la función va según el nombre.
• Comentarios descriptivos y bien redactados. Esto no quiere decir que deba ser largo, debe ser asertivo.
• Consistencia. El código no está escrito como una pieza aislada en el repositorio. Asegúrate de que sea coherente con las prácticas. Intenta asegurarte de que el código que estás revisando esté en consonancia con el resto.

Por ejemplo, sucede con este tipo de casos:

Ve que todo el código tenga armonía y que la pieza que vayas a agregar no haga ruido.

• No imprimir declaraciones. Quizás lo olvidaron mientras depuraban.
• Evita declaraciones anidadas innecesarias.
• Retorna el feedback lo más rápido que pueda

Si ves un código como este:

 

Puedes refactorizar haciendo esto:

Sugiere todo lo que creas necesario para que se comprenda mejor el código.

Revisión por funcionalidad

Como revisor, también eres responsable de la calidad del código que la empresa envía a producción. Presta atención a los detalles, la escalabilidad y especialmente la seguridad.

• ¿Tiene sentido el flujo?
• ¿Hay validaciones innecesarias, bucles, o algún otro detalle?
• Responsabilidad única de métodos y clases. Entonces, las pruebas pueden ser más atómicas.
• ¿Es susceptible de fallar? Por ejemplo, asegúrate de comprobar la longitud de la matriz antes de acceder a ella. O al menos asegurarse de que no terminará en un error -NullPointer alert-
• ¿Cómo lo hubiera hecho? ¿Es mejor a mi manera? ¿Podría esa lógica mejorar la actual?
• Las pruebas no cambian sin una razón. Por ejemplo, si la prueba se usó para validar que la función no arroja un error, pero luego valida que la función arroja un error, pregunta por qué. Quizás haya cambios importantes que afecten la operación.
• No elimine pruebas sin un motivo. Pregunte por qué si no entiende por qué se eliminó la prueba. ¿Ya no es necesario? ¿Por qué?
• Las pruebas son suficientes para cumplir con el impacto del cambio. Y también, revisa que las pruebas estén afirmando lo que deberían.

¿Qué debo hacer si no conozco el idioma del código?

Este es un clásico. No conoces un determinado lenguaje o tecnología de codificación y debes revisarlo.

Primero, no tengas miedo. Asegúrate de que los otros revisores sepan el idioma porque pueden detectar cosas que tú no podrás. Y pregúntales si es necesario.

Un buen punto de partida es la revisión superficial: busca errores tipográficos y nombres de variables.

Si lo deseas, puedes buscar otro código en el repositorio del mismo idioma e intentar descubrir patrones. Recuerda que puedes preguntar si algo no está claro.

También puedes leer: Bienvenidos al mundo de los algoritmos

Y el consejo más importante: no siga las "Prácticas recomendadas" a ciegas. Piensa siempre primero. Cada fragmento de código intenta agregar valor al producto. Piensa en cómo podría agregar valor y facilitarle la vida al desarrollador que mantendrá ese código más adelante, tal vez sea tu.