Миграционные проекты чреваты опасностью.
Первая опасность: «это дорого и больно. Давай восстановим
все это с нуля и реализовать любую новую идею или функцию, которая
любой маркетолог / менеджер / программист использует структурированные методологии
и бла-бла-бла ... "Этот путь ведет к гибели, потому что
1) это открытый объем работы, и
2) никто на самом деле не знает, что делает старая система (недавно вы видели спецификацию?), И поэтому вы в конечном итоге заново откроете, что старая система после того, как новая заработает, нанесут большой урон и нанесут ущерб способности организаций делать свою работу с новым программным обеспечением. Обычно фактически новая система никогда не догоняет старую, и переписывание умирает ужасной смертью.
Правильный способ выполнить такую миграцию: настаивать на том, чтобы оставить функциональность в покое, и преобразовать существующую систему. Никаких новых вкусностей, возможностей, методологий.
У этой настойчивости есть свои проблемы: организации часто приходится вносить некоторые изменения.
по причинам выживания во время окна, в котором происходит миграция.
Чтобы справиться с этим, вам действительно нужен инструмент автоматической миграции, чтобы правило «без изменений в функциональности» применялось только во время фактического преобразования и, следовательно, было как можно более коротким. Разработчики инструмента миграции могут потратить некоторое время на его сборку и тщательно протестировать инструмент преобразования; в то же время организация может улучшить существующую систему своими обычными методами. Когда инструмент миграции будет готов ... нажмите триггер, преобразуйте код, исправьте проблемы и проверьте работоспособность системы результатов.
После того, как система была перенесена, вы можете рассмотреть возможность радикальной реструктуризации или изменения формы, зная, что фундаментальные функциональные возможности все еще сохраняются.
Что бы вы ни выбрали для инструмента автоматической миграции, вы должны быть осторожны, чтобы создаваемый им код можно было поддерживать в новой среде. Многие преобразователи превращаются в действительно наивные преобразования 1-в-1, и в результате получается код, унаследованный от foo-coded-in-new-bar, или то, что смешно называют «JOBOL» после наивных преобразований COBOL в Java. Инструмент преобразования должен быть изощренным в том, как он отображает языковые конструкции. (Возможно, вы захотите прочитать это ТАКОЕ обсуждение преобразования PL / 1 в Java ).
Ваша самая большая проблема, вероятно, будет "тестирование". Текущая система имеет полные функциональные тесты, верно? У вас нет каких-либо функциональных тестов? Как вы будете проверять, что новая система реализует то, что старая сделала правильно?
Правильный ответ здесь - построить тесты унаследованной системы с точки зрения ее поведения ввода-вывода и применить эти тесты как к унаследованной системе, так и к перенастроенной. Это большая работа, и никто не хочет ее делать, не говоря уже о том, чтобы платить за нее. Это второй способ сбоя миграции.
Последнее, что происходит, - это то, что руководство крайне недооценивает и не хватает работы, необходимой для того, чтобы сделать это правильно. Обычно переговоры с командой разработчиков идут так:
Mgr: How long to do this?
Team: Two years...?
Mgr: BZZZT! Wrong answer, try again...
Team: One year?
Mgr: BZZT! ..
Team: (Gulping) 6 months?
Mgr: OK, get started.
Обратите внимание, что здесь нет реального обсуждения работы.
По истечении 6 месяцев начнется указание пальцем. Менеджер: «Я спрашивал вас, ребята, а вы сказали 6 месяцев ...»
Вам предстоит грубая поездка. Приготовьтесь тщательно. Настаивайте на том, что люди действительно перечисляют все проблемы и что они дают правдоподобные оценки. Если вы выполняете миграцию впервые, у вас нет хороших оснований для таких оценок; если организация впервые, у нее нет оснований судить о том, верна ли какая-либо оценка.
(Полное раскрытие: я предвзятый. Я работаю над инструментами автоматической миграции уже 22 года. Ознакомьтесь с Миграция B2 .)