转：OpenERP8.0开发进展分享

原文来自开阖软件：http://www.osbzr.com/1291

OpenERP8.0开发进展分享

---

邮件列表里大家表示对新版本期待的同时，质疑OpenERP没有明确说明8.0会包含什么，每次都是fp像挤牙膏 一样说这个我们在做，那个我们在做，你们等着好戏吧。作为最终用户这确实是个最好的答案，保持饥渴么。对于我们这些靠openerp吃饭的人，谁知道他到 时候发布的是惊喜还是惊讶。

于是openerp公司的CTO Antony Lesuisse 回复了一下，很多人对这个回复比较满意，希望能把全文贴在网页上。开阖软件义不容辞提供中译。

 

So What’s in 8 ?

首先要对OpenERP的进展未做充分沟通表示抱歉。我们更愿意把时间花在修复缺陷和开发超棒的新功能:)

如您所知，我们做的所有事情都公开在launchpad网站和runbot.openerp.com上，但是上面有上千个代码库，对门外汉来说这简直是迷宫。

我们也吃自己的狗粮：我们一直在用OpenERP的项目管理模块，结合看板视图、EtherPad和SNS功能，每个任务都对应一个代码库的链接。

任务有以下阶段：
- 需求（新创意或愿望）
- 设计（功能设计、技术设计及易用性设计）
- 开发
- 功能和易用性设计
- 代码审查和合并
- 发布和推广（修改描述文件和更新日志、写博客文章等）
- 部署

这些任务被分隔成6个项目。
有三个长期固定项目：
- 框架（如接口规范、新BI模型/图表）
- 易用性和功能改善（如游戏化机制、问卷、群发邮件、base_action_rules里的工作日历以及很多小的改善）
- 平台（我们自己的OpenERP以及在线租用云管理）

有三个临时项目（不过可能会延续几个月甚至几年）：
- 建站系统（内容管理系统、电子商务）
- 仓库（新的WMS系统）
- 零售点（pos硬件和很多改善）

一部分重要任务现在正在进行中（在runbot上测试一下后，您可以问我关于他们的所有问题）

打开http://runbot.openerp.com/找到这个代码库单击链接后的向下箭头，点击“All addons”

新日程表和google同步（已经合并）
服务器动作和base_action_rule改善（已合并）
OpenERP数据转google电子表格（已合并）
游戏化（已合并）

trunk-website-al（将在近日合并）
- 建站系统
- 博客引擎
- 电子商务
- 仿照eventbrite
- 业务伙伴和推荐目录
- hr直接生成“我们的团队”页面
- 与招聘功能相连的职位列表
- 新的邮件模板构建器

trunk-new-graphview-ged（将在明天合并）
- 新的图表视图和多维分析
- read_group支持分组粒度，如创建日期（按年、按月、按日）

trunk-quote-roller（将在近日合并）
- 仿照quoteroller网站的在线报价系统

trunk-pos-ugly-but-fast（将在明天合并）
- 100倍的速度提升
- 原生支持硬件：打印机、扫描枪、钱箱
- 平板和手机支持及修复大量缺陷

trunk-survey2-rim（大概一个月完成）
- 基于旧的问卷模块和建站系统仿照serveymonkey

trunk-bs3-jke（大概三个月完成）
- 网页客户端由css向boostrap3转化
- 响应式设计，支持从手机到4K屏幕的自动适应

trunk-wms（大概两个月完成）
- 用“份”的概念大量重构
- 先进先出、后进先出
- 很多简化和缩减代码（去掉一些工作流）
- 和SAP一样强大（我们现在能处理所有SAP的用例）

trunk-apiculture（大概三个月完成）
- 新的应用程序接口（新字段类型，不需要id列表，没有cr，uid，ids参数）
- 修正 onchange

我知道大家对OpenERP公司的非我所创（Not Invented Here）综合征有抱怨很正常，但我认为我们多数情况下是正确的。但首先请允许我分享我在做这些决策时的四个原则（我也和Fabien分享过）。这些原则并非固定（因为我时常改变想法，他也是）。

1、在软件系统中集成的价值

我在这里考虑的并非简单独立的工具，而是由不同组件和功能组成的软件系统。

仿照梅特卡夫定律，我这里要来个Lesuisse定律（我也可能是未来规则制定者，嘿嘿）：

“软件系统的价值是集成的功能数量和集成程度的乘积”

我喜欢的几个软件系统已证实了这一点：
传统的unix工具集，一个强大的系统包含很多命令，但他们是松散集成的（靠单向的字节流）。
Debian发新版，大量的功能，不同的软件包集成程度不同。
集成的软件包如微软Office，Adobe套件，功能少但集成程度很高。
我也喜欢一切功能都内置上手即用的软件，姑且叫它厨房水槽软件（我不懂emacs所以无法用它来举例），例如Blender, facebook, chrome, Ableton live……

Ableton Live是个好例子，在用它之前我们总要花时间下载VSTi或者VST音效，用不同的的软件做midi序列、取样跟踪，适应不用的用户界面，开着好多个窗 口。Live改变了玩法，一切都集成在一起，使用相同的用户界面无缝地完成midi生成部分、取样部分、伴奏和音效。

我也喜欢通用并包含多种解决方案的软件，例如：
Linux – 从嵌入式到大型机的架构，所有的设备驱动都在一个代码库里
ffmpeg – 所有的视频和音频解码器在一个代码基里
mess/mame – 包含所有计算机设备的模拟器
qemu – 每一个源到目的cpu指令翻译/模拟功能都包含

当然包括ERP系统

2、内部整合与异构集成
您可能会注意到一些伟大的程序员（法布里斯贝拉德，约翰·卡马克，
的Linux Torvalds的…还有更多）会尽量保持最小的依赖列表。您
可以说，他们不符合NIH综合症，但是从他们的角度来看，这样做
意义重大。

首先我要比较一下两种集成方式：
内部整合是指当你调用一个链接库或从另一个系统复制代码、创意或模式。他们在相同的内存空间运行，靠函数调用来通信，使用相同的数据模型和类型，并非异步执行。你让他们在你的执行控制之下，让他们遵循你的规则、设计和架构。

异构集成是指你和其他使用不同平台、框架、数据模型和类型的系统做接口，或许它在另一台电脑上或者在同一台电脑的另一个内核进程上。

这很难，可行但是非常难，所以这样的集成成本应该与内部整合相比对，即使这意味着重复建设。

特别是协议很复杂的时候，UDDI WSDL SOAP这三个缩写足以让任何人理智的程序员感到恐惧和厌恶。

我们还得考虑用户体验，显性地从一个系统切换到另一个系统对最终用户来说总是个痛苦的体验。

我们在决策的时候要考虑这些方面。我还认为复制并不差，没有什么东西本身就很复杂（即使是高级工具），通常把这些东西集成起来就复杂了。比如我听说 john carmack 总是从头开始他的项目。

凡事都有例外，用HTTP和JSON这种通用协议和数据类型系统就容易多了。有时我们不得不在浏览器和服务器之间、在openerp和postgresql之间用rpc

异构集成的模块质量总是不高，因为需要大量工作：webdav, document_ftp, caldav, import_sugarcrm, auth_openid,
event_moodle…所以我们尽量少开发这种。

我也不喜欢不必要的依赖，说实话我希望python库的依赖限制在最新的Debian所提供的范围内。我们包含了一些javascript库，但我倾向于让这个越少越好。

3、保持简单

4、只有傻子和死人才不会改主意

openerp的战略是高效地提供集成度最高的企业应用系统，对最终用户和程序员来说都是如此。