odoo11-写在前面

这几年接触到了flask, tornado,django,odoo之后。在独立开发方面odoo貌似具备无可比拟的优势。我应该不是odoo学习最深入最了解的人吧。但odoo大概也是最轻松的的呢。odoo的结构设计本身就是为了模块化，企业化。不得不说相比于django和flask这种迭代开发的模式。odoo更加偏向于一次成型，二次迭代。当一个功能产生到后面迭代。不会出现太多了次数。因为odoo会随着经手人的增加。迭代的次数增加越来越难用。在最初恰恰是最易用的时候。

实现了这么多年的迭代和非迭代的需求。大部分功能其实都围绕一个主逻辑的细枝末节。并不需要持久开发。只有跟商业模型相关的主逻辑会不断的迭代。所以其他很多逻辑在这个程序员实现功能到上线代码。很长一段时间不会发生变动。只要能用。只有在产品完成一个大版本之后慢慢不管精修枝叶。而这一切其实符合odoo的概念和运行逻辑。

odoo在中国使用存在一个落地难的问题。odoo内部存在大量的erp模块。可以呗随意微调。这恰恰也是很多中国公司和团队使用odoo的原因吧。不管是我还是我朋友都被落地这个问题所坑到。国情不同。逻辑不同。二次开发做调整还是重新开发。而重新开发到底要不要用odoo这些问题都是被稀里糊涂的回答。

只能说按照自己需要去解决。后续主要编写大概也是一些odoo 11 的一些基本结构和戏法。还有属性介绍吧。在odoo模块构成中最初也是最让人舒服的模块构成。所以除了使用odooweb模块外不使用odoo任何app。二次开发真的没什么。有足够的水平之后不断阅读理解。然后在关键位置做更改罢了。

但重新用odoo开发模块真的会比二次开发慢很多吗？？

如果考虑好所有商业逻辑。odoo的开发速度不会让任何人失望。在我足够熟练的时候甚至比django更快。就更别提flask和tornado了。每个人因为各种各样的理由吧。仅仅只是证明这个可能性。在去掉一大块精华的同时也去掉绝大多数的糟粕。保留了odoo最低绝对精华的部分吧。只有在足够了解熟悉的情况下。在考虑启用部分odoo应用为宜。这其中需要花费大量的时间而我自认不足以应对。

如果有问题欢迎指正。 [email protected]