2.2-Cosas-a-tener-en-cuenta-antes-de-pushear-un-nuevo-feature-a-main

Ver en Git

---

---

title: Cosas a tener en cuenta antes de pushear un nuevo feature a main

📘 Guía de Desarrollo de nuevos features.

Este documento tiene como objetivo definir una serie de buenas prácticas y requisitos a cumplir antes de mergear nuevos features a la rama main.

🔑 Buenas Prácticas Generales

✅ Crear un Merge Request (MR) y asignarlo a otro desarrollador para revisión.

✅ Revisar que no queden prints, console.log, ToDo, debugger en el código.

✅ Mantener mensajes de error claros y útiles para debugging.

✅ Escribir código mantenible antes que optimizado prematuramente.

✅ Testear el feature en los entornos de testing/preprod antes de pasar a producción.

✅ Revisar que las dependencias nuevas sean necesarias, estén documentadas y actualizadas.

✅ Mantener consistencia en el estilo del código (linters, pep8/eslint, etc.).

🔒 Seguridad

🔐 Involucrar al equipo de seguridad si el cambio impacta en integridad, autenticación, autorización o lo crees necesario.

🔐 No devolver IDs internos de la base de datos → utilizar UUIDs.

🔐 Usar self.require_login() para validar logueo en cada endpoint protegido.

🔐 Usar jsonschema.validate (o validadores equivalentes) para sanitizar inputs.

🔐 Verificar permisos de acceso según el objetivo del feature.

🔐 Evitar información sensible en respuestas (contraseñas, tokens, datos privados).

⚡ Performance & Mantenibilidad

📈 Priorizar la mantenibilidad del código sobre micro-optimizaciones.

📈 Evaluar limitar las pegadas con decorators. Ej: decorators = [limiter.limit("1 per second, 20 per minute, 50 per hour")]

📈 Documentar nuevas funciones, endpoints y estructuras de datos.

📈 Revisar queries SQL → evitar N+1 queries y asegurar índices adecuados.

📈 Verificar que no haya procesos que puedan causar memory leaks o consumo excesivo de CPU.

🗄️ Base de Datos

📌 Si se agregan nuevas tablas o migraciones, asegurarse de:

Crear las tablas en producción antes del merge.

Revisar que la migración corra correctamente en testing y producción.

Mantener backward compatibility siempre que sea posible.

Documentar la nueva estructura en la guía de datos.

📝 Checklist Antes de Mergear a Main

• MR creado y asignado a otro dev.

• Sin prints, debugger, ToDo.

• Logs de seguimiento implementados donde corresponda.

• Validaciones de input (jsonschema o equivalentes).

• Validación de login y permisos (self.require_login, roles, etc.).

• No se exponen IDs internos, solo UUIDs.

• Migraciones probadas en testing y ya creadas en producción.

• Tests ejecutados y pasados.

• Mensajes de error claros y manejados.

• Código revisado por seguridad si aplica.

• Revisar performance y queries SQL.

• Documentación mínima actualizada.