Hector Villarreal OrtegaLa revisión de código en open source no consiste solo en encontrar bugs. En un proyecto como la Odoo Community Association, revisar también significa cuidar compatibilidad, mantenibilidad, guía para contribuidores y estándares compartidos entre muchas empresas y países.
El código puede resolver un problema local, pero el módulo debe seguir siendo útil para una comunidad más amplia.
Los módulos de Odoo viven entre versiones, migraciones y estilos de despliegue distintos. Un cambio que funciona en una base de datos puede romper otra por módulos instalados, configuración, localización o comportamiento específico de versión.
Una buena revisión pregunta:
El objetivo no es bloquear cambios. El objetivo es hacer que el cambio sea seguro.
Los tests no solo protegen contra regresiones. Explican el comportamiento esperado. En software de negocio esto es especialmente importante porque las reglas pueden ser sutiles: impuestos, movimientos de stock, facturas, permisos, monedas y comportamiento específico por partner.
Un buen test le dice al siguiente mantenedor qué debe seguir siendo cierto.
Los comentarios línea por línea son útiles, pero la forma general importa más. Un pull request puede pasar tests y aun así introducir una abstracción equivocada, duplicar comportamiento existente, mezclar cambios no relacionados o esconder una regla de negocio en la capa incorrecta.
Una revisión útil busca:
La revisión open source suele ser asíncrona. El contribuidor puede estar en otra zona horaria y no compartir el mismo idioma nativo. El feedback directo y específico ayuda más que preferencias vagas.
En vez de decir “esto no está limpio”, explica el problema: “esto duplica el helper existente y divergirá durante la migración; por favor reutiliza el helper y añade un test para el caso nuevo.”
Ese tipo de revisión mejora el código y ayuda al contribuidor a aprender el proyecto.
El mejor hábito de revisión es pensar en la siguiente persona. ¿Entenderá la razón del cambio? ¿Podrá depurarlo? ¿Podrá migrarlo? ¿Podrá extenderlo sin leer una conversación privada?
La calidad open source se construye con muchas decisiones pequeñas como esa. Un buen pull request resuelve el problema inmediato. Una buena revisión ayuda a que el proyecto siga sano después de resolverlo.
Written By
Ingeniero de backend y experto en Odoo con más de 8 años de experiencia especializado en Python, arquitectura de sistemas escalables y aplicaciones de alta disponibilidad. Apasionado por construir sistemas de backend robustos, optimizar el …
Hector Villarreal OrtegaDocker Compose a veces se descarta como una herramienta solo de desarrollo. Para muchos equipos ERP pequeños y medianos, puede ser mucho más útil que eso si se aplica con disciplina.
Leer más
Hector Villarreal OrtegaEl trabajo con Odoo suele describirse como personalización de ERP, pero los proyectos serios se convierten muy pronto en problemas de ingeniería de plataforma. Una implementación real toca diseño de base de datos, integraciones, colas, almacenamiento de archivos, despliegues, monitorización, seguridad y soporte operativo.
Leer más