Bienvenidos a esta Guía de Code Review. Comparte este articulo y síguenos para recibir más guías y cursos.
Para saber más comente a continuación, respondemos todos y cada uno de los comentarios.
¿Te gustaría enterarte de cuando lanzamos descuentos y nuevos cursos?
Dentro de lo que es el mundo de la programación, es un estándar de cada profesional, intentar aplicar buenas prácticas en su trabajo. Hay variadas, pero hoy hablaremos de una que no a todos les gusta realizar: Code Review o Revisión de código.
¿Qué es el Code Review?
Como (por ahora), todos los que escriben código son personas, cometer errores es normal y, de hecho, forma parte del proceso sano y creativo. Para corregir estos errores, se suelen usar una serie de pruebas manuales o automáticas para lidiar con esos defectos. Pero a veces, corremos el riesgo de que nosotros mismos no podamos notarlo fácilmente.
Para eso, se utilizan estas prácticas colaborativas de revisión de código. Es normal que ocurran de manera más frecuente en empresas agiles, con una clara inclinación al trabajo en equipo y equipos organizados. Pero ¿en qué consisten? ¿Cómo benefician a los profesionales y a las empresas?
Cómo se realiza
Dentro de equipos colaborativos, es normal utilizar sistemas de control de versiones. Esto permite diversas configuraciones. Una de las más usadas es usar un archivo como principal, mientras que los demás colaboradores trabajaran en versiones derivadas del mismo, pero sin que los cambios afecten directamente al principal.
Una vez que el programador concluyo su parte, envía esa porción del código a la guía principal pendiente de revisión. Antes de que esta modificación o adición sea agregada de manera definitiva al principal, pasara por una revisión de código para evitar errores.
Ocurre igual cuando se busca una versión nueva del software, se evitan realizar cambios directos a “producción”, dejando la nueva versión creada pendiente y permitiendo al examinador evaluar los cambios entre cada versión.
La más usada es la denominada “revisión entre pares”, donde una persona con habilidades técnicas y experiencia normalmente mayor al programador, revisa el código. Se evalúan normalmente 5 aspectos:
- Requerimientos alcanzados: la lista de objetivos funcionales solicitados debería haberse llevado a cabo de manera exitosa.
- Código correcto: se evalúa que el código, variables, patrones, case o nomenclaturas concuerden con lo esperado, de acuerdo al lenguaje que se está utilizando
- Arquitectura y lógica: se busca cierta fluidez en el código, que trate de mantener el conjunto de “buenas prácticas” respetando los estándares planteados por la organización, sobre todo enfocándose en que en ocasiones se suele usar porciones de código extraídas de otros sitios
- Reacción a errores: acá se piensa un poco más como un usuario del futuro producto, intentando ver cómo se comporta el programa si se ingresaran parámetros distintos a los planteados (por ejemplo, un formulario donde se solicita un numero de celular y el usuario decide poner letras)
- Optimización de código: dentro de los lenguajes, en ocasiones se pueden usar prácticas variadas orientadas a mejorar la velocidad, funcionalidad o seguridad del código. Un desarrollador más experimentado, probablemente posea más experiencia en determinada situación y pueda brindar maneras alternativas y mejores de resolver una situación puntual
¿Aporta beneficios?
Cuando inicialmente se plantean solicitudes de revisión de código, la primera traba que se suele poner es: “pero nos demandara demasiado tiempo y ya estamos atrasados”.
Acá hay dos conceptos que tenemos que recordar: primero, hay que intentar arreglar las cosas ANTES de que se rompan, y el tiempo “perdido” arreglando algo ahora, es mucho menos del tiempo (y recursos) que se gastarán cuando las fallas sean demasiadas o múltiples usuarios de un producto ya publicado, afronten problemas.
Desde Agile como forma de trabajar, cuando los equipos son auto organizados y tienen la libertad de decir el “COMO” realizar algo, los tiempos y circunstancias sobre cuando realizaran este tipo de revisiones surgen de manera autónoma, lo que produce mejores resultados.
A pesar de que, en circunstancias puntuales, se recurre a utilizar un código con errores o en circunstancias no óptimas, la mayoría de las veces las revisiones de código se dan con frecuencia, permitiendo que el producto final salga en mejores condiciones y con menos probables errores desde su lanzamiento.
Por otro lado, el reto de tener que ponerse a leer y revisar un código ajeno, permite aumentar las habilidades de desarrollo y potenciar las habilidades analíticas y de resolución de problemas. También, beneficia al equipo en general, dado que aumenta el nivel de habilidades y de excelencia técnica que todos los miembros irán desarrollando a lo largo de los proyectos en los que participen.
Esto también permite potenciar la lógica de los programadores, y potenciar sus habilidades de entender requerimientos. Seamos honestos, no siempre tendremos los objetivos a cumplir con lujo de detalles. Para eso, a través de la revisión de código se potencia la comunicación entre miembros del equipo, lo que lograría analizar de manera interna los distintos requisitos a cumplir.
Ser code reviewer no es solo una tarea técnica, es una responsabilidad clave para mantener la calidad del software y garantizar que el código que llega a producción sea eficiente, limpio y seguro. Un buen code reviewer no busca simplemente señalar errores, sino guiar al equipo hacia mejores prácticas y un estándar de excelencia continua. La revisión de código es una oportunidad para aprender, compartir conocimiento y evitar que pequeños descuidos se conviertan en problemas graves más adelante.
La mentalidad del code reviewer
La primera regla del code review es entender que no se trata de criticar al desarrollador, sino de mejorar el código. Mantener una actitud constructiva es esencial. Los comentarios deben enfocarse en el código, no en la persona. En lugar de decir «Esto está mal», es mejor usar frases como «¿Qué te parece si intentamos esta otra forma? Creo que podría mejorar la legibilidad».
Un code reviewer debe tener en mente el propósito del cambio. Antes de entrar a revisar línea por línea, es importante leer el ticket o la historia de usuario asociada y entender el contexto y la intención del cambio. ¿El objetivo es optimizar rendimiento? ¿Corregir un bug crítico? ¿Agregar una nueva funcionalidad? Esta visión general ayuda a hacer observaciones más relevantes.
Revisión de la legibilidad y claridad
Un buen código no solo funciona, sino que es fácil de leer y entender. Si el reviewer encuentra un bloque de código confuso o difícil de seguir, incluso si técnicamente está bien, debe señalarlo. La legibilidad es una inversión: el código claro se mantiene con menos esfuerzo y es menos propenso a errores en el futuro.
Por ejemplo, si una función tiene demasiados parámetros o su nombre no refleja claramente lo que hace, es una señal de alerta.
pythonCopiar códigodef procesar(a, b, c, d):
return a + b * c / d
En lugar de dejar pasar esto, un reviewer debería sugerir algo como:
pythonCopiar códigodef calcular_descuento(precio, descuento, impuestos):
return precio - (precio * descuento) + impuestos
Los nombres descriptivos y los métodos bien segmentados hacen que otros desarrolladores puedan entender la lógica sin esfuerzo.
Consistencia en el estilo y las convenciones
El code reviewer debe asegurarse de que el código sigue las convenciones establecidas en el proyecto. Si el equipo ha decidido usar snake_case para variables y funciones, cualquier desviación debe ser señalada. Mantener la consistencia evita que el código se sienta como una mezcla caótica de diferentes estilos.
Las herramientas de análisis estático como ESLint, Pylint o Prettier pueden automatizar parte de este trabajo, pero el reviewer debe estar atento a patrones más complejos que no siempre se detectan automáticamente.
Detección de duplicidad y refactorización
El reviewer debe tener buen ojo para identificar duplicidad de código. Si ve fragmentos que parecen repetirse en diferentes partes del proyecto, es momento de sugerir una refactorización para encapsular esa lógica en una función o clase reutilizable. El principio DRY («Don’t Repeat Yourself») es crucial en cualquier proyecto grande.
Por ejemplo:
pythonCopiar códigodef calcular_total(productos):
total = 0
for producto in productos:
total += producto['precio'] * producto['cantidad']
return total
def calcular_subtotal(productos):
subtotal = 0
for producto in productos:
subtotal += producto['precio'] * producto['cantidad']
return subtotal
El reviewer podría sugerir:
pythonCopiar códigodef calcular_monto(productos):
return sum(producto['precio'] * producto['cantidad'] for producto in productos)
Este tipo de sugerencias no solo optimizan el código, sino que reducen errores futuros.
Evaluación del rendimiento y la eficiencia
Aunque el código esté bien estructurado, el reviewer debe analizar si existen maneras más eficientes de lograr el mismo resultado. Algoritmos ineficientes o estructuras de datos mal elegidas pueden generar cuellos de botella. Un reviewer experimentado propondrá mejoras cuando detecte estas situaciones.
Por ejemplo:
pythonCopiar códigofor i in range(len(lista)):
if lista[i] == valor:
return True
Esto puede optimizarse usando:
pythonCopiar códigoif valor in lista:
return True
A simple vista puede parecer un cambio menor, pero este tipo de optimizaciones tienen un impacto notable en escalabilidad y rendimiento.
Seguridad y validación de datos
El code reviewer debe ser paranoico con la seguridad. Si el código manipula datos sensibles, interactúa con APIs externas o realiza operaciones críticas, es su responsabilidad garantizar que haya validación de datos y manejo adecuado de excepciones.
Por ejemplo, si se detecta que el código acepta parámetros de entrada directamente de un formulario sin sanitización, debe señalarlo de inmediato:
pythonCopiar códigonombre_usuario = request.GET['usuario']
Y sugerir algo más seguro:
pythonCopiar códigonombre_usuario = sanitize_input(request.GET['usuario'])
Este tipo de revisiones previenen ataques como SQL Injection, XSS o inyección de comandos.
Pruebas y cobertura de código
Un buen reviewer nunca acepta código sin pruebas. La cobertura de pruebas (tests unitarios, de integración y funcionales) debe ser parte de los criterios de aceptación. Si un cambio introduce nueva lógica pero no incluye tests, es una señal de advertencia.
El reviewer debe preguntar:
- ¿Hay pruebas que validen los nuevos caminos del código?
- ¿Qué pasa si la entrada es inesperada o incorrecta?
- ¿Las pruebas cubren casos extremos o límites?
Si no hay suficientes tests, el reviewer debe pedir al desarrollador que agregue más antes de aprobar el cambio.
Feedback constructivo y educativo
El objetivo no es imponer autoridad, sino educar. Un buen reviewer explica por qué algo necesita cambiar, proporcionando ejemplos o referencias. Es una oportunidad para que el equipo crezca. Un comentario útil podría verse así:
«Esta función podría beneficiarse de la refactorización porque actualmente viola el principio de responsabilidad única. ¿Qué te parece dividirla en dos funciones más pequeñas para que cada una tenga una sola responsabilidad?»
Los code reviews no son trámites burocráticos, sino pilares de calidad. Cuando se hacen bien, no solo evitan bugs y mejoran el código, sino que fortalecen al equipo, promueven la colaboración y crean software robusto que resiste el paso del tiempo.
Más allá de la programación
Trabajar con Agile no se trata solo de seguir un conjunto de ceremonias y marcos, sino de adoptar una mentalidad que promueva la colaboración, la adaptabilidad y la entrega continua de valor. Las buenas prácticas en Agile garantizan que el equipo no solo cumpla con las expectativas, sino que también evolucione y mejore constantemente. El objetivo final es responder al cambio rápidamente, sin sacrificar calidad o perder de vista las necesidades del cliente.
Comunicación constante y transparente
En Agile, la comunicación es el eje central. Las reuniones diarias (daily stand-ups) no son solo un ritual, sino una herramienta clave para mantener sincronizado al equipo. Durante estas reuniones, es importante que cada miembro comparta lo que está haciendo, los obstáculos que enfrenta y qué planea hacer a continuación. Sin embargo, para que realmente aporten valor, deben ser breves y enfocadas. Si las stand-ups se extienden o derivan en debates técnicos, es una señal de que algo está fallando.
La transparencia va más allá de las reuniones. Todo el equipo debe tener visibilidad sobre el progreso del sprint, los bloqueos y las prioridades. Tableros de herramientas como Jira o Trello deben mantenerse actualizados. Un tablero que refleja fielmente el estado del trabajo permite tomar decisiones rápidas y ajustar el rumbo si es necesario.
Priorización basada en valor
No todo el trabajo tiene el mismo impacto. Una buena práctica en Agile es priorizar las tareas según el valor que aportan al cliente. El Product Owner juega un rol fundamental aquí, pero el equipo también debe involucrarse activamente. Si algo no añade valor o no resuelve un problema inmediato, probablemente deba ser pospuesto.
El uso de técnicas como MoSCoW (Must have, Should have, Could have, Won’t have) o la planificación basada en valor de negocio ayuda a tomar decisiones más informadas. El backlog debe ser tratado como un ente vivo, ajustándose constantemente a medida que cambian las necesidades del cliente o surgen nuevas oportunidades.
Iteraciones cortas y entregables funcionales
Uno de los pilares de Agile es la entrega continua de software funcional. Los sprints cortos, de una a cuatro semanas, permiten entregar incrementos que pueden ser probados y utilizados. La clave aquí es que cada incremento debe estar en un estado «listo para producción». Evita acumular trabajo que no llega a ser entregable.
Si al final del sprint hay tareas que no están terminadas, no deben arrastrarse al próximo sin una evaluación crítica. Quizá fue un problema de estimación o surgieron imprevistos. Lo importante es aprender de esto y ajustar la planificación futura.
Retrospectivas efectivas
Las retrospectivas no deben convertirse en sesiones de quejas sin rumbo. Deben ser espacios de mejora continua, donde el equipo identifica qué funcionó, qué no y qué acciones tomarán en el próximo sprint.
Una buena práctica es centrarse en acciones concretas. Si en la retrospectiva se menciona que las pruebas automáticas tardan demasiado, la acción no debería quedarse en “mejorar el proceso de pruebas”. Debe ser algo específico y asignado, como «Reducir el tiempo de ejecución de las pruebas de integración en un 20% durante el próximo sprint».
Feedback temprano y frecuente
Agile promueve la obtención de feedback constante, tanto del cliente como de los usuarios finales. Esperar a que el producto esté completo para recibir comentarios puede ser catastrófico. Las demostraciones de sprint (sprint reviews) permiten al equipo mostrar avances y obtener retroalimentación directamente de los stakeholders.
Este proceso evita malentendidos y asegura que el producto evoluciona en la dirección correcta. Además, el feedback temprano permite corregir errores de concepto antes de que se conviertan en problemas costosos.
Colaboración con el cliente
Agile rompe con la idea de que el cliente entrega requisitos y desaparece hasta el final del proyecto. La colaboración activa y continua es clave para asegurar que el producto se alinee con las expectativas del cliente.
El Product Owner debe estar en constante comunicación con los stakeholders, traduciendo sus necesidades al backlog y priorizando lo que realmente importa. Sin embargo, es fundamental evitar que el cliente caiga en micromanagement. El equipo necesita autonomía para decidir cómo implementar las soluciones.
Adaptabilidad y flexibilidad
El cambio no es un enemigo en Agile, es parte del proceso. Si un cliente solicita modificaciones, el equipo debe estar preparado para ajustar el plan sin resistencia. Los sprints están diseñados para ser períodos cortos donde se entrega valor, pero al final de cada iteración, es posible revaluar prioridades y cambiar de rumbo si es necesario.
La clave está en mantener un equilibrio. No significa aceptar cambios constantes que desmoronen cualquier planificación, sino encontrar una vía que permita adaptarse sin perder productividad.
Automatización y CI/CD
La integración continua y la entrega continua (CI/CD) son aliados naturales de Agile. Automatizar las pruebas y los despliegues permite que el equipo entregue software con rapidez y confianza.
Un pipeline de CI/CD bien implementado significa que cada vez que un desarrollador hace un commit, las pruebas se ejecutan automáticamente y el código puede ser desplegado en entornos de staging o producción. Esto reduce la fricción y permite entregas más frecuentes, alineadas con el enfoque iterativo de Agile.
Equipos autoorganizados y multidisciplinarios
En Agile, los equipos no dependen de un líder que dicte cada paso. La autoorganización permite que cada miembro tome decisiones y asuma responsabilidad sobre su trabajo. Esto fomenta la creatividad, la autonomía y el sentido de pertenencia.
Además, los equipos deben ser multidisciplinarios, integrando desarrolladores, testers, diseñadores y cualquier otro rol necesario para completar el trabajo. La diversidad de habilidades acelera el proceso y evita cuellos de botella.
Las buenas prácticas en Agile no se limitan a seguir un manual. Se trata de construir una cultura donde el equipo esté siempre en busca de mejorar, aprendiendo de sus errores y evolucionando con cada iteración. Es una forma de trabajo que, cuando se adopta bien, transforma no solo el software que se desarrolla, sino también la forma en que se construyen relaciones y se entrega valor real al cliente.
Consideraciones finales
Recuerda, siempre que la revisión de condigo forma parte de un ciclo de búsqueda de excelencia técnica de manera permanente. Algunas sugerencias finales relacionadas a esta excelente practica:
- Si eres el revisor: recuerda que es normal estar a la defensiva cuando estamos en una “evaluación”. Se amable con tu manera de hablar, trata de ser objetivo y no hacer comentarios agresivos, humillantes o que generen malestar. Recuerda que todos cometemos errores y que las falencias en los programas no significan que tu compañero sea incompetente.
- Si eres el revisado: no tomes a título personal las sugerencias o correcciones que te hagan. Velas como una oportunidad única que puede potenciar tus habilidades a futuro. Si tienes la oportunidad, solicita correcciones cada “poco” contenido. No sobrecargues a tu revisor con múltiples archivos, mientras menos cosas, más a fondo se puede analizar.
¿Qué opinas de la revisión de código? ¿la utilizas con frecuencia? Déjame tus comentarios en mis canales