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

Question

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

Текущая ситуация:

• Я взял на себя обслуживание приложения VB6 / SQL.
• Общее количество строк кода составляет 75-100 КБ (кодовые компоненты, модули и классы).
• Первоначальный разработчик ушел, так что это только я, и нет возможности расширить команду, по крайней мере, на несколько лет.
• Не было никакой архитектуры для программы (только прямые вызовы SQL в виде простого текста в виде выделенных кодов).
• Не пытается следовать принципам СУХОЙ или ОАОО.
• База данных имела несколько первичных ключей, но не имела внешних ключей.
• До того, как эта система была на месте, все управлялось в больших электронных таблицах, поэтому эта система на самом деле является огромным улучшением по сравнению с тем, что у них было, но не выполняет то, что они предусмотрели.
• Мне удалось написать несколько инструментов для замены всех буквальных экземпляров имен таблиц и имен столбцов константами и поисками, и я написал скрипт быстрого генерации кода для генерации этих констант и поисков из базы данных, поэтому теперь я могу смело вносить изменения в базу данных и видеть везде, что сломалось. Я начал нормализовать базу данных "по краям", но это примерно 3% пути.
• Нет модульных тестов, поэтому каждый раз, когда я меняю базу данных, мне приходится переписывать любую логику, расположенную поверх нее, и я использую две версии для сравнения функциональности и проверки того, что она одинакова. Пока все хорошо.
• Я начал с того, что попытался исправить критические ошибки, чтобы остановить кровотечение, и я могу с уверенностью сказать, что это в основном сделано, поэтому сейчас я на секунду отступаю, чтобы посмотреть на общую картину.
• Руководство поддерживает и оправдывает свои ожидания.
• Долгосрочная цель в любом случае - преобразовать его в .NET ...

Итак, я взвешиваю следующие варианты:

1. Продолжайте нормализовать базу данных и вносить изменения в приложение VB6, пока я работаю (в конечном итоге это происходит по частям)
2. Переведите VB6 в состояние только для обслуживания (без новых функций), выберите один функциональный модуль за раз и переписайте эту часть в .NET поверх нормализованной структуры базы данных.

Я думаю, что если я выберу вариант 1, то в конце у меня просто будет приложение VB6, которое они все еще хотят обновить до .NET, и я посмотрел на это, и это дорого и требует много времени, и даже с инструменты вы все равно получите что-то вроде Франкенштейна. Если я перейду к варианту 2, я думаю, что с этим можно будет покончить быстрее, и я перейду прямо к целевой технологии.

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

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

Итак, это квалифицируется как один из тех "один из десяти" раз или нет?

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

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

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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

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

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

Answer 9

Прежде всего - бедняжка.Никогда не хорошее место, чтобы быть оставленным на.

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

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

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

Answer 10

Может быть. Для начала вы скажете: «Не пытайтесь следовать принципам СУХОЙ или ОАОО», так что сразу, возможно, существует много избыточности, которая может быть подвергнута рефакторингу, но если вы переписываете в .NET, вам не придется рефакторинг , Кроме того, счет LOC, вероятно, раздут из-за этой проблемы.

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

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