将自定义持久层迁移到 hibernate3
因此，很快，我将参与迁移，将本地持久层（大约任何好的、流行的 ORM）迁移到 hibernate3。然而，在这种迁移发生的同时，开发人员将努力在当前持久层之上实现新的业务逻辑，从而阻碍迁移！有人对如何最好地管理大约 1MLOC 的迁移有建议吗？
我有一些初步的想法，但我想要输入。
- 最初，hibernate 迁移可能需要成为主要开发线的一个分支，专门用于将当前系统转换为使用 hibernate。
- 在某些时候，开发应该切换到 hibernate 分支，或者应该将 hibernate 分支合并回主开发线。
- 尽管每个开发人员可能拥有完成新逻辑所需的特殊业务特定知识，但一些开发人员可能需要完全专注于迁移任务。
还有其他人执行过如此大规模的任务吗？我认为也许可以为每个开发人员提供某种配给量，例如新逻辑与迁移工作的 80/20、60/40 时间。通过这种方式，每个开发人员都可以拥有自己的代码领域，并且所有人都将接触到新的范例，以防止那些被排除在所有迁移工作之外、突然暴露于休眠状态的开发人员的生产力突然停止。
那么，哪个可能会更好呢？
仅负责迁移的开发人员核心单位
或
所有开发人员之间的开发分配分配以进行迁移
哪一个更好，为什么？
So, very soon, I will be part of a migration that will move a home-rolled persistence layer (circa any good, popular ORM) to hibernate3. However, at the same time that this migration happens, developers will be working to implement new business logic atop the current persistence layer, hence working against the migration! Does anyone have suggestions as to how best to manage a migration of about 1MLOC?
I have some initial thoughts, but I'd like input.
- Initially, the hibernate migration will likely need to be a branch of the main development line devoted solely to converting the current system to use hibernate.
- At some point, development should either switch to the hibernate branch, or the hibernate branch should be merged back into the main development line.
- Some developers will likely need to be pretty-solely devoted to the task of migration, although each developer may have special business-specific knowledge necessary for completing new logic.
Has anyone else performed a task of this magnitude? I'm thinking that perhaps some kind of rationing amount could be given to each developer, such as 80/20, 60/40 time for new logic vs. migration work. In this way, each developer can own their domain of the code, and all will be exposed to the new paradigms to prevent a sudden halt in productivity for developers left out of all migration work, suddenly exposed to hibernate.
So, then, which would likely be better?
A core unit of developers tasked solely with migration
or
A rationed split of development across all developers for migration
Which of these would be better, and why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我过去做过这样的迁移，情况非常相似：这是一个巨大的关键项目（迁移时有超过 120 名开发人员），该项目使用自己的持久性框架（不是 ORM，更多一个非常接近 JDBC 的数据映射器），我们在开始一年后引入 Hibernate，在构建阶段的中期，没有停止开发。
我们是这样做的：
并且它有效。
I've done such a migration in the past, the situation was very similar: it was a huge critical project (more than 120 developers at the time of the migration), the project was using its own persistence framework (not an ORM, more a data mapper very close to JDBC), we introduced Hibernate 1 year after the start, in the middle of the construction phase, without stopping developments.
Here is how we did it:
And it worked.