When it comes to development, it is essential to follow Odoo Best Practice that promote clean, efficient, and scalable code. That’s a general golden rule and best practice of software development, including here in Odoo ecosystem.
One of the great things about Odoo is the ability to customize almost anything. The downside of this is that most things need to be done in code.
Usually there are a multitude of changes/customizations (minor ones but many) that are made e.g. remove field A from form x in app/module1, add fieldB to form y in app/module2, create a custom module 3 for new functionality not present, change the domain for a particular search etc.
As listed above, these changes are made in a number of different modules. There’s so many ways out there that can be replicate by yourself to create your own customization. You might wonder, which path is the “right way”, which path is the “best practice” for doing that.
Odoo Module Development Best Practice
From here, we will be taking a small example for a better understanding. Let’s say your customer requires you to create three big module customizations consist of Sales Order, Purchase Order, and Inventory.
Best Practice 1 : Try to Split Each Feature To a Custom Module
You might wonder, should you make a customization in one module or split it up by for each customization?
Well, to be frank it’s actually it’s up to you who write the code.
But, as we should follow the best practice, it is better to split it up the feature for each customization. Since Odoo is promoting themself as a modular ERP, the customization we made should also adapt this kind of design.
This will help you to speed up the delivery. Based on the example above, if one of your custom module are finished (including manual or automated testing) you can start to deploy it in the production right away.
This shall make you look more professional since you develop things way much faster and efficient.
Best Practice 2 : Do Not Monkey-Patch
As we promote Odoo as a modular ERP, we also shall follow it’s principal. The principal practice of adding new feature is by extending the already-existed module using Class inheritance and, not using monkey patch approach.
As stated in wikipedia, monkey patch is a method that dynamically update the code at runtime. For example, Odoo has create() method that responsible to create a record. In order to extend the functionality of this create() we are supposed to inherit it by declaring a Class with _inherit parameter in our custom module.
Monkey patch in odoo is permissible, as it is always be just like in other framework or program but it should become the very, very last resort. It’s because when you do the monkey patch, that means there will be a chances other method which invoking it will also having a changes of behavior. This shall make other method prone to error. Thus, you have to do much consideration when you are about to do a monkey patching.
Best Practice 3 : Write Comments
During writing, jot down some comments regarding what these piece of chunk does to the system flow. You might remember how the code works now, but there’s no guarantee in a day or two you will remember what those blocks are used for, as you might stumbling upon other code block that also needs your attention. Try to briefly explain why you write that block and the outcome. Writing comment will also saving your time especially if you are a freelance developer, as you will later no need to create a separate documentation for yourself somewhere else.
Best Practice 4 : Consider Not To Loop Too Much Query Result
When it comes to fetch information or data from Postgresql database, consider when you should loop returned result through ORM or pack it into a collection of data object and loop from there instead.
Both of them has pros and cons. The pros If you loop through ORM, it will cost you less memory usage but the drawdown is there will be a database-roundtrips.
Same goes with packing things into collection of data. For example, a list. This will cost you some memory usage for saving temporary dataset into list, but this shall reduce the database-roundtrips and increase database performance.
Doing both will be okay if you could predict how many dataset will be returned as per loop through, but as the time goes by the database will grow over time so there might be a time when you reconsider and do a fine-tuning of it.
That’s all, for now
By following the good practice, the outcome of our module will be good and expected to working well.
