Программное решение 2000-х, я должен попытаться исправить или переделать все это?

9

Меня послали обсудить систему, которую в настоящее время использует определенная компания, и что с ней делать.

Компания производит различные картонные дисплеи. Эта система была разработана для отслеживания клиентов, заказов и цен. Многое произошло с тех пор, как система была создана, и теперь система, как ее описал менеджер, « заблокирована » и « проблематична », что я перевожу как «не динамический» и «нестабильный».

Некоторая информация о системе

  • Он был разработан около 2000 года
  • Довольно маленькая система, 2-5 пользователей, 6 форм, ~ 8 таблиц со средним количеством данных
  • Построенные на ранних версиях Visual Basic, формы, созданные с помощью перетаскивания. Интерфейс в основном просто окно с меню и некоторыми формами
  • Использует базу данных MSSQL (сервер SQL2005) для хранения данных и драйвер ODBC для запроса, данные были перенесены из Excel до этой системы, а до того, как Excel был обработан, рассчитан и записан вручную и на бумаге
  • Пользователи работают в среде Microsoft XP (и выше)

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

Я предложил 3 возможных решения

  1. Попытка исправить текущую систему
  2. Создать новый новый интерфейс (желательно аналогичную среду на основе VB.net или VB)
  3. Верните его в решение Excel, учитывая, что это такая маленькая система

Там может быть больше вариантов, но это те, которые я мог придумать.

Мои вопросы

  • Что я должен рекомендовать и почему?
  • Каковы или могут быть плюсы и минусы этих альтернатив?
  • Есть ли другие (возможно, лучшие) альтернативы?
ShadowScripter
источник
3
Вы не можете решить, насколько сильно сломана текущая система, пока не задокументируете схемы базы данных.
@ ThorbjørnRavnAndersen Это правда. Я только заглянул в базу данных. Судя по возрасту, в котором он был создан, я предполагаю, что он действительно ужасно спроектирован и нуждается в первой помощи ... или в операции.
ShadowScripter
1
Вы знаете, кто написал оригинальную систему? Было ли это внутренним усилием или было заключено соглашение?
maple_shaft
7
Не делай этого. Сообщите клиенту, что состояние базы данных имеет решающее значение для стоимости различных опций и должно выполняться независимо от того, какой вариант они выбирают. Даже для переписывания с нуля они, скорее всего, хотят, чтобы их данные были перенесены.
4
Разработчикам по умолчанию нравится «переписывать с нуля» и рефакторинг только при необходимости. Я бы предпочел по умолчанию «постепенно реорганизовывать» и переписывать только при необходимости.
Quant_dev

Ответы:

5

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

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

jfrankcarr
источник
Учитывая его небольшой размер, я согласен. На первый взгляд, это тоже не кажется слишком сложным. Судя по ответам, переписывание кажется наиболее подходящим. Я посмотрю поближе, прежде чем принять окончательное решение. Спасибо за совет! :)
ShadowScripter
@ShadowScripter Я бы посмотрел на то, чтобы написать это на более хорошем языке, чем VB, пока вы на нем. Проверьте проект с открытым исходным кодом Lazarus .
Спенсер Ратбун
5

У меня немного другой совет, большинство ответов до сих пор.

Попытка исправить текущую систему

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

Создать новый новый интерфейс (желательно аналогичную среду на основе VB.net или VB)

После того, как вы узнали все, что вы можете с их текущей настройкой. Предоставьте им варианты, если вы можете решить их проблемы с их текущей системой, в их текущей системе нет ничего плохого. Единственная проблема, конечно, заключается в том, что поддержка Visual Basic 6 может отсутствовать в течение 5 лет.

Другой проблемой является то, как он взаимодействует с базой данных. Microsoft постепенно избавляется от некоторых старых способов взаимодействия со своими продуктами баз данных (Access, MSSQL), поэтому способ взаимодействия с этими продуктами будет определять, будет ли решение использоваться в Windows 9 и Windows 10 в будущем.

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

Я не чувствую, что в приложении Visual Basic 6 есть что-то «не так», кроме того, его поддержка будущих версий неизвестна. Даже сегодня с Windows 7 и 64-битными операционными системами его становится все труднее поддерживать. Это основная причина, по которой переписывание на современный язык с надлежащей 64-битной поддержкой может быть хорошей идеей.

Если у них нет источника на тот момент, переписывание действительно является их единственным решением.

Ramhound
источник
Не могли бы вы привести ссылку на " Microsoft is slowly getting rid of some of the older ways to communicate..."? Хотел бы прочитать больше об этом.
ShadowScripter
@ShadowScripter - Например, поставщик Microsoft.Jet.OLEDB.4.0 для доступа к устаревшим файлам базы данных Access не поддерживается, если этот процесс не является 32-разрядным процессом. WinRT также может изменить способ подключения к этим продуктам Microsoft. Я забыл, где я читал о будущих изменениях, я понимаю, что после MSSQL 2012 Microsoft будет поддерживать только конкретный способ подключения к нему. Это, конечно, в контексте провайдеров, встроенных в Windows и ее предложений по разработке
Ramhound
1

Переписать интерфейс - отличный вариант, учитывая, что система относительно мала. Преимущества -

  1. Улучшена стабильность (если вы делаете это хорошо!)
  2. Улучшенная ремонтопригодность
  3. Современный интерфейс

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

Крейг Шварц
источник
Переписывание интерфейса - это то, к чему я тоже склонялся. И, честно говоря, я не уверен, с чего бы начать со старого интерфейса, судя по сегодняшним стандартам, просто так ... все плохо.
ShadowScripter
1

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

Когда-то я работал над тем, что должно было быть «веб-сайтом», но на самом деле с конца 1990-х годов брал на вооружение инструмент в стиле CRM, основанный на Access, и переносил его в современный веб-мир. Первоначальный разработчик давно ушел, база данных была изменена множество раз, поэтому оригинальная документация устарела, и никто не понимал, как работает система. Но они знали, как им пользоваться, просто. Вероятно, 80% бюджета на этот проект ушло на три вещи:

  • сбор требований
  • понимание существующей системы
  • придумать осмысленную схему базы данных о том, как они намеревались использовать программное обеспечение

Проект в финансовом отношении не имел успеха!

ZweiBlumen
источник
Я слышу, что вы говорите: прежде чем я приму окончательное решение, мне нужно быть полностью осведомленным о его нынешних недостатках, функциях и целях. Не то, чтобы я хотел пойти ва-банк, с оружием, пылающим, кричащим All right, let's do this. LEEEEEEEROOOOOOOY...! : P
ShadowScripter
0

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

Дайте им новую функциональность в новом приложении, построенном с нуля.

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

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

Это может быть более приемлемый подход.

Ozz
источник
1
Я полагаю, что это хорошая идея, но если второй этап никогда не произойдет, они получат старое отдельное приложение, которое зависит от другого нового приложения, оставив их с двумя приложениями, что удвоит проблему.
ShadowScripter
0

Перезаписи часто имеют тенденцию исчерпывать бюджет ... Плохо.

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

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

кодировщик
источник