Перенос пользовательского слоя персистентности в hibernate3

Question

Итак, очень скоро я буду частью миграции, которая переместит домашний слой персистентности (примерно любой хороший, популярный ORM) в hibernate3.Однако в то же время, когда происходит такая миграция, разработчики будут работать над реализацией новой бизнес-логики поверх уровня персистентности current , следовательно, работая против миграции!У кого-нибудь есть предложения относительно того, как лучше всего управлять миграцией около 1MLOC?

У меня есть некоторые начальные мысли, но я хотел бы ввести.

1. Первоначально миграция в спящем режиме будетскорее всего, это должна быть ветвь основной линии разработки, предназначенная исключительно для преобразования текущей системы в режим гибернации.
2. В какой-то момент разработка должна либо переключиться на ветку гибернации, либо ветка гибернации должна быть снова объединена восновная линия разработки.
3. Некоторым разработчикам, скорее всего, придется быть исключительно-исключительно преданными задаче миграции, хотя у каждого разработчика могут быть специальные специфические для бизнеса знания, необходимые для завершения новой логики.

Кто-нибудь еще выполнил задачу такого масштаба?Я думаю, что, возможно, каждому разработчику может быть предоставлено определенное количество нормирования, например, 80/20, 60/40 времени для новой логики против миграции.Таким образом, каждый разработчик может владеть своим доменом кода, и все будут подвергаться новым парадигмам, чтобы предотвратить внезапную остановку производительности для разработчиков, оставшихся без всякой миграции, внезапно подвергшихся гибернации.

Итак, что, вероятно, было бы лучше?

Базовое подразделение разработчиков, которому поручена только миграция

или

Рациональное разделениеразработки для всех разработчиков для миграции

Что из этого будет лучше и почему?

Answer 1

Я делал такую ​​миграцию в прошлом, ситуация была очень похожей: это был огромный критический проект (более 120 разработчиков на момент миграции), проект использовал свою собственную среду хранения (не ORM, точнее, картограф данных (очень близкий к JDBC), мы внедрили Hibernate через 1 год после запуска, в середине этапа строительства, не останавливая разработку.

Вот как мы это сделали:

• мы направили команду сватов (10 человек в течение 3 интенсивных недель) для начала миграции
• мы сделали это в отдельной ветке, мы не могли помешать строительной команде
• мы логически начали с самых глубоких частей графов объектов: (все «справочные данные», такие как клиенты, банковские счета, финансовые инструменты и т. Д. И т. Д., Т. Е. В основном считывают данные, используемые повсеместно).
  • мы написали тесты для всех существующих DAO, которые недостаточно протестированы
  • мы отобразили бизнес-объекты, переписали методы DAO, используя Hibernate API и HQL
• и пошли немного дальше по некоторым чрезвычайно важным частям
• мы объединили код в конце недели, выполнив все возможные регрессионные тесты (0 регрессия:)
• мы обучили строительную бригаду и создали несколько новых правил разработки
  • Hibernate стал правилом (если возможно) для новых разработок
  • миграция существующего постоянного кода была выполнена при возможности

И это сработало.