morgan1freeman
329 天前
国情所致吧，国内的项目大多短平快，半年就要出成绩，甚至 2 个月就要出成绩，而且码农本身真的很便宜（相对国内的公司收入而言），一个项目再烂，再狗屎都能请到人来维护，像 JPA 这种 Model First 的框架当然不合适，远没有 mybatis 面向 db 表驱动的开发模式搞的快。
要是美国 2000 美金就能雇佣工程师去吃屎，资本家怕是笑得合不拢嘴，做梦都能笑醒，软件工程？啥是软件工程？ 2000 美金雇个大学生，让你在屎山里面 996 遨游不香么？这比 GPT 高级不知道多少的真人工智能，才 2000 美金在就中国能雇佣到一个入门的。
讲一个真实的案例，我们系统里面有一个车辆模型，光是 status 状态就好几个， 审核状态，车辆可租售状态，催审状态 等一大堆的状态变量，而这些状态变量本身相互之间还有依赖。
结果这些变量全部都在各个接口跟 job 里面来维护，本来这种状态变化最好的方式当然是维护一个状态机模式，在模型内部维护车辆状态，不至于代码逻辑失控。
但是我们的现状就是类似 mybatis 这种，天然就是面向 db 的（虽然 mybatis 有提供一个表针对多个对象的转换服务，但是真的很少看到有人用，毕竟是个半残的 ORM ），几乎不存在逻辑内聚的需要，这个开发在 job 服务里面 query 出来 update 一下，那个开发在接口里面 query 出来 update 一下，代码多了，服务多了，基本上就失控了，第一版写的人很爽，因为一开始状态很少，变量也少，逻辑还没有分散在各个代码仓库（草台班子还用上了微服务，逻辑没有内聚，全靠人肉对代码进行跨仓库静态分析），基本上不会有什么思维负担，对于三版第四版维护的人来讲，简直比吃屎还难受，时间评估的多，还容易改错。
说到底用 JPA 跟用 Mybatis 是两种截然不同的开发模式跟思维方式，一个系统里面 OLTP 的部分出错了，需要花费巨大的成本去定位问题，以及修复数据，并评估对生产数据带来的影响，成本极高。对于业务逻辑相对复杂的项目，建议使用 JPA 去好好建模分析的，减少业务变动对于后续维护者带来的心智负担。
对于需求变化极快且复杂的 OLAP 需求，这种功能大多都是面向内部，用 SQL 怎么快怎么来，就算出错也没事，改改就好，而且我经常跟人讲，OLAP 就是要打破业务逻辑里面的 Model ，甚至用 es 来重新聚合 Model 的数据都没有问题，因为 OLAP 就算出问题，who care ？分析数据？根本不重要的东西。
以我之前那个案例来讲，有一个哥们因为车辆状态太复杂，帮业务下线一匹数据，job 维护车辆的逻辑写错了，导致生产上几千辆车 没法进行租售，直接就是生产重大事故，要是做个报表联几个表出一个后台页面，就算是错了又能怎样？糊弄一下就过去了。