Это «одно через десять ”времени переписать?

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

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

• Это не будет прямым переписыванием. Как только станет известно о его переписывании, появятся запросы на новые функции, и будет проведено изрядное количество редизайна / перепроектирования
• . Люди не примут режим «только для обслуживания» без большого сопротивления вначале. Какое-то время каждая ошибка будет «критически важной»
• . Перенос приложения VB6 в .Net НЕ следует рассматривать как более простой процесс, чем перенос приложения C ++ в .Net или проекта Haskell в .Net. Есть некоторая общность, но, в конце концов, кодовая база отличается на 99% (возможно, на 1% для существующих уравнений)
• Предполагая, что эта программа находится в производстве (даже внутри компании), ваша новая программа, скорее всего, не будет соответствовать требованиям, по крайней мере, изначально. Вы услышите «Но по-старому ...» или «Раньше ...»
• Если ваши клиенты не другие ИТ-специалисты, они НЕ поймут:
  • Что занимает так много времени
  • Почему это не похоже на программу (по внешнему виду) старого
• Несмотря на то, что текущее приложение разрабатывалось с течением времени, вероятно, ожидается, что ваше приложение будет иметь 100% функциональных возможностей при запуске и за меньшее время.

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

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

Это дает вам несколько преимуществ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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