Cuando hablamos de programar en Odoo, hablamos directamente de la creación o modificación de módulos. Es la piedra angular sobre la que se asienta el ecosistema de Odoo y es por ello que debe ser una tarea fundamental la correcta gestión de estos. En este artículo vamos a hablar de buenas prácticas y cómo consideramos en Dixmit una buena estructura de módulos, para que sea sostenible a largo plazo.
Más allá de cómo es la estructura de módulos de Odoo, que ya todos sabemos, queremos hablar del contenido de los mismos.
¿Qué debemos tener en cuenta?
Seguir la línea de desarrollo existente.
Primero es aconsejable seguir las nomenclaturas definidas por Odoo y dividir el desarrollo en ficheros según el modelo al que afecte. Por otro lado, debemos revisar siempre que lo que queremos no se haya realizado antes, como la creación de un campo, o exista algo que podamos reutilizar. También debemos diseccionar el código en métodos con una acción lo más concreta posible para que pueda ser reutilizado en el mismo módulo o en futuros módulos, y además hacer uso de las menores dependencias posibles.
En nuestro caso, si un módulo empieza a crecer, solemos dividir el módulo en piezas más pequeñas para poder hacer una gestión más atómica y controlada. De esta forma, podremos hacer un uso de dichas funcionalidades. Además, es básico extraer las funcionalidades genéricas y, si es posible, ponerlas en un módulo OCA. Por ejemplo, si nos solicitan añadir 5 campos nuevos en contacto y dos de ellos tienen sentido fuera de esta implementación, crearemos un módulo OCA con esta funcionalidad concreta.
Tests
Seguidamente, debemos de tomarnos en serio dos aspectos del desarrollo vitales, que marcan la calidad de un desarrollo. La creación de tests y la documentación. El desarrollo de testing es una tarea aparte, no imprescindible pero altamente recomendable. Y enfocarnos en él, desarrollando una buena batería de pruebas, hará por un lado, que el módulo sea más robusto y, por tanto, mantenible a largo plazo, y por otro lado asegurarnos haber entendido e implementado correctamente el módulo. Con un buen testing, nos podríamos asegurar incluso de entender en qué consiste el módulo con solo ver los tests. Además, con lo de ser tarea aparte, también debe conllevar un buen desarrollo del código de test y una documentación de los mismos.
Un detalle que nos ha salvado más de una migración: siempre añadimos tests para las reglas invisibles del negocio, esas que no quedan claras revisando solo el código o los XML. Por ejemplo, validaciones que dependen de fechas, estados intermedios o cálculos con rounding. Estos tests actúan como contrato histórico y evitan regresiones cuando, cuatro versiones después, ni siquiera recordamos por qué aquello se programó así.
Documentación.
Como hemos comentado anteriormente, la documentación es otro de los pilares para hacer mantenible un módulo a largo plazo, y al igual que los tests, se debe prestar especial atención en su desarrollo, no simplemente poner una breve frase de descripción, sino explicar y que se entienda el motivo del módulo, la necesidad que cubre, de qué se compone, posibles implicaciones, explicación de su uso, de su instalación, aspectos futuros, deficiencias encontradas y pendientes de resolver. Es decir, todo aquello que nos permita conocer la estructura del módulo y su contexto, ya que para asegurarnos la correcta mantenibilidad del módulo deberemos ir revisando su funcionalidad y su marco contextual.
Un error típico que hemos visto en proyectos antiguos es depender demasiado de conocimiento oral: módulos sin README, o con uno que no explica nada. En Dixmit siempre intentamos que el README esté correctamente informado. Además, todos los cambios quedarán registrados en el sistema de versiones, que nos permitirá ver cada cambio cuando sucedió y, allí ver la discusión alrededor a dicho cambio.
¡Ojo con el JavaScript!
Como tip extra para hacer tus módulos mantenibles a largo plazo, es recomendable reducir la cantidad de código en JavaScript al mínimo posible y emplear otras herramientas sustitutivas. Esto se debe a qué el código de JavaScript cambia mucho entre versiones y las migraciones son más costosas, haciendo más difícil su mantenibilidad a largo plazo. En cualquier caso, desde la versión 18, si se opta por realizar código con OWL y JavaScript, deberíamos implementar tests que nos ayuden a mantenerlo como ya hemos explicado.
Aquí hemos aprendido a base de golpes: los módulos con JS personalizado en Odoo 12–14 son los que más nos han costado migrar a OWL. Por eso ahora aplicamos una regla clara: si la funcionalidad puede resolverse con vistas, server actions, comandos o ajustes backend, evitamos JS. Y si escribimos OWL, añadimos siempre tests de componentes y snapshots.
Conclusión
Desde Dixmit, os animamos a que sigáis todos estos consejos y nunca descuidéis la correcta gestión de módulos. También es aconsejable seguir la guía de buenas prácticas de la OCA, ya que se tratan de directrices consensuadas por los mayores expertos de desarrollo de Odoo y te pueden garantizar que un módulo sea sostenible a largo plazo.
La sostenibilidad no se consigue con trucos mágicos, sino con pequeñas decisiones diarias: no mezclar responsabilidades, documentar por qué se hace algo, escribir tests para lo que podría romperse y evitar dependencias innecesarias. Esta filosofía es la que nos permite mantener módulos que empezaron en Odoo 11 y hoy funcionan en Odoo 18 sin grandes sobresaltos.