When it comes to development,  it is essential to follow best practices 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.

Best practice illustration

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.

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. The question is, should you make a customization in one module or split it up by three for each customization?

Well, actually it's up to us who write the code.
But if we follow the best practice, it is better to split it up by three 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. For all those three module customization, if one of them are finished (including manual or automated testing) you can start to deploy it in the production. After that, you can start to work on other requirement. 

Still on the modular subject, modular ERP mean we should follow the class inheritance and extending the selected module, instead of doing a monkey patch. 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. In another article, i already explain why doing monkey patch is bad in Odoo and what makes me doing that in the very last minute of the project.

During writing, jot down some comments regarding what these piece of chunk does to the system flow. You might remember how it would work 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.

When it comes to fetch information or data from Postgresql, consider when you should loop returned result through ORM or pack it into a collection of data object and loop from there. 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.