Checklist de Revisión de Código
Una checklist estructurada ayuda a realizar revisiones de código de manera consistente y eficiente. Este artículo proporciona una checklist exhaustiva para todos los aspectos de un Pull Request.
En pocas palabras
Checklist de revisión de código: revisa la lógica, seguridad, rendimiento, tests, documentación y arquitectura. Pull Requests pequeños, descripciones claras y retroalimentación constructiva son clave para el éxito.
Descripción técnica
Las checklists de revisión de código son listas estructuradas de puntos de control que garantizan un examen sistemático de todos los aspectos relevantes de un Pull Request. Ayudan a los revisores a mantener una calidad consistente y a los autores a concentrarse en los puntos más importantes. Una buena checklist cubre corrección funcional, seguridad, rendimiento, cobertura de tests, documentación y arquitectura.
La checklist
1. Descripción y contexto del PR
- Descripción clara: ¿Qué cambió y por qué?
- Referencia a ticket: Issue/tarea enlazada
- Estrategia de prueba: ¿Cómo se probó?
- Screenshots: Presentes para cambios de UI
- Breaking changes: ¿Están documentados?
2. Lógica y funcionalidad
- Corrección: ¿Hace el código lo que debe hacer?
- Casos límite: Manejan situaciones extremas y errores
- Manejo de errores: Las excepciones se tratan correctamente
- Validación: Se validan las entradas
- Limpieza de recursos: Se cierran archivos y conexiones
3. Seguridad
- SQL Injection: Se usan queries parametrizadas
- XSS: Las entradas de usuario se escapan
- Autenticación: Solo acceso autorizado
- Datos sensibles: Sin secrets en el código
- Validación de entrada: Todas las entradas validadas
4. Rendimiento
- Queries de base de datos: Se evita el problema N+1
- Caching: Se usa caching donde tiene sentido
- Algoritmo: Se eligió algoritmo eficiente
- Memory leaks: Sin fugas de memoria
- Operaciones asincrónicas: I/O no bloqueante
5. Estilo de código y legibilidad
- Nombres: Variables y funciones con nombres significativos
- Funciones: Pequeñas, una responsabilidad
- Comentarios: Solo para el PORQUÉ, no el QUÉ
- Duplicación: Se respeta DRY
- Linter: Sin errores del linter
6. Tests
- Unit Tests: Se prueban los cambios lógicos
- Integration Tests: Se prueban los endpoints de API
- Casos límite: Tests para situaciones extremas
- Cobertura: Cobertura de tests suficiente
- Flaky Tests: Sin tests inestables
7. Documentación
- README: Se actualizó cuando es necesario
- API-Docs: Se documentan los cambios en la API
- Inline-Docs: Se documentan las funciones complejas
- Changelog: Se actualizó el changelog
- Migration Guide: Se documentan los breaking changes
8. Arquitectura y diseño
- SOLID: Se respetan los principios
- Cohesión: Lo que va junto está en un módulo
- Acoplamiento: Acoplamiento débil entre módulos
- Abstracción: Nivel correcto de abstracción
- Escalabilidad: El diseño escala con los requisitos
9. Prácticas de Git
- Commit messages: Conventional Commits
- Nombre de rama: Rama con nombre descriptivo
- Commits: Commits agrupados lógicamente
- Estrategia de merge: Rebase o merge consistente
- WIP Commits: Sin commits WIP en el PR final
10. CI/CD
- CI verde: Todos los checks pasados
- Build: Build exitoso
- Tests: Todos los tests pasados
- Lint: Sin errores del linter
- Security Scan: Sin vulnerabilidades
Ejemplo de revisión
## Code Review: JWT Authentication
### ✅ Bien
- Separación clara entre lógica de auth y controller
- Unit Tests exhaustivos
- Descripción del PR detallada
### ⚠️ Mejoras
- El secret debería leerse de variables de entorno
- La validación de token podría extraerse a un service
- Faltan Integration Tests para los endpoints de API
### ❏ Preguntas
- ¿Por qué se eligió JWT en lugar de OAuth2?
- ¿Está implementado el flujo de token refresh?
### ✏️ Cambios requeridos
- [ ] Leer secret desde ENV
- [ ] Agregar Integration TestsPriorización
| Prioridad | Categoría | Enfoque |
|---|---|---|
| Crítica | Seguridad, Lógica | Bloquea el merge |
| Alta | Rendimiento, Tests | Debe corregirse |
| Media | Estilo, Documentación | Puede completarse después |
| Baja | Detalles menores | Opcional |
Puntos clave de evaluación
- Checklist estructurada para revisiones consistentes
- Categorías: lógica, seguridad, rendimiento, tests, documentación
- Priorización: Crítica > Alta > Media > Baja
- Integración CI/CD como control de calidad
- Los breaking changes deben estar documentados
FAQ
1. ¿Qué es una checklist de revisión de código?
Lista estructurada de puntos de control para revisiones de código consistentes.
2. ¿Qué categorías incluye la checklist?
Lógica, seguridad, rendimiento, tests, documentación, arquitectura, Git, CI/CD.
3. ¿Cómo se prioriza la retroalimentación?
Crítica > Alta > Media > Baja. Crítica bloquea el merge.
4. ¿Cuáles son los puntos críticos?
Vulnerabilidades de seguridad, errores de lógica, tests faltantes.
5. ¿Qué incluye la descripción del PR?
Qué, por qué, tests, screenshots, breaking changes.
6. ¿Cómo revisar la seguridad?
SQL Injection, XSS, autenticación, secrets, validación de entrada.
7. ¿Cómo revisar el rendimiento?
Queries N+1, caching, algoritmo, memory leaks, operaciones asincrónicas.
8. ¿Qué revisar en los tests?
Unit Tests, Integration Tests, casos límite, cobertura, sin tests inestables.
9. ¿Qué revisar en documentación?
README, API-Docs, inline docs, changelog, migration guide.
10. ¿Qué revisar en prácticas Git?
Conventional Commits, ramas descriptivas, commits lógicos.
11. ¿Qué revisar en CI/CD?
CI verde, build, tests, lint, security scan.
12. ¿Cuánto tiempo debería tomar una revisión?
Con checklist, 15-30 minutos para PRs pequeños.
13. ¿Debe adaptarse cada checklist?
Sí, adáptala al proyecto y equipo.
14. ¿Qué hacer con breaking changes?
Documentar, proporcionar migration guide, actualizar changelog.
15. ¿Checks automatizados?
Automatiza linter, security scan y tests en CI/CD.
Continúa en la ruta de aprendizaje de Calidad de Software
El siguiente artículo en la ruta de aprendizaje de Calidad de Software cubre Static Code Analysis Tools (herramientas de análisis estático de código), como ESLint, SonarQube y Pylint para verificación automática de calidad.
Fuentes
- https://google.github.io/eng-practices/review/reviewer/
- https://github.com/features/pull-requests
- https://martinfowler.com/articles/code-review-checklist.html
Recomendaciones de libros sobre Calidad de Software
Si quieres profundizar en revisiones de código, aseguramiento de calidad y calidad de software en general, te recomendamos los siguientes libros:
Keine Bücher für Kategorie "software-engineering" gefunden.