Як виправити проект в основному без структури?

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

Специфіка проекту: Це програма продажу, майже повністю написана на Visual Basic Classic (VB6) із задньою частиною MySQL та механізмом звітності, написаним на C #. Модуль звітності C # із задоволенням працює над ним, він був написаний лише за останні пару років, а до цього всі звіти були зроблені в Crystal Reports 9 (так, у нас все ще є деякі звіти, на які покладаються).

Однак сама програма є повною катастрофою. Всього не більше 90 тис. LOC, і близько 10 тис. Рядків коментарів (в основному це не документація, а старий код, який прокоментували). 158 форм-файлів та 80-модульних файлів. Я поняття не маю, скільки з них насправді використовується, тому що деякі функції програми просто застаріли і (ех, іноді) відзначаються як такі, не видаляючи з програми пов'язаний код. Я б здогадався, що лише 50% коду в реальному виробничому використанні.

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

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

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

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

Тож як мені почати реально виправляти цей проект? Спробуйте інструмент VB6 іншою мовою? Спробувати і переписати програму у вільний час? Або це зовсім безнадійно?

Оновлення

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

З тих пір я перейшов на іншу роботу. Хоча після стількох років vb6 і лише периферійного досвіду роботи з іншими технологіями пошук був важким, і я зіткнувся з багатьма відмовами на цьому шляху (близько десятка інтерв'ю протягом року). Моя порада іншим у цій ситуації - розглянути можливість залишати цей фактор самостійно. Подумайте про шкоду, яку ви можете завдати кар'єрі, залишаючись у тупиковій позиції, як ця.

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

Я почав тут у подібній ситуації (додаток 80KLOC VB6 без управління джерелами, реальної структури, майже все, що робиться в обробниках подій).

Приблизно через 2 роки і вимикаючи, я перетворив більше половини на C # (зазвичай, коли потрібні значні нові функції). Весь новий код C # має модульне покриття. Це, безумовно, потребує більше часу для перетворення на C #, хоча. Якщо ви не додаєте важливих нових модулів, я не пішов би по цьому маршруту.

Одне, що я зробив, - створити рудиментарний рівень доступу до даних, який автоматично генерується з бази даних. Принаймні, виникли проблеми, коли змінилася назва стовпця таблиці, і я не знайшов усіх місць у коді. Крім того, я повільно перемістив бізнес-логіку в модулі, поза формами обробників подій.

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

Я дійсно думаю, що найкраще робити наступний підхід:

1. Вивчіть кожен шматочок з неприємними подробицями. Це робить меншою ймовірність, що ви зламаєте щось ненавмисно.
2. Рефактор нещадно покращує розділення та структуру, але не намагайтеся вподобати таку нову методологію, як об’єктно-орієнтоване програмування там, оскільки VB6 просто смокче її.
3. Трактуйте це як досвід навчання. Як би ви знали, що інший спосіб кращий, якби ви ніколи не бачили нижчого?
4. Не переймайтеся переписуванням новою мовою / рамкою / платформою, якщо у вас є основний модуль для написання. Вже тоді уважно подумайте.

Пам’ятайте, мета програми - бути продуктом, який заробляє гроші вашої компанії. Він не повинен бути бездоганним твором мистецтва (і я перфекціоніст , так що це дійсно важко для мене , щоб визнати , що). Іноді краще сприйняти прагматизм.

Нібито є багато програмістів COBOL, які підтримують величезний обсяг застарілого коду. Я сумніваюся, що всі вони шалено працюють над тим, щоб переписати його якоюсь новою мовою. :)

Що вам потрібно зробити - це рефакторинг. Рефакторинг майже неможливий у такій ситуації без одиничного тесту, який дає вам впевненість, що ви нічого не зламали. Тому почніть зі створення одиничних тестів. Задокументуйте поведінку коду, але не (тільки) на папері, а в більшій кількості коду - одиничні тести. Після того, як ви встановите тести, можете приступити до реструктуризації коду.

Приходить одне правило з « Налагодження » Девіда Агана : киньте думати і дивіться. У вашому розпорядженні є машина, здатна обробляти велику кількість тексту. Використовуйте його, щоб точно визначити, який код більше не використовується, і видаліть його без поваги. Якщо ви зробили помилку, саме для цього використовується джерело управління.

Це легка частина. Що потрібно подумати далі - як ви їсте слона? По одному укусі. Візьміть " Рефакторинг " Мартіна Фаулера і виконайте його функцію за функцією, файл за файлом. Не повністю щось бракуйте і не переписуйте це з того, що, на вашу думку, є вимогами. Працюйте як альпініст, ніколи не знімаючи попередню безпеку, поки не з’явиться наступна.

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

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

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

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

Тут вже є кілька хороших відповідей, я хотів би додати одне. Замість того, щоб намагатися переписати все, можливо, у вас з’явиться шанс перенести хоча б деякі з цих модулів, в основному, 1: 1 до VB.NET (звичайно, ви повинні бути дуже обережними або при цьому)? На мій досвід, таке перенесення може бути виконано з ~ 5-10 разів меншими зусиллями, ніж спроба відновити всі наявні функції з нуля. І після того, як ви перенесли його, то ви можете почати рефакторинг - всі ці інструментами , доступними в .NET світі, як хороший інструмент модульного тестування, автоматичні інструменти рефакторинга, реальний об'єктно - орієнтоване програмування і т.д.

Я був у подібній ситуації, коли нам довелося перенести стару 16-бітну програму C ++ (150k LOC) у 32-бітний світ, де оригінальний графічний інтерфейс, що використовується, вже не був доступний. Ми зайняли певний час, щоб зрозуміти, що переписування було нереальним, але після того, як ми вирішили перенести цю річ у світ .NET, використовуючи C ++, C ++ / CLI і C #, нам знадобилося лише дев'ять місяців, щоб це відбулося (приблизно 1 дев. повна робота над цим проектом). І у нас не було доступних одиничних тестів для частини GUI, все це тестування було виконано вручну.

Хоча він робить багато акцентів на тестуванні одиниць вашої програми, що, хоча це дуже важлива річ, у VB6 щось досить важко зробити, Стівен МакКоннелл написав чудову книгу про те, як боротися з таким проектом.

Погляньте на це:

Стівен К. МККОННЕЛЬ: Ефективна робота зі спадковим кодом, друге видання. Microsoft Press, червень 2004 року.

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