俄联储首席技术专家讲解Jimmer，一个革命性的ORM

从2022年3月开始，我辞去了工作，潜心研究革命性的ORM框架Jimmer并分享到github。

俄联储首席技术专家Aleksandr Belov敏锐地发现了Jimmer的划时代的革命性，最终决定决定让俄联储的项目往Jimmer上迁移。

获得巨大成功后，Aleksandr Belov代表俄联储在莫斯科为Jimmer举办了一场精彩的演讲。

俄罗斯联邦储蓄银行(英：Sberbank ，俄：СБЕРБАНК)成立于 1841 年，是俄罗斯最大的国有商业银行，占有四分之一以上的国内银行资产，与俄罗斯经济和社会发展息息相关

视频分享

俄联储首席技术专家讲Jimmer，又一西方技术被中国替代
www.bilibili.com/video/BV1Cp13YdEQ...

视频介绍

作为深入使用的Jimmer大型机构，俄联储和Jimmer结缘较早，此演讲于4月申请、7月审批、9月排练、10月执行。

欲了解俄联储为何和Jimmer结下良缘，先要了解为什么开发人员分化成了ORM和SQL两大阵营并形成强烈对立。

以JPA为代表的传统ORM性价比太低，即”生产力提升/运用它的成本”的比值很低。更糟糕的是，容易生成低性能的SQL，对初学者而言尤其如此。事实上，即便你是相关专家，在避免低效SQL和让其尽可能强大灵活两方面可以做的事也不多。

这相当于给行业画了一个超大的饼，但是饼没做好，开发人员进退两难。对此，业内有两种应对方式

• 进 (以外部环境为主)：前仆后继地开发更多更好的方案。然而，要彻底解决这些历史遗留问题非常难，我个人是苦思冥想十多年才得到这套方法论的。视频开头处的台词“方案虽然很多，但是可以直接拿来用的很少”就是对这种现象的委婉表达。

• 退 (以内部环境为主)：回归原始SQL路线。此模式存在三大问题

  • 实际项目中绝大部分复杂性都是因需要操作复杂数据而衍生出的各种工程复杂性，局部的每个数据库操作细节反而成为最不重要的问题，所以这种开发路线会导致工作的大量重复。任务虽然无比简单，但是似乎永远都做不完，疯狂加班成为常态，严重影响了从业人员的身心健康（难解决）。
  • 适应需求快速变更的能力差，开发团队和产品团队的矛盾不断（难解决）。
  • 几乎所有环节都可以轻松引入低级错误，但是，大部分中小型团队无力支付高覆盖自动化测试的成本，品控难（可通过技术选型和改变开发习惯解决）。

Aleksandr Belov既能深刻地认识到现有ORM的问题的严重，又绝不回退到原生SQL那种高内耗的开发模式。于是花了一个月研究github上所有star超过100的所有新型ORM，发现只有Jimmer能满足自己所有要求，废寝忘食研究了了两个星期后，最终决定让俄联储的项目向Jimmer迁移。

最后论述一个伪命题：”原生SQL流派具有很好的可控性”，这句话成立的前提是鲜有ORM存在严重问题，既无法带来惊叹的生产力提升，也容易导致低性能SQL的出现。然而，如果信的ORM性价比足够高且能制止低性能SQL的出现，那么这就不是问题，这就好比，因为高级语言的性价比足够高，所以没人在乎汇编级别的可控性。

大量问题长期未得到解决的确会带来绝望，但是，请勿把绝望固化为信仰，未来一定会更美好。

相关资源

俄文原始链接：jokerconf.com/en/talks/3f29bdad0db...
项目地址：github.com/babyfish-ct/jimmer
文档地址: babyfish-ct.github.io/jimmer-doc/z...
官方示例：github.com/babyfish-ct/jimmer-exam...