Herencia de modelos en Odoo

Hace unos días me hicieron una pregunta cuya resolución suponía modificar el código de Python del módulo de ventas de Odoo. Recomendé firmemente no hacerlo de esa manera, salvo que sea estrictamente necesario (hay un puñado de casos donde podría darse el visto bueno a hacer eso). Como de costumbre, la razón detrás era el ahorro de tiempo, cosa que puedo entender para salir de apuro, pero es preciso entender que un parche no siempre es una solución final. Vamos por partes.

Mantenimiento / Escalabilidad

Sin dudas la razón principal por la cual vamos a preferir heredar a modificar un módulo es el mantenimiento a futuro. Odoo como plataforma recibe una actualización anual, y cada versión tiene un mantenimiento a nivel código de 3 años. Esto quiere decir que nuestras customizaciones van a estar sujetas a eso. Y si, ya se que la mayoría de los negocios en Community no migran una vez al año; pero eso no quita que en un futuro deseen migrar. Si modificamos el módulo de mail directamente dentro de la propia carpeta vamos a incurrir en un problema a la hora de encarar una migración. No solo no sabremos que migrar sino donde se hicieron las modificaciones en primer lugar. Y esto es un consejo general, a lo mejor el equipo que hizo las modificaciones no es el mismo que migre; haciendo que la migración se convierta en un desarrollo prácticamente desde cero al no saber que y donde se modificó (independientemente de que git puede ayudar a entender dónde y cuándo se hicieron esos cambios).

El otro problema es la escalabilidad, aun si nunca migrara un negocio va a solicitar cambios en su plataforma. Esto se traduce en volver al código del módulo, interpretarlo (porque aunque sea nuestro es muy probable que necesitemos leerlo nuevamente) y hacer los cambios pedidos. Si debemos hacerlo en los módulos del core de Odoo estamos en problemas; hay customizaciones que implican el manejo de 4 o 5 módulos de Odoo, el no tener todo centralizado y de cómoda lectura afecta negativamente a la productividad, convirtiendo a la escalabilidad del sistema en una odisea.

Replicación

Si dedicamos un poco más de tiempo en producir un módulo genérico para determinada labor, podremos utilizar dicho módulo en un caso similar en el futuro, paradójicamente ahorrando tiempo en el proceso. Situación: "un usuario me pidió un desarrollo tan sumamente particular que no vale la pena hacer un módulo genérico porque nadie más en la vida me lo va a pedir". Bueno, eso es subestimar a los usuarios; pero llegado el caso, y aunque tengamos razón, tener módulos genéricos de cada desarrollo que llevemos a cabo es positivo al largo plazo, aunque sean módulos que no se van a vender a otra gente. En muchos casos pueden ser la base de un módulo diferente; o presentar una solución que puede ayudar a resolver otra cosa a futuro. De última, recomiendo que si le tienen poco cariño al módulo aun asi lo pongan público en Github; especialmente en plataformas como Odoo (con poca documentación) cada código cuenta y contribuye a la comunidad.

Riesgo

¿Qué pasa si codeamos algo mal en un módulo personalizado? Bueno, depende el error, en caso de un error grave como opción de "salvataje" podremos desinstalar el módulo y seguir usando Odoo como de costumbre. No es lo ideal, es más bien un botón de ejección ante una emergencia; pero al menos esa opción la tenemos con nuestros módulos. ¿Qué pasa si codeamos algo mal en el módulo de ventas? Bueno, ese en principio no lo podemos desinstalar si está siendo utilizado en Odoo; y para colmo el error podría ser viejo y detectado luego de varios "arreglos". En este caso volvemos a tener una emergencia, pero no tenemos el botón de ejección para salir airosos. Toca buscar dicho error; realmente creo que el riesgo es innecesario en una plataforma que permite heredar sin mucho problema.