Подтвердить что ты не робот

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

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

Я должен сказать, что качество, структура и архитектура кода - это просто кошмар. Есть 2 больших проекта: Nr.1 с 40 формами, 40 модулями и несколькими файлами классов, этот EXE является своего рода "базовой системой". Nr.2 с 80 формами, 20 модулями и несколькими файлами класса, эта функция EXE вызывает "базовую систему". Тогда есть ~ 10 других проектов с графическим интерфейсом (1-3 формы) и еще 90 проектов без GUI, большинство из которых - EXE файлы, некоторые DLL файлы. DLL записываются на C, С++ и VB6.

Кодекс развивается эволюционно с 10 лет и написан в основном одним (плохим) разработчиком за раз.

  • Функции с 500 строк (и более) очень распространены.
  • 90% компонентов GUI называются text1, command2 (1),...
  • копировать и вставлять повсюду e. г. проект EXE (без GUI) с 5000 строками кода был скопирован, и единственное изменение в копии заключалось в том, чтобы отправлять файлы в Mail вместо FTP (есть еще 2 копии того же проекта).
  • У меня когда-то была небольшая форма (15 полей), где я должен был решить небольшую проблему (обычно не более получаса), каждый раз, когда я что-то менял, это либо не работало, либо создавало новые ошибки в форма. Через 2 дня я решил полностью переписать форму и из ~ 20 SQL-заявлений в старой форме, только 2 остались в новой.
  • даже не спрашивайте о комментариях в коде...

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

Мои параметры

1) Перепишите с нуля. В этом случае я мог бы написать его на Java для переносимости. Проблема здесь в том, что помимо некоторой (старой) помощи пользователю нет документации, поэтому уродливый код - это "документация". Существует один Человек, который знает на высоком уровне, как это должно делать программное обеспечение. Также трудно убедить руководство в том, что он это сделает, даже если в долгосрочной перспективе будет огромная экономия средств, есть политические проблемы. Я также не могу сделать этот проект (vb) за раз, потому что структура базы данных не лучше, чем код, который тоже должен выполняться с нуля. Поэтому я могу сразу изменить все программное обеспечение.

2) Перенесите код в VB.NET/С# Перенос основных проектов во-первых, я протестировал это уже и получил ~ 2000 обновлений комментариев от Project Nr.1, большинство из них, такие как Screen.MousePointer, изменено, функции с вариантами возвращаемых значений и т.д. Моя идея здесь после преобразования, создания классов для абстракции БД, изменения кода для использования этих классов и рефакторинга, переноса и изменения других проектов, а также, когда весь код использует классы БД, измените структуру БД.

3) Реорганизуйте код в VB6 всякий раз, когда мне что-то нужно что-то менять (я уже делаю это частично), а в какой-то момент рефакторинг тоже остальное. Таким образом, легче видеть оригинальную функциональность, потому что это оригинальный код и когда есть ошибки, очевидно, что они не могут быть результатами миграции. Когда код реорганизуется (я предполагаю, что он будет на 50-75% меньше, а затем), проще переносить его на .NET. Затем измените структуру БД (а затем выполните еще один раунд рефакторинга...).

В будущем есть некоторые большие изменения (совместим с Win7 и еще один большой CR, который затрагивает большие части кода), поэтому была бы хорошая возможность сделать эти изменения, так как я буду иметь чтобы пройти через много кода.

Мой вопрос: у кого есть опыт/подсказки для переноса плохого, уродливого кода? Какие варианты вы бы предложили?

4b9b3361

ОТВЕТЫ

Ответ 1

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

Помните, что всегда держите идею в своей голове, что ваша конечная цель - полная миграция на .NET. Поскольку вы рефакторинг думаете о том, как VB6s ужасная поддержка OO будет выглядеть в VB.NET или С#. Если возможно, измените свой код, чтобы облегчить миграцию.

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

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

  • Напишите тесты для модуля.
  • Рефакторинг модуля.
  • Проверьте модуль.
  • Отпустите свое приложение.
  • GOTO 1

Ответ 2

Нужно ли полностью переносить код? Если он этого не делает, он все еще служит ему цели и на полпути обслуживается, просто оставьте его в покое и перейдите на.

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

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

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

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

Ответ 3

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

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

  • Удалить зависимости от сторонних компонентов.
  • Рассмотрим ступенчатую миграцию, например. используя обратный интерфейс.
  • Цвета и шрифты должны быть обработаны вручную.
  • Следите за неинициализированными объектами в массивах после перехода на .NET.
  • Изменить на ошибку, чтобы попытаться поймать
  • При необходимости используйте пространство имен Microsoft.VisualBasic.Compatibility.VB6.
  • Сохраняйте рефакторинг до минимума, пока весь код не будет преобразован в .NET.
  • Остерегайтесь ненулевых массивов в вашем коде VB6.
  • Refactor (минимально) ваш код в VB6, чтобы он мог пройти через мастер преобразования кода.
  • Следите за 1-мя элементами управления VB6, например. ListView
  • Используйте синхронизацию, чтобы избежать проблем с потоками.
  • Если вы выполняете ручной рефакторинг юнита, будьте осторожны с изменениями размеров данных, особенно если вы работаете с файлом IO.

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

Ответ 5

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

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

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

  • выполнить перевод
  • построить/просмотреть/протестировать сгенерированный код для определения/уточнения необходимых улучшений кода.
  • если сгенерированный код "достаточно хорош", goto завершает работу в .NET.
  • перенастроить переводчика для реализации необходимых улучшений (при необходимости)
  • goto 1

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

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

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

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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

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

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

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

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

Ответ 9

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

Я бы посмотрел на рефакторинг кода медленно, но просто. Начните с малого. Его удивительно, как быстро вы можете реорганизовать код в нечто более управляемое. И вы должны иметь возможность держать код "работающим" в конце каждого блока рефрактонирования, который вы делаете.

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