Odoo Core 和重新发明一切的成本

Source: Dev.to

Odoo 是一个提供众多预构建模块（小型应用）的单一平台，这些模块是大多数公司所需的。例如，几乎每家公司都需要一个人力资源系统来管理员工信息、请假、考勤、合同、离职等。除了人力资源，企业还需要采购、库存、会计、认证、授权等系统。

Odoo 将所有这些紧密耦合的系统打包成一次安装。从纸面上看，这听起来很棒——从商业角度来看，它确实常常如此。但从技术角度来看，情况会很快变得复杂。

主要 Odoo 组件（从最简单到最复杂排序）

Odoo HTTP 层

• JSON‑RPC
• 网站路由

Odoo 并不是基于 Django 或 Flask 等标准 Python Web 框架构建的。它在 Werkzeug（一个 WSGI 实用库）之上实现了自己的 HTTP 框架。该层引入了自己的抽象、请求生命周期、路由和序列化逻辑，包括 JSON‑RPC 和网站控制器。虽然技术上令人印象深刻，但它重新实现了许多已经被现有框架解决并经受实战检验的问题。依我之见，这是 Odoo 最成问题的部分之一。

Odoo 视图

• XML 转换为 Python 和 JavaScript

基于 XML 的视图会发送到浏览器，然后通过抽象语法树（AST）分析转换为 JavaScript。在其他场景（如网站）中，XML 可能会先被转换为 Python 代码，有时再转换回 JavaScript。这导致：

• 高认知负担
• 调试困难
• 后端与前端耦合紧密
• 与现代前端栈相比，工具支持不足

感觉就像用原始金属造车，只是为了从 A 点开到 B 点。

Odoo ORM

• 自定义继承系统（而不是使用 Python 内置的）
• 依赖注入机制
• 查询构建器
• 缓存层（LRU）
• 通过猴子补丁进行模型扩展

虽然功能强大，但该系统极其复杂，难以推理。调试模型行为常常像在看不见的魔法层中穿梭。

缓存系统

• 从头实现

WebSocket 实现

• 超低层级处理

Odoo 并未使用成熟的实时框架，而是用非常底层的逻辑实现 WebSocket 处理，有时代码文件既小又密集。代码库中的一条注释比文字更能说明这种做法：

[Insert comment from the codebase here]

历史背景

对 Odoo 架构的常见辩护是“它是一个老系统”——最初在 2005 年左右使用 Python 2 开发。然而，这一论点已不再成立。Odoo 在 2017 年左右为支持 Python 3 进行了大规模重写。那时，已经有许多优秀的框架能够更干净地解决相同的问题，并且持续演进而不会破坏其生态系统。

对开发的影响

如今，即使是对 Odoo 核心的微小改动也可能导致自定义模块崩溃，除非这些模块仅限于简单的 CRUD 模型且对核心行为的依赖极少。Odoo 是一个强大的产品，也是一个成功的商业平台，但从软件工程的角度来看，许多设计决策更倾向于控制和内部一致性，而非可维护性、清晰度和开发者体验。如果你长期使用 Odoo，你会不再问“它为什么这么实现？”而是问“我该如何在这次升级中生存下来？”