Програмне рішення 2000-х років, чи варто спробувати зафіксувати або переробити все?

Мене відправили обговорити систему, яку зараз використовує певна компанія, і що з нею потрібно робити.

Компанія виготовляє різні картонні вітрини. Ця система була розроблена для відстеження клієнтів, замовлень та цін. Багато часу трапилося з того часу, як система була створена, і система зараз, як описав її менеджер, " заблокована " і " проблемна ", що я перекладаю як "не динамічний" і "нестабільний".

Деякі відомості про систему

• Він був розроблений близько 2000 року
• Досить невелика система, 2-5 користувачів, 6 форм, ~ 8 таблиць із середньою кількістю даних
• Створені на ранньому Visual Basic, форми, створені за допомогою дизайну перетягування. Інтерфейс - це лише вікно з меню та деякими формами
• Використовує базу даних MSSQL (сервер SQL2005) для зберігання даних та драйвера ODBC для запиту, дані були переміщені з excel перед цією системою, а до того, як excel оброблявся, обчислювався та записувався вручну та на папері
• Користувачі працюють у середовищі Microsoft XP (і вище)

Їх основна проблема полягає в тому, що вони не можуть коригувати та обчислювати ціни, не можуть додавати нові типи коробки тощо, правильніше, тому що вони не можуть (точніше, не знають, як) торкатися даних на сервері.

Я запропонував 3 можливих рішення

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

Можливо, буде більше варіантів, але це ті, про які я міг би придумати.

Мої запитання є

• Що мені рекомендувати і чому?
• Які є чи можуть бути плюси та мінуси цих альтернатив?
• Чи є інші (можливо, кращі) альтернативи?

Щось із лише 6 формами і подібними слід легко перебудувати на більш сучасних рамках. Я працював з міграцією проектів VB6, які мали близько 200 форм разом з десятками класів та таблиць баз даних. Це не здається, що ти дивишся на що-небудь безладне, але погляди можуть обманювати.

Мені доведеться проаналізувати код, базу даних та бізнес-вимоги, щоб сказати, чи було б найкраще переписати чи переробити існуючу базу коду. З огляду на те, що ви сказали, я схиляюся до переписання. Але, можуть бути приховані труднощі, яких ви зараз не бачите.

Я маю дещо інші поради, більшість відповідей поки що.

Спроба виправити поточну систему

Я, принаймні, досить добре вивчив поточну систему, щоб пояснити клієнту, як ним користуватися. Я б зайняв цей час, щоб пояснити недоліки в їх теперішній системі, уникати негативних слів, просто скажіть їм, чого вона не може зробити, навіть якщо всі відомі помилки були виправлені.

Створіть новий інтерфейс (бажано схоже середовище, на базі VB.net або VB)

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

Інша проблема - спосіб спілкування з базою даних. Microsoft повільно позбавляється деяких старих способів спілкування зі своїми продуктами баз даних (Access, MSSQL), тож спосіб взаємодії з цими продуктами визначатиме, чи можна в майбутньому використовувати рішення для Windows 9 та Windows 10.

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

Я не відчуваю, що з додатком Visual Basic 6 щось "не так", окрім того, його підтримка майбутніх версій невідома. Навіть сьогодні з операційними системами Windows 7 та 64-розрядними операційними системами її підтримувати стає все важче та складніше. Це головна причина, що перезапис на сучасну мову з належною 64-бітовою підтримкою може бути хорошою ідеєю.

Якщо у них немає джерела, то переписування - це єдине їхнє рішення.

Перезапис інтерфейсу - відмінний варіант, враховуючи, що система порівняно мала. Переваги -

1. Підвищена стабільність (якщо припустимо, що ви це зробите добре!)
2. Поліпшення ремонту
3. Сучасний інтерфейс

Основним недоліком є ​​те, що він все одно, ймовірно, коштуватиме трохи дорожче, ніж злом існуючого коду.

Я б також схильний переписувати, але вам потрібно бути на 100% впевненим, що ви повністю розумієте поточну функціональність, а також будь-яку функціональність, яка порушена, відсутня або неадекватна. Останні два важливі, як ви згадали, коригування та розрахунок цін. Ви повністю розумієте наслідки додавання цієї функції?

Я колись працював над тим, що повинен був бути "веб-сайтом", але насправді переймав користувальницький інструмент управління стилем CRM з кінця 1990-х років і вводив його у сучасний веб-сайт. Оригінального розробника давно не було, База даних була модифікована не раз, оригінальна документація таким чином застаріла, і ніхто не зрозумів, як працює система. Але вони знали, як ним користуватися, просто. Ймовірно, 80% бюджету на цей проект було спрямовано на три речі:

• вимоги щодо збору
• розуміння чинної системи
• придумавши повноцінну схему бази даних про те, як вони мали намір використовувати програмне забезпечення

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

Іншим варіантом може стати компроміс між переписуванням усієї речі та злому наявного додатка.

Надайте їм нову функціональність у новому додатку, побудованому з нуля.

Це потенційно може бути простіше зробити, і не коштувати стільки, скільки повного переписування.

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

Це може бути більш приємним підходом.

Переписувачі часто мають тенденцію до скорочення бюджету ... Погано.

Але наявність сучасного кістяка для програми може бути хорошою інвестицією, особливо якщо ніхто не знає, як працює стара система, і якщо все порушиться, як тільки ви почнете торкатися їх.

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