【odoo】关于odoo二开模块规范的一点思考
2022-01-03 04:07
661 查看
背景
作为丙方,完成了甲方的二开需求。因此,在设计二开模块的时候,考虑的是当时所列的需求清单,并整合到一个二开模块中。完成交付后,客户评价蛮好的。因此,成功的为乙方争取到了继续合作的机会。然后,就没我啥事了,尴尬...
再之后过了一两个月,另一个丙方搞不定甲方的需求,所以我又被安排上线收拾残局。而,此处接手的残局有点坑,涉及多个开发的二开模块。由于甲方的需求是分批提出,且由多个团队完成。因此,二开模块的间存在循环依赖的情况。在已经跑起来的库上运行,没有任何问题,但是,在新库上重新安装的时候,会发现根本安装不上。因此,决定花一个月的时间彻底拆分已有的二开模块。
为什么拆
问:一般情况下,odoo上线后基本上不会出现在新库上重新部署的情况,为什么还要费劲去拆分二开模块呢?
答:最核心的原因是,这可能是一个需要长期维护的项目。
问:长期维护的项目和单次分包的区别是什么?
答:长期维护的项目,虽然在前期可能会付出更多的时间,但是可便于后期的项目管理,即便是最极端的情况发生,也可以以较快的速度恢复生产;而单次分包的项目,一般只是为了去完成一份需求清单,而且即使设计了二开的原因,也很少会有单次分包人员会遵守,因为工作量会增加。
怎么拆
- 针对基础模块的功能扩展:比如库存、销售、采购等,此类二开模块需仅包含针对该单一模块的功能扩展,且不能引用非odoo原生的模块;
- 针对多基础模块的功能扩展:比如针对销售的业务中扩展对调拨的业务处理逻辑,此类二开模块应仅包含odoo原生的基础模块和1中二开模块;
- 针对独立业务场景的功能扩展:比如图书馆有借书还书的需求,就需要单独根据业务场景扩展功能模块。
以上三项是否拆分的合理的一个主要的标识是,1、2、3中的任意模块均可独立安装(2、3中在__manifest__.py中添加所需依赖)
本项目的拆分效果如下:
各二开模块建议是甲方公司的简称,便于标识。
结论
由于业务是不断变化和发展的,为了让系统真正成为助力业务发展的工具,势必会接触到odoo的二开市场。因此,不管是甲方还是可以长期维护的乙方,都建议在二开之初,可以参考上面提到的“怎么拆”章节。当然,如果是单次分包,那就随意吧。
相关文章推荐
- 关于SAP物流和供应链模块发展的一点思考
- 关于最小生成树算法原理的一点思考
- 关于c加加的一点思考
- 关于jQuery中load函数的一点思考
- 关于javascript面向对象的一点思考
- 关于windows内核SSDT HOOK的一点思考
- 关于APP开发的一点思考
- 关于Windows下ShellCode编写的一点思考
- 关于模板方法和策略模式的一点思考
- 关于Test Case与Bugzilla的一点思考
- 关于棋牌类服务端架构的一点思考
- 关于数据分析的一点思考
- 最近关于物联网模块创新方面的思考(如何让物联网真正落地生根)
- 关于cocoa编程模块间协作的一点总结(delegate/T-A/notification/...)
- 关于Windows下ShellCode编写的一点思考
- 关于设计web页面的一点思考
- 关于自学的又一点思考
- 关于项目启动报ibatis.BindingExcetion错误的一点思考(持续更新中)
- 关于C++两个类相互引用的一点思考
- 关于程序员成长的一点思考