Лучшая стратегия перехода с VB6 на .NET.

Моя компания имеет множество устаревших приложений, написанных на VB6.

Мы находимся в переходах от перемещения приложений VB6 к .NET(3.5).

Какова была бы лучшая стратегия для перемещения формы VB6 в .NET?




ПРИМЕЧАНИЕ. Ниже обновление должно перейти к "Управление проектами" и не имеет никакого отношения к основному вопросу.

[ОБНОВЛЕНИЕ]: Спасибо за ваши отзывы.
Теперь есть больше вопросов, которые появляются вверх

  • Как бы вы назначили разработчиков для разработки новых приложений?
  • Должно существовать специальное одноразовое подразделение обновления, которое будет конвертировать устаревшие приложения для новых? Или следует каждый разработчик участвует в процесс преобразования?
  • Должны ли только старшие разработчики участвовать в конверсии? юниор Разработчики? или смешанные?

Похоже, чем больше я думаю о эта проблема, больше вопросов просто показывают вверх.

Ответы

Ответ 1

Понятно, что это важное мероприятие, которое потребует много работы.
Поэтому мой совет будет относиться к нему как к очень долгосрочному проекту.

У вас есть четкая цель, которая затрагивает такие важные проблемы, как безопасность, устойчивость, ремонтопригодность и будущее ваших приложений.

Как только это будет согласовано заинтересованными сторонами, разработайте прототипную систему для проверки ваших предположений, где вы можете попробовать С# vrs VB.net или MVC vrs Webforms. Я бы назначил для этого лучших разработчиков.

Затем запустите одну из своих небольших устаревших систем и создайте основные компоненты, которые вы будете повторно использовать в других областях.
На этом этапе, начните с более старших разработчиков, но каждый должен принять участие и ознакомиться с новой структурой.
Это гарантирует, что каждый будет обучен одновременно, и никто не останется позади.
В зависимости от того, сколько приложений у вас есть, я бы поменял разработчиков, поэтому все системы могут выиграть.

Также вся новая работа должна быть выполнена на вашем языке .net, а не на VB6.

Постепенно преобразуйте каждое из ваших устаревших приложений. (Я бы только преобразовал их, если они меняются, или если есть явная польза для их обновления.)

Это должно дать вам прочную основу для использования в будущем, при этом все еще не гарантируя, что ваши пользователи не будут препятствовать миграции.

Например:
Я работал в компании, где было около 40 приложений VB.
Со временем мы перенесли все это на С#, а теперь (через 5 лет) у нас примерно 150 приложений С# (все в .net 2.).

Все они имеют общую структуру, что упрощает их поддержку и расширяется там, где это необходимо.

Ответ 2

Попробуйте заменить основные функциональные возможности библиотеками .NET с поддержкой COM. "Пустотелые" существующие приложения VB6, поменяв функциональность до .NET по-разному.

Опасайтесь полного перезаписи. Хотя они заманчивы "потому что это чистый срез" - обычно безумие впереди! В качестве подготовки прочитайте "Эффективно работая с устаревшим кодом" Майкла Перса. Хотя книга специально не переходит в "переход от одного языка к другому", она действительно показывает много подводных камней в реальном мире, с которыми вы столкнетесь.

Я действительно думаю, что все разработчики должны были определить временные интервалы, в которых они выполняют миграционную работу над устаревшими приложениями, которые они разрабатывали ранее. Поскольку они уже имеют знания домена и знают проблемное пространство, они должны быть наиболее продуктивными.

Ответ 3

Ниже приведена адаптация моего к аналогичному вопросу.

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

... и здесь сообщение в блоге Microsofty, в котором соглашается со мной:

Многие компании, с которыми я работал в первые дни работы .NET, сначала смотрели на переписывание, отчасти обусловленное сильным желанием улучшить базовую архитектуру и структуры кода одновременно с переходом на .NET. К сожалению, многие из этих проектов столкнулись с трудностями, и некоторые из них никогда не были завершены. Проблема, которую они пытались решить, была слишком большой

Эта отличная Microsoft страница рекомендует двум сторонним средствам миграции лучше, чем маломощный встроенный мастер обновления VB.NET - Artinsoft и CodeArchitects VBMigration. Artinsoft написала встроенный мастер обновления VB.NET, это их улучшенная версия. И CodeArchitects был основан Франческо Балена, который написал некоторые из классических книг на VB6 и VB.NET.

На той же странице Microsoft также говорится:

Выполнение полного переписывания в .NET намного более дорогостоящее и сложное для достижения наилучшего результата [чем конвертирование]... мы бы рекомендовали этот подход только для небольшого числа ситуаций.


РЕДАКТОР: Сун говорит в комментариях: "Я не большой поклонник автогенерации кода, потому что его отлаживать изначально сложнее и может занять столько времени, сколько потребуется, чтобы переписать всю вещь". Я должен не согласиться. В общем, я тоже не поклонник генерации кода, но в этом случае полученный код будет структурирован идентично вашему оригинальному VB6 и должен быть почти полностью функциональным. Я еще не пробовал эти инструменты самостоятельно, но из их клиент отзывы это обещание выполнено.

И я повторяю совет Microsoft чуть выше, основываясь на их опыте оказания помощи во многих миграциях - "полная переписывание гораздо более дорогостоящая и трудная, чем преобразование [мой акцент]" - плоское противоречие предположение, что это может занять одно и то же время. Если вы хотите улучшить структуру VB6, миграция, то постепенный рефакторинг, вероятно, будет намного более экономически выгодным, чем переписывание.

Ответ 4

Смотрите это:
https://stackoverflow.com/questions/507291/should-we-select-vb-net-or-c-when-upgrading-our-legacy-apps

Конечно, С# vs VB.Net - это лишь одна его часть.

Например, еще одна вещь, которую следует учитывать, - это если вы хотите использовать эту возможность для перемещения этих приложений в интрасеть, если вы еще этого не сделали. Или насколько глубоко вы хотите вникать в стек Microsoft. Является ли Winforms достаточно или вы хотите использовать WPF, например.