Guía de Pull Request [Code review]
Objetivo: Validar la calidad, arquitectura, reutilización e impacto en el sistema/app
Antes de crear un Pull Request verifica:
- ¿Se probó la funcionalidad completa? = Sí
- ¿Rompe otras features? = Sí
- ¿Se siguen la guía de estilo y lineamientos del área? = Sí
- ¿Nomenclatura adecuada en código, assets, escenas? = Sí
- ¿Código limpio y documentado (sin debug logs innecesarios)? = Sí
- Si aplica ¿Se reutilizan módulos existentes? = Sí
- ¿Hay lógica duplicada? = No
Cosas que el líder técnico / programador principal debe revisar antes de aprobar un Pull Request:
Arquitectura
- ¿Respeta la arquitectura del proyecto?
- ¿Está bien separada la responsabilidad?
- ¿Evita acoplamiento innecesario?
Reutilización
- ¿Esto ya existía?
- ¿Se puede convertir en módulo/pseudo módulo o elemento reutilizable?
- ¿Es reutilizable en otros proyectos?
Simplicidad
- ¿Es lo más simple posible?
- ¿Evita sobreingeniería?
Principios KISS / YAGNI
Legibilidad
- Nombres claros
- Código entendible sin explicación y documentado (si es necesario)
- Métodos cortos
- Respeta la guía de estilo, estructura y nomenclatura
Riesgos
- ¿Puede romper algo existente?
- ¿Afecta otras escenas/sistemas/features?
UX / Funcionalidad
- ¿Se comporta como espera diseño?
- ¿La interacción es correcta?
Pull Request - Proyectos internos
Flujo / Lineamiento
- Todos los cambios y/o mejoras en los repositorios, tanto del proyecto base como de módulos internos, deberán trabajarse sobre la rama "Develop".
- Posteriormente, se deberá crear un Pull Request para la revisión de los cambios.
- La descripción del Pull Request debe ser clara y breve.
- Los Pull Request deben contener commits con cambios pequeños.
- La única persona que aprueba el Pull Request es el LDA o, en su defecto, un responsable designado del repositorio.