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

Ответ 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, и некоторый код может пережить обновление. В любом случае, есть конвертеры кода, которые могут помочь.

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

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