Вы бы заново разработали полностью под .net?

Question

Очень обширное приложение началось как система на основе доступа (для хранения базы данных). Формы были написаны в VB5 и/или VB6. Поскольку .NET стал приспособлением в сообществе разработчиков, некоторые модули были переписаны. Это кажется очень неловким и потенциально дорогостоящим просто для поддержания из-за межтехнологий и дополнительной работы, чтобы две технологии были довольны друг от друга. Конечно, в приложении используется смесь ODBC OLEDB и MySQL.

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

ОбновлятьПриложение использует OLEDB и MySQL - я исправил свое предыдущее утверждение.

Кроме того, чтобы предоставить дополнительную поддержку для переписывания: я с тех пор узнал, что когда "портирование" На начало .NET существующий код VBA/VB6 был в основном переведен в эквивалент .NET. На мой взгляд, ничего не было сделано для повышения производительности или воспользования новыми библиотеками или технологиями.

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

Answer 1

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

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

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

Answer 2

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

1. Функции продукта сохраняются.
2. Способность доставить новый релиз поддерживается.
3. Временное давление удаляется.

Удачи

Answer 3

Как правило, это обескураженная практика - «переписать» приложение с нуля (которое является нормальным побуждением, которое большинство программистов чувствовали хотя бы несколько раз за всю жизнь), потому что вы переходите из приложения с известным набором функций (и известными ошибками!) к приложению с наиболее вероятном меньшим набором функций и, что более важно - неизвестные ошибки. Пользователи могут разочароваться и т. Д.

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

Answer 4

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

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

Answer 5

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

Хотя это не может быть прибыльным с точки зрения разработки, как распространяются различные приложения, поражающие пользователей? Требуется ли больше обучения пользователей? Они делают больше ошибок. Увеличивает ли это количество вызовов поддержки, потому что они не могут что -то найти?

Answer 6

«Вы бы подумали, что тратить время и ресурсы на полное повторное развитие приложения в соответствии с .NET будет более экономически эффективным?»

Это не вопрос, на который можно ответить здесь.

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

Это способ сделать это. Если для этого нет бизнес -плана. Затем ответ состоит в том, чтобы сначала работать над бизнес -планом, отслеживаемым некоторыми вариантами использования высокого уровня, чтобы сделать анализ воздействия, чтобы проверить начало проекта.

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

Если нет бизнес -плана, но «это просто сделано», тогда попробуйте сделать его и представить его высшему управлению. Включите высокий уровень использования случаев, затраты, часы для редизайна, сборку, дополнительные затраты на операции, новое обучение для администратора и эндосов, управление проектами и потенциальные риски.

ИМХО это не технический вопрос.