Как перенести некрасивый и недокументированный код VB6 в .NET

Мне пришлось пройти одно и то же (массивное приложение VB6 без документации и ужасного кода.). Единственный безопасный и разумный маршрут, который вы можете взять, это номер 3. Чтобы улучшить то, что вы должны сначала понять это. Если вы возьмете маршрут 1 или 2, вам гарантированно остается ужасным беспорядком.

Не забывайте всегда держать идею в глубине своего ума, что ваша конечная цель - полная миграция .NET. Как вы рефакторируете, подумайте о том, как в VB.Net или C # будет выглядеть ужасная поддержка VB6S или C #. Если возможно, сдвиньте ваш код, чтобы проще миграцию.

Вы можете захотеть рассмотреть возможность переключения большого количества ваших основных функций в .NET DLL и обнажив его на VB6 через COM. Это удалит смешную сумму кода из вашего VB6 и, надеюсь, оставит в основном бизнес-логику.

Самое важное, что вам нужно помнить, это не будь ковбой.

1. Написать тесты для модуля.
2. Refactor модуль.
3. Проверьте модуль.
4. Отпустите свое приложение.
5. Goto 1

Опытный аналогичный мигрирующий 14-летний код в VS2008

вот несколько советов:

1. Удалите зависимости на 3-х компонентах сторонников.
2. Считайте поэтапную миграцию E.g. Использование обратного взаимодействия.
3. Цвета и шрифты должны быть рассмотрены вручную.
4. Следите за неинициализированными объектами в массивах после миграции к .NET
5. Изменение ошибки, чтобы попробовать улов
6. Использовать использование пространства имен Microsoft.visualBasic.comPatibility.vb6, где это необходимо.
7. Продолжайте рефакторинг до минимума до тех пор, пока весь код не преобразуется в .NET
8. , следите за ненулевыми массивами в вашем коде VB6.
9. Refactor (минимальный) Ваш код в VB6, поэтому он может пройти через мастер преобразования кода.
10. Следите за 1 на базе контроля VB6 E.g. ListView
11. Используйте Synclock, чтобы избежать проблем с резьбой.
12. Если вы выполняете ручной рефактором саб, то, будьте осторожны с изменениями размеров типа данных, особенно если вы работаете с файлом IO.

Есть компания, которая может помочь вам во всем процессе (хотя мы их не использовали) http://www.vbmigration.com/

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

Я бы посмотрел на рефакторинг кода медленно, но просто. Начать маленький. Это удивительно, как быстро вы можете ревертировать код в чем-то, что гораздо более управляемым. И вы должны быть в состоянии сохранить код «Работа» в конце каждого блока Refractoring, который вы делаете.

Обновление: Стоит отметить, что автоматизированная миграция будет перемещать только ваши проблемы на другой язык.

. Код абсолютно должен быть мигрирован? Если это не так, по-прежнему служит ее назначению, а на полпути ремонсируется, только оставить его в одиночку и двигаться дальше .

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

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

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

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

Check out M. Feathers' "Effectively Workingly with Legacy Code" -- в нем обсуждаются подводные камни усиления, рефакторинга и миграции и непроверенного кода.

Вы можете создать частную статическую функцию

@implementation Car 

static createBlueCar () {
  ....
}

+(Car*) createCar:(int) color{
   if (color==1) {
     return createBlueCar();
   } ...
}

@end

, но нет, вы не можете создать настоящий элемент . (Вы можете вызвать некоторые конвенции E.g. + (Car *) Private_createCar в частной категории, чтобы отговорить его использование.)

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

Ответ заключается в создании структуры, которая позволит вам вырезать разделы программы одновременно и преобразовывать их один за другим.

E.G. Вставьте файл адаптера базы данных «Layer», который обрабатывает все вызовы в базе данных, затем один за другим, удаляйте каждый, но SQL и замените его вызовом на слой DB. Старые вызовы все равно будут прямыми, пока новые звонки проходят через слой. В конце концов все звонки будут проходить через слой, и вы можете изменить бэкэнд БД.

Вы можете сделать то же самое с любым другим секцией кода, расширяя структуру «слой», чтобы покрыть эту функциональность.

Ключ для переключения его из VB6 в VB.Net (например) - использовать библиотеку взаимодействия - вот одна статья: http://support.microsoft.com/kb/817248

Другой, Гораздо позже мысль: получим MZ-Tools и используйте их инструмент анализа, чтобы найти избыточный код и избавиться от него. Мне удалось устранить что-то вроде пяти до десяти процентов кода в старом устаревшем продукте в моей компании.

Из вашего описания этого проекта звучит так, будто это может быть возможно для вас рефактором и мигрировать одновременно. Вы явно собираетесь принимать большое количество избыточного кода и консолидировать его; Вероятно, что как часть консолидации вы также можете переписать его (избыточный код, то есть) в .NET.

Это не будет работать для пользовательских пользователей. Но это будет для базы данных и бизнес-логики. Например, я не видел ваш код, но я сделаю ставку складной деньги, которые большинство комбинированных коробок в вашем приложении, которые наследуются методами в их форме (вероятно, скопированы и вставляются в form_load ), которые создают ADO ), которые создают ADO Recordsets и петля через них. Это то, что может быть восстановлено в класс доступа к данным .NET и с легкостью интегрировано в существующие формы. Он также, вероятно, позволит вам представить магический мир кэширования в этом приложении, что будет неплохо, потому что, вероятно, приведет к видимым улучшениям производительности.

И видимые улучшения важны. Если ваше управление полностью не должно участвовать в необходимости выполнения этого, это очень высокий риск. Это очень плохо, если вы узнаете о своем руководстве, что данный CR займет больше времени для реализации, чем они ожидают из-за проблем в вашей рефакторинге. Даже если у вас есть полная поддержка, вы не хотите, чтобы эта ситуация возникла, но это намного хуже, если ваша поддержка является частичной. Видимые улучшения будут многое сделать, чтобы смягчить это.

Кроме того, есть растущее тело литературы по проблеме рефакторинга наследие. Вы должны быть на вершине этого. Чем больше вы знаете, прежде чем погрузиться в это, тем лучше будет ваш опыт. Я сам не читал книги Майкла перьев, но если бы я был на твоем месте, это первое, что я бы сделал.

вы отлично постарались сформулировать этот вопрос. Спасибо, что спросили! И спасибо сообществу stackoverflow за размещение вдумчивых ответов (как обычно).

Если это довольно большая кодовая база, и похоже, что так и есть (50-100 взаимосвязанных VBP, 200-500K LOC), то вам стоит подумать об инвестировании в инструменты миграции. Рассмотрим эту аналогию: если бы у вас было большое количество данных для конвертирования, даже если исходные данные были грязными и сильно отличались от требуемого формата, вы бы использовали инструменты. Если бы кто-то предложил вам просто ввести данные заново, или даже сделать черновик, а затем исправить его вручную, вы бы подумали, что это безумие. Кроме того, с помощью 120 форм, приложение звучит так, как будто оно предоставляет довольно значительный объем бизнес-функций. Эта бизнес-функциональность появилась за многие годы использования, и, нравится вам это или нет, код VB6 представляет собой полную, формальную и проверенную временем спецификацию этой функциональности, а также бесчисленные технические факты о том, как приложение работает за кулисами. Сбор, перекодировка и повторное тестирование всех этих функциональных/технических требований "с нуля" очень дорого и сложно. Для того, чтобы управлять стоимостью и риском проекта, необходимо "обналичивать" унаследованный код. Вопрос в том, как это сделать, а также обеспечить более низкую стоимость владения после миграции.

Проблема связана не столько с размером кодовой базы, сколько с деталями редизайна, необходимого для адаптации и использования преимуществ .NET. Необходимо определить конкретные вещи, которые делают код VB6 "некрасивым", почему он "некрасивый", и как вы должны/должны/желают делать эти вещи по-другому в .NET. Как только Вы начнете формулировать эти требования к перепроектированию, Вы можете начать внедрять их в Ваш процесс преобразования, чтобы они появились в Вашем коде .NET. Общий подход, за который мы выступаем, называется "tool-assisted rewrite" и выполняется следующим образом:

1. запустите трансляцию
2. build/review/testest генерируемого кода для выявления/изменения необходимых улучшений кода
3. если генерируемый код "достаточно хорош", то завершите работу в . NET
4. переконфигурируйте транслятор для реализации необходимых улучшений (если необходимо)
5. goto 1

Вывод инструмента не обязательно должен быть "идеальным" (программное обеспечение никогда не бывает...), оно просто должно быть "достаточно хорошим". То, что является "достаточно хорошим", упомянутым в шаге 3, является критическим вопросом. По сути, это означает, что качество кода - с точки зрения функциональной корректности и соответствия вашим стандартам - таково, что команда разработчиков знает, что потребуется, чтобы закончить миграцию и затем продолжить работу/поддержку приложения - И они уверены, что смогут сделать это в рамках заданных ограничений по времени и ресурсам. Для очень большой кодовой базы "достаточно хорошо" - это "очень хорошо", потому что просто слишком дорого и рискованно пытаться закончить и впоследствии поддерживать миграцию низкого качества. В общем, чем больше код и чем меньше бюджет, тем более эффективным должен быть ваш процесс миграции.

Также есть некоторые мысли о том, чтобы "закончить работу в .NET": Наличие хорошо сформированного кода в .NET является важной вехой. В сообществе .NET есть хорошие инструменты рефакторинга, анализа и юнит-тестирования, которые помогут Вам ускорить процесс завершения миграции. Вы будете использовать Visual Studio на самых ранних этапах процесса для экспериментов и доработки рефакторинга, а также для отладки/тестирования приложения. Возможность работать со всей вашей кодовой базой в .NET и с Visual Studio на ранних стадиях миграции является ключевым преимуществом (и важной частью) подхода с использованием инструментов.

Конечно, для того, чтобы это стало возможным, вы должны иметь возможность инвестировать средства в набор инструментов для миграции, который специально разработан для поддержки перезаписи с помощью инструментов. Инструмент из Great Migrations - единственный инструмент, о котором я знаю в этой категории.

Отказ от ответственности: я работаю на Great Migrations. На нашем сайте есть гораздо больше информации - в том числе примеры того, как инструмент использовался для миграции более 1M LOC VB6 для реинжиниринга C#, а также руководство пользователя gmStudio, в котором детально описывается продукт и методология.

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

Как уже упоминалось другими, важно понимать, что процесс миграции не улучшит автоматически качество кода. Поэтому, если ваша основная цель - провести рефакторинг (и ничего больше), вы должны знать, что могут пройти недели или месяцы, прежде чем у вас появится функционально эквивалентный код (в зависимости от размера кода и сложности миграции).

При этом в .NET есть несколько очень хороших инструментов для рефакторинга и анализа кода, помимо наборов модульных тестов. Инструменты автоматического преобразования, такие как ArtinSoft Visual Basic Upgrade Companion , можно настроить для обеспечения соблюдения стандартов кодирования или значительного улучшения кода во время преобразования. Это в сочетании с другими инструментами модификации кода, такими как ReSharper , значительно ускорит ваш переход на .NET.

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

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

По сути, любые новые пользовательские элементы управления должны быть написаны на .NET и представлены как элементы управления ActiveX для использования приложением VB6. Точно так же новые функции DLL следует размещать в сборках .NET, которые можно использовать через COM. Таким образом, когда придет время для миграции, вам не придется беспокоиться об этих элементах управления или библиотеках.