Это один раз из десяти переписать?

У меня был проект, изначально написанный на VB6, и меня наняли, чтобы преобразовать его в .NET. Недавно я ушел с этой работы. Я вполне убежден, что программу, вероятно, не стоило переписывать.

Вот некоторые факторы, которые следует учитывать, если вы выберете метод перезаписи (на основе моего проекта)

• Прямой перезаписи не будет. Как только станет известно, что он будет переписан, появятся новые запросы функций, и будет изрядное количество редизайна / реархитектуры.
• Люди не примут режим «только обслуживание» без большого сопротивления. Какое-то время каждая ошибка будет критически важной.
• Перенос приложения VB6 в .Net НЕ следует рассматривать как более легкий, чем перенос приложения C++ в .Net или проекта Haskell в .Net. Есть некоторая общность, но в итоге кодовая база отличается на 99 % (возможно, 1 % для существующих уравнений).
• Предполагая, что эта программа находится в производстве (даже внутри компании), ваша новая программа, скорее всего, не будет соответствовать требованиям, по крайней мере, на начальном этапе. Вы услышите "Но по-старому..." или "Раньше..."
• Assuming your customers are not other IT people, they WILL NOT understand:
  • What is taking so long
  • Почему это не похоже на программу (по внешнему виду) старой
• Хотя текущее приложение разрабатывалось с течением времени, скорее всего, ожидается, что ваше приложение будет иметь 100% функциональности при вводе в эксплуатацию и за меньшее время.

Все это опыт реальной миграции с VB6 на .Net. Я был единственным разработчиком .Net. Не было ресурсов, чтобы нанять дополнительную помощь. Основные различия между моей ситуацией и вашей: 1. первоначальный разработчик все еще был там - просто в новой роли (иногда это усложняло задачу) и 2. оригинальное приложение не нуждалось в большом количестве исправлений ошибок.

Я думаю, что если бы мне пришлось делать это снова, я бы попытался создать несколько .NET dll и включить их в приложение VB6. По частям переходим на .net. Так что, возможно, вы переместите данные и бизнес-логику для расчетов с клиентами в .NET. Все остальные аспекты остаются прежними. Графический интерфейс, другие функции и т. Д. Затем, после того, как это будет развернуто и помечено как завершенное, перейдите в раздел «Доставка» и сделайте то же самое. Последним шагом является создание нового графического интерфейса .NET, использующего ваши библиотеки DLL.

Это дает вам пару преимуществ

• В итоге приложение написано на .NET
• Позволяет медленно внедрять изменения. Вы не будете отлаживать отгрузку и дебиторскую задолженность, HR и т. Д. Все в одно и то же время недели «ввода в эксплуатацию»
• Позволяет использовать более современные инструменты, не нарушая работу всей программы. Хотите использовать NHibernate, PLINQ или MEF? Делайте это по одному модулю за раз. Изучите инструмент и делайте маленькие шаги
• Обеспечивает гибкость графического интерфейса. В конце концов, вы можете сделать WinForms, WPF или веб-проект, используя ваши основные библиотеки DLL.
• Не бросает тонну изменений пользователю сразу. Вы переписали эту часть дебиторской задолженности, и пользователь понятия не имеет, потому что графический интерфейс тот же. Затем, когда вы развертываете графический интерфейс, вы ЗНАЕТЕ, что ваш сервер работает.
• Упростит будущий рефакторинг. Вы уже разбили свой проект на небольшие куски. Вы можете продолжить работу над ними, зная, на что они влияют и т. д.

Я был бы ОЧЕНЬ утомлен, решая, как один разработчик, переписать это приложение и предоставить им работающий продукт. Я думаю, что по консервативной оценке (при условии отсутствия расширения масштабов и т. д.) это будет 24 месяца. Скорее всего 3-4 года.

Над проектом, который я оставил, работали 3 года, и его можно было обслуживать, но он еще не стал 100% заменой оригинального приложения. Как я уже сказал... хотя это означало бы, что у меня не будет работы, я не думаю, что это нужно было переписывать.

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

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

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

После того, как у вас будет твердая база данных, я думаю, что лучшим сценарием было бы попытаться разбить код на отдельные и многократно используемые сборки (которые вы должны иметь возможность использовать в .NET), а затем постепенно преобразовать их в .NET из VB. Это может быть невозможно, если код ужасно пахнет спагетти!

Начните преобразовывать различные модули по одному, выводя их из приложения VB6.

Расставьте приоритеты в соответствии с тем, что является критически важным/стратегическим, чтобы вы также могли добавлять ценность по мере продвижения.

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

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

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

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

Клиенты могут получить следующее

1. более быстрое устранение дефектов/улучшений.
2. Меньшая вероятность появления новых дефектов во время развертывания
3. Большой пул разработчиков для найма
4. Может быть в состоянии реализовать функции, которые были невозможны в прошлом

Затраты/Риски

1. Почти полная потеря текущих инвестиций
2. Может внести дефекты, которые были устранены в прошлом.

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

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

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

1). Это VB6, разработка которого MS прекратила два года назад (ref) . Они его не поддерживают, поэтому и вы не должны его поддерживать, и именно поэтому программное обеспечение никогда не заканчивается.

2). Объем кода не имеет значения — сложность рефакторинга или переписывания приложения зависит от его размера.

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

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

5). Отсутствие модульных тестов — еще один серьезный риск, поскольку вы не сможете доверять никаким изменениям, которые вносите. Это первое, что вам нужно изменить, какой бы подход вы ни выбрали.

6). Если у вас есть одобрение руководства и стратегическое желание перейти на .NET, тогда у вас действительно нет причин не переписывать.

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

Удачи солдат.

Может быть. Для начала вы говорите: «Не пытается следовать принципам DRY или OAOO», так что сразу же появляется много избыточности, которую можно было бы реорганизовать, но если бы вы переписали на .NET, вам не пришлось бы рефакторить . Кроме того, количество LOC, вероятно, раздуто из-за этой проблемы.

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

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

Во-первых, ты бедный s*d. никогда не хорошее место, чтобы быть брошенным на.

Тем не менее, это действительно звучит так, как будто вы схватили быка за рога и следуете устойчивому курсу. У меня возникло бы искушение добавить, что VB6 больше не будет поддерживаться в следующем году (насколько я помню), что будет означать, что если приложение выйдет из строя в результате изменений ОС, то вы в основном застрянете. Кроме того, я бы попытался увидеть, сколько параллельных разработок вы можете провести с этим в .net, поскольку взаимодействие не должно (знаменитые последние слова) быть слишком сложным для работы.

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

Я добавлю больше деталей, когда смогу вернуться к теме.

Я бы выбрал маршрут «заморозить и написать новое приложение».

• Используйте столько кода/методов VB6, сколько сможете или сочтете нужным, из приложения VB6. Похоже, вы можете перейти на VB.NET, и некоторый код может пережить обновление. В любом случае, есть преобразователи кода, которые могут помочь.

• Начните редизайн базы данных. Напишите сценарии для преобразования данных в нормализованную форму, которая имеет для вас смысл.

• Затем запустите помодульную миграцию в новое приложение. Если вы можете помочь, не вносите больше изменений/исправлений/улучшений в новое приложение.

Долгосрочная цель - все равно преобразовать его в .NET...

Похоже, вы просто будете поддерживать старый код, пока не придет время перенести его на .NET. Так что сохраните некоторые работы и начните сегодня, переписать. Мои 2 цента.

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