所以，很快，我将成为迁移的一部分，将一个家庭滚动的持久层(大约任何好的、流行的 ORM)移动到 hibernate3。但是，在进行此迁移的同时，开发人员将致力于在当前 持久层之上实现新的业务逻辑，因此反对迁移!关于如何最好地管理大约 1MLOC 的迁移，有人有建议吗？
我有一些初步的想法，但我想听听意见。
- 最初，hibernate 迁移可能需要成为主要开发线的一个分支，专门致力于将当前系统转换为使用 hibernate。
- 在某个时候，开发应该切换到 hibernate 分支，或者应该将 hibernate 分支合并回主开发线。
- 一些开发人员可能需要完全专注于迁移任务，尽管每个开发人员可能都具备完成新逻辑所需的特殊业务特定知识。
还有其他人执行过如此规模的任务吗？我在想，也许可以为每个开发人员提供某种配给量，例如新逻辑与迁移工作的 80/20、60/40 时间。通过这种方式，每个开发人员都可以拥有自己的代码域，并且所有人都将接触到新的范例，以防止被排除在所有迁移工作之外的开发人员的生产力突然停止，突然进入 hibernate 状态。
那么，哪个可能更好？
专门负责迁移的核心开发人员单位
或
为迁移而在所有开发人员之间合理分配开发
哪个更好，为什么？
最佳答案
我以前做过这样的迁移，情况非常相似:这是一个巨大的关键项目(迁移时有 120 多个开发人员)，该项目使用自己的持久性框架(不是ORM，更像是一个非常接近 JDBC 的数据映射器)，我们在开始 1 年后，在构建阶段的中期引入了 Hibernate，没有停止开发。
这是我们的做法:
- 我们专门成立了一个特警团队(10 人，历时 3 个紧张的星期)来启动迁移
- 我们是在一个单独的分支做的，不能打扰到施工队
- 从逻辑上讲，我们从对象图的最深部分开始:(所有“引用数据”，如客户、银行账户、金融工具等，即大部分在各处使用的读取数据)。
- 我们为所有未经过充分测试的现有 DAO 编写了测试
- 我们映射了业务对象，我们使用 Hibernate API 和 HQL 重写了 DAO 方法
- 并在一些极其关键的部分上更进一步
- 我们在周末合并了代码，进行了所有可能的回归测试(0 回归 :)
- 我们培训了施工团队并制定了一些新的开发规则
- Hibernate 成为新开发的规则(如果可能的话)
- 现有持久代码的迁移是在适当的时候完成的
它奏效了。
关于java - 将自定义持久层迁移到 hibernate3，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3614804/