将自定义持久层迁移到hibernate3

Question

所以，很快，我将成为迁移的一部分，将家庭滚动持久层（大约任何好的，流行的ORM）移动到hibernate3。但是，在迁移发生的同时，开发人员将努力在当前持久层上实现新的业务逻辑，从而阻止迁移！有没有人建议如何最好地管理大约1MLOC的迁移？

我有一些初步的想法，但我想要输入。

1. 最初，hibernate迁移可能需要成为主要开发线的一个分支，专门用于将当前系统转换为使用hibernate。
2. 在某些时候，开发应该切换到hibernate分支，或者hibernate分支应该合并回主开发线。
3. 虽然每个开发人员都可能拥有完成新逻辑所需的特定业务知识，但有些开发人员可能需要完全专注于迁移任务。

还有其他人执行过如此规模的任务吗？我想也许可以给每个开发人员一些配给量，比如新的逻辑与迁移工作的80 / 20,60 / 40时间。通过这种方式，每个开发人员都可以拥有自己的代码域，所有这些都将暴露给新的范例，以防止开发人员突然停止所有迁移工作，突然暴露于休眠状态。

那么，那可能会更好呢？

仅负责迁移的开发人员核心单位

或

所有开发人员进行迁移的合理分配

哪一个更好，为什么？

Answer 1

我过去做过这样的迁移，情况非常相似：它是一个巨大的关键项目（迁移时超过120个开发人员），项目使用自己的持久性框架（不是ORM，更像是一个非常接近JDBC的数据映射器），我们在开始1年后，在构建阶段的中间引入了Hibernate，而没有停止开发。

以下是我们的做法：

• 我们致力于一个特警团队（在3个紧张的星期内有10人）开始迁移
• 我们是在一个单独的分支机构中完成的，我们无法打扰施工团队
• 我们逻辑上从对象图的最深部分开始:(所有“参考数据”，如客户，银行账户，金融工具等，即大多数读取数据到处使用）。
  • 我们为所有尚未经过充分测试的现有DAO编写了测试
  • 我们映射了业务对象，我们使用Hibernate API和HQL重写了DAO方法
• 并在一些非常关键的部分上进一步了解
• 我们在一周结束时合并代码，进行所有可能的回归测试（0回归:)
• 我们培训了施工团队并制定了一些新的开发规则
  • Hibernate成为新发展的规则（如果可能的话）
  • 现有持久性代码的迁移是基于机会进行的

它有效。