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

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

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

Я взял на себя обслуживание приложения VB6/SQL.
Всего строк кода составляет 75-100 тыс. (коды, модули и классы).
Исходный разработчик ушел, так что это только я, и там нет возможности расширить команду, по крайней мере, на несколько лет.
В программе не было архитектуры (просто прямые вызовы SQL в виде простого текста в виде кода).
Не пытается следовать принципам DRY или OAOO.
В базе данных были первичные ключи, но не внешние ключи.
До того, как эта система была на месте, все управлялось большими таблицами, поэтому эта система действительно значительно улучшилась по сравнению с тем, что у них было, но не делает того, что они предполагают.
Я смог написать несколько инструментов, чтобы заменить все литералы экземпляров имен таблиц и имен столбцов на константы и поисковые запросы, и я написал быстрый код gen script, чтобы сгенерировать эти константы и поисковые запросы из базы данных, поэтому теперь я могу безопасно делать изменения в базе данных и видеть повсюду, что сломалось. Я начал нормализовать базу данных "по краям", но это похоже на 3% пути.
Нет никаких модульных тестов, поэтому каждый раз, когда я меняю базу данных, я в основном должен переписать любую логику, расположенную поверх нее, и я использую две версии, чтобы сравнить функциональность и убедиться, что она та же. Пока все хорошо.
Я начал с того, что пытался исправить критические ошибки, чтобы остановить кровотечение, и я могу с уверенностью сказать, что в основном это сделано, поэтому теперь я отступаю на мгновение, чтобы посмотреть на общую картину.
Руководство поддерживает и оправдывает свои ожидания.
Долгосрочная цель - конвертировать его в .NET в любом случае...

Итак, я взвешиваю эти параметры:

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

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

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

Рядом с общей потерей текущих инвестиций
Может вводить дефекты, которые были решены в прошлом.

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

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

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

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

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

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

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

Ответ 8

The long-term goal is to convert it to .NET anyway...

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

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

Ответ 9

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

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

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

Ответ 10

Прежде всего, вы бедный s * d. никогда не было прекрасным местом для посещения.

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

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

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

Ответ 11

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

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