Criterios y Guía para Revisiones de Código (en proyectos con React)

Empezá con la mentalidad adecuada

Antes de revisar el código, tené en cuenta estos valores fundamentales:

🎯 Propósito ante todo

Entendé qué busca lograr el PR antes de revisar cómo está implementado.

🤝 Feedback respetuoso

El objetivo es mejorar el código, no criticar a quien lo escribió. Concentrate en el trabajo, asumí buenas intenciones y usá un lenguaje amable y colaborativo.

🧼 Simple antes que ingenioso

El código debe ser fácil de leer, mantener y actualizar, incluso si eso implica evitar “trucos” complejos.

📏 La consistencia importa

Seguí las convenciones del proyecto: estructura de carpetas, nombres de archivos, estilos de capitalización y patrones de código. Reutilizá componentes o librerías internas siempre que sea posible.

🌱 Fomentá el crecimiento del equipo

Ayudá al crecimiento del equipo ofreciendo sugerencias constructivas, no solo correcciones.

🧾 La receta para una buena revisión de código – Paso a paso

1. Entendé el PR

• ¿El título y la descripción son claros?
• ¿Se entiende el objetivo? (Ej.: corregir un bug, agregar funcionalidad, mejorar rendimiento)
• ¿Incluye links a tickets, issues o diseños?

📌 Tip: Si el PR incluye refactors no relacionados o demasiados cambios, sugerí dividirlo en PRs más pequeños para facilitar la revisión.

2. Probá el código (si podés)

• ¿Probaste la rama localmente?
• ¿Funciona como se espera?
• ¿Hay efectos secundarios o regresiones?

⚠️ Un efecto secundario es un cambio inesperado. Una regresión es cuando algo que antes funcionaba ahora se rompe.

3. Revisá estructura y lógica

• ¿La lógica está dividida en partes pequeñas y testeables?
• ¿Hay componentes o funciones demasiado grandes?
• ¿Se siguen buenas prácticas de React?

4. Buscá reutilización y patrones

• ¿Hay lógica duplicada innecesaria?
• ¿Se puede extraer algo a un hook o componente reutilizable?
• ¿Se respetan los patrones arquitectónicos del proyecto?

Ejemplos:

• Estado manejado de forma consistente (Context, Redux, Zustand, etc.)
• Lógica de negocio fuera de los componentes
• Fetch de datos aislado en hooks o servicios

5. Mantenibilidad y legibilidad

• ¿El código se explica por sí solo?
• ¿Los nombres de funciones y variables son claros?
• ¿Hay código muerto, TODOs o líneas comentadas sin sentido?

🔧 Tip: Usá herramientas de CI como ESLint y Prettier para detectar problemas automáticamente.

6. Buenas prácticas y rendimiento

• ¿Se minimizan los re-renders?
• ¿Hooks como useEffect, useMemo y useCallback se usan correctamente?
• ¿El estado está bien ubicado (local vs. global)?

💡 Datos eficientes = mejor rendimiento

• Usar react-query, SWR o hooks personalizados
• Evitar fetchs redundantes
• Hacer fetchs condicionales
• Cancelar requests cuando el componente se desmonta
• Manejar bien loading y error

7. Seguridad y casos límite

• ¿Se validan entradas del usuario?
• ¿Se maneja información sensible de forma segura?
• ¿Se contemplan estados como null, undefined, errores, cargas?

8. Verificá la cobertura de tests

• ¿Hay tests unitarios o de integración?
• ¿Cubren tanto casos felices como casos límite?
• ¿Los tests pasan localmente?

9. Estilo y formato de código

• ¿Se usa Prettier, ESLint o herramientas similares?
• ¿Los estilos son consistentes? (comillas, punto y coma, indentación)

10. Feedback respetuoso y accionable

En lugar de decir:

“Esto está mal.”

✅ Mejor:

“¿Te parece si probamos este enfoque?”

En lugar de decir:

“¿Por qué hiciste esto así?”

✅ Probá con:

“Tengo curiosidad—¿cuál fue tu razonamiento acá?”

En lugar de decir:

“Esto no tiene sentido.”

✅ Decí:

“¿Te parece si lo hacemos más legible o agregamos un comentario?”

En lugar de:

“Arreglá esto.”

✅ Usá:

“¿Qué pensás de extraer esto a una función helper?”

🎉 Cerrá con un mensaje positivo

“Buen trabajo en general—solo faltan algunos detalles y ya queda listo.”