Cómo hacer una GRAN code review

Hola, fellow dev 👋

Es innegable que las code reviews son una de las prácticas más valiosas en el desarrollo de software.

Una buena code review detecta errores antes de que lleguen a producción, mejora la calidad del código y ayuda a los miembros del equipo a aprender unos de otros.

Por otro lado, una mala code review hace perder tiempo al equipo y pasa por alto problemas críticos.

Como Reviewer, uno de los principales desafíos es saber en qué centrarse.

Al enfrentarte a un pull request con muchos cambios, es fácil fijarte en aspectos secundarios.

¿Debes dedicar tiempo a revisar la sintaxis?

¿Buscar posibles errores?

¿Centrarte en el estilo del código?

🤔 Todo esto es importante, pero en el orden de prioridades adecuado.

Tener un enfoque estructurado (en lugar de escanear aleatoriamente los cambios) hace que el proceso sea más eficaz y eficiente.

👉 Es por ello que hoy quiero detallar las áreas clave en las que debes centrarte durante tus Code Reviews, comenzando por las consideraciones más importantes y terminando por los detalles.

​

1. Consideraciones de diseño

Este es el aspecto más importante de una revisión de código, porque los problemas de diseño son los más difíciles y caros de arreglar más adelante.

En este paso, básicamente debes averiguar si los cambios propuestos mejoran o empeoran el sistema en su conjunto.

Cuando compruebas si el código está bien diseñado para el sistema, debes ir más allá de la utilidad inmediata y ver cómo encaja el cambio en la arquitectura general.

¿Sigue ese código los patrones existentes del proyecto?

¿Introduce conceptos que chocan con abstracciones ya establecidas?

Un buen cambio debe integrarse con el sistema actual, en lugar de sentirse como un nuevo parche.

El código que modifica elementos de la interfaz de usuario no debe ir en la capa de acceso a los datos.

La lógica de negocio no debería dispersarse en clases de utilidad.

Pregúntate: ¿Un nuevo desarrollador sabría dónde buscar para cambiar esta funcionalidad dentro de seis meses?

Si la respuesta es no, es posible que el código esté en el lugar equivocado.

​

2. Revisión de funcionalidad

El siguiente paso es verificar si el código funciona como debería.

Esto implica buscar errores que las pruebas automatizadas puedan pasar por alto y pensar en qué podría fallar.

Primero, averigua qué pretendía el desarrollador que hiciera el código.

¿Se cumple ese objetivo?

La implementación no siempre coincide con la intención inicial, o puede acarrear efectos secundarios no previstos.

Lee el código y comprueba que todo encaje.

Las "fugas de recursos" son otro problema común.

¿El código cierra correctamente archivos, conexiones de base de datos o sockets?

¿Hay alguna situación en la que una excepción impida ejecutar el código de limpieza?

Estos problemas a menudo no muestran ningún síntoma hasta que el sistema está bajo presión.

Por último, considera si necesitas validar el comportamiento del código tú mism@.

Si el cambio afecta a la funcionalidad de cara al usuario, especialmente cambios en la interfaz, suele valer la pena pedir una demostración o probar la función tú mism@.

No siempre basta con leer el código para entender cómo funciona algo.

​

3. Complejidad

El código complejo es caro. Es más difícil de cambiar de forma segura, lleva más tiempo entenderlo y es más propenso a errores.

La pregunta clave es si otro Developer podría entender y modificar fácilmente este código. Si tú no puedes seguir la lógica durante la revisión, otros también tendrán dificultades después.

Por ejemplo, si una única función gestiona validación de entrada, consultas a la base de datos y envío de correos electrónicos a la vez está violando el principio de responsabilidad única, y resulta difícil de probar y mantener.

La sobreingeniería también es un tipo de complejidad a vigilar.

Un ejemplo típico es crear clases abstractas e interfaces para algo que tiene una sola implementación, y no muestra una necesidad clara de múltiples por el momento.

Cuando abstraes demasiado pronto, a menudo obtienes la abstracción equivocada, algo más difícil de usar que no tener ninguna abstracción.

​

4. Calidad de los Tests

Los Tests son parte integral del código y requieren el mismo nivel de atención en las revisiones.

Los buenos tests detectan errores y dan confianza al hacer cambios.

Los malos tests hacen perder el tiempo y crean una falsa sensación de seguridad.

Primero, comprueba si se han incluido los tipos de tests adecuados.

¿Los cambios necesitan pruebas de unidad, de integración o end-to-end?

Las pruebas siempre deberían ir en el mismo pull request, a menos que se trate de una emergencia.

Comprueba si los tests verifican realmente lo que deben verificar.

🤔 ¿Fallarían si el código estuviera roto?

Es sorprendentemente común ver tests que siempre pasan, incluso cuando el código tiene errores graves.

Analiza la lógica de los tests mentalmente y asegúrate de que validan el comportamiento que dicen validar.

Por ejemplo, un test que comprueba doce cosas distintas en un solo método es difícil de entender cuando falla.

Cada test debe centrarse en un comportamiento específico e indicar claramente qué es lo que ha fallado si no pasa.

💡 Recuerda que los buenos tests se fijan en el comportamiento y los resultados, no en pasos de ejecución concretos.

​

5. Nombres y documentación

Una buena nomenclatura hace que el código se documente por sí mismo.

Una mala nomenclatura obliga a los lectores a buscar detalles internos para entender qué hace una parte del código.

Busca nombres que comuniquen lo que algo es o hace.

Una variable llamada data o info no transmitirá nada útil.

Por el contrario, una variable llamada "userAccountBalance" será más clara.

Los nombres no deben ser ni demasiado largos ni demasiado cortos.

Asegúrate de que sigan las reglas establecidas por tu equipo.

El código nuevo no debería usar snake_case si el resto del código usa camelCase.

¡El código es fácil de leer cuando es coherente!

Al leer comentarios, comprueba si explican el “por qué”, no el “qué”.

Los comentarios que repiten lo que ya dice el código son inútiles.

Los que explican la razón de una decisión sí aportan valor.

Si necesitas un párrafo para explicar lo que hacen cinco líneas de código, esas cinco líneas deberían simplificarse o dividirse en partes más claras.

💡 No olvides la documentación externa al código: si el cambio afecta cómo se construye, prueba o despliega el sistema, asegúrate de actualizar la documentación.

​

6. Estilo

El estilo importa porque influye en la rapidez con que los desarrolladores pueden leer y comprender el código.

Cuando el código sigue patrones coherentes, los desarrolladores no tienen que descifrar el formato y pueden concentrarse en la lógica.

Comprueba que el código sigue la guía de estilo de tu equipo.

Si quieres sugerir una mejora de estilo que no cubre la guía, márcala como un “nit” para indicar que no es obligatoria.

No bloquees un pull request por preferir un formato distinto. Los gustos personales no deben impedir avanzar.

Espero que esta guía te haya aportado claridad y una guía paso a paso que seguir en tus futuras pull request.

​

Así que por último recuerda siempre, ¡busca la excelencia en todo lo que hagas!

La vida es demasiado corta como para no conocer la mejor versión que podrías alcanzar.

- Patri

​

P.D. cuando estés list@, así es como te puedo ayudar...

En mi Programa DevAccelerator™, ayudamos a Software y Data Engineers a trabajar en entornos internacionales y acelerar su carrera profesional. - ​​Únete a nuestra lista de espera aquí.​

​