План модернізації готовий, бюджет попередньо затверджений. Виконавець задає перше питання: «Де документація системи?». Виявляється, що є вікі, оновлена останнього разу п'ять років тому, кілька схем «десь на мережевому диску» і код, який сам собі робить за документацію. Оцінка зростає на одну третину. Бо виконавець не оцінює роботу, тільки невизначеність.
Цей текст описує практику, яка знімає цю невизначеність зі столу: прежде ніж хтось торкнеться коду старої програми, відтворюється знання про неї. Ще недавно такий етап означав тижні роботи аналітика і мало хто на нього погоджувався. Сьогодні AI виконує більшу частину цього аналізу за робочі дні. І це змінює порядок всього проекту.
Спочатку карта, потім код
Модернізація системи без актуальної документації нагадує ремонт будинку без плану інсталяції. Дається, але кожне пробивання стіни - це лотерея: може за нею нічого не бути, а може труба, від якої залежить половина поверху. У програмах цією трубою буває інтеграція з складом, про яку пам'ятав тільки автор коду, або нічний експорт, з якого потай користується бухгалтерія.
Тому розумна послідовність є зворотною до інтуїтивної. Не починається з написання нового коду чи навіть з оцінки. Починається з карти.
Що AI витягує з коду, бази і логів
Сучасні інструменти аналізу можуть прочитати три джерела істини про систему: код джерела, структуру бази даних і логи з продуктивного використання. З їхнього перехрестя виникає карта системи, яка охоплює чотири шари.
Перша - модулі: з чого складається система і за що кожна частина відповідає, описані мовою, зрозумілою також для осіб поза ІТ. Друга - потоки даних: звідки дані надходять, що з ними відбувається по дорозі, де вони приземляються. Третя - інтеграції, тобто всі місця, в яких додаток розмовляє з іншими системами: бухгалтерією, складом, магазином, партнерами. Це вони найчастіше ламаються при змінах.
Четвертий шар найменш очевидний: мертвий код. Аналіз журналів показує, які функції не були викликані років та до яких таблиць ніхто не писав з 2019 року. У старших системах такий баласт часто становить велику частку цілого. Кожен рядок, якого не потрібно переносити, - це реальна економія в проекті.
Що змінився в рішенні "переписати чи модернізувати"
Про саме рішення ми писали окремо, в тексті про чотири критерії: framework рішення. Карта системи надає цим критеріям тверді дані. Без неї технічний борг оцінюється на відчуттях, а ризик - на підставі анекдотів. З нею все видно чорним по білому: які модулі несуть бізнес-відміну, які мертві, де сидять інтеграції, що підвищують ризик кожної зміни.
Ефекти іноді бувають несподівані в обидві сторони. Іноді система, яку "треба переписати з нуля", виявляється на три чверті здоровою і достатньо замінити два модулі. Іноді навпаки: додаток виглядає невинно, а карта розкриває десятки неудокументованих з'єднань, які роблять часткову модернізацію дорожчою за переписування. В обидвох випадках рішення приймається на основі даних, а не емоцій. А виконавець, який отримує карту замість загадки, оцінює роботу замість ризику.
Нашою думкою, відновлення карти має бути окремим, першим етапом договору модернізації, з власним прийомом. Навіть якщо після цього етапу ви вирішите, що модернізацію робить хтось інший або не робите її взагалі, документація залишається в компанії і продовжує працювати.
Як верифікувати те, що згенерувала AI
Документація, згенерована автоматично, не є оракулом. Її потрібно перевірити. Найефективніший метод простий: перегляд з особою, яка систему знає найкраще, часто єдиною такою в компанії. Різниця порівняно з класичним підходом полягає в ролі цієї особи. Ви не просите її описати знання, чого ніхто не любить і що тягнеться місяцями. Ви просите про рецензію готового опису, а вказівка "тут згоден, тут ні" йде багатократно швидше, ніж написання з нуля.
Доброю практикою є проходження через кілька найважливіших процесів від початку до кінця: замовлення, фактура, рекламація. Якщо карта правильно описує критичні потоки та вибірково перевірені деталі, можна їй довіряти в інших областях. Це можна зробити за день.
Чого AI не відновить
Тут чесне застереження: код говорить, що система робить, але не говорить, навіщо. Дивний виняток у розрахунку знижки може бути помилкою, а може бути угодою з 2016 року, яка ще діє для одного великого клієнта. Це жоден аналіз коду не розставить. Бізнес-інтенції з минулого відновлюються за допомогою опитувань: коротких розмов з людьми від продажів, бухгалтерії та операцій, які проводяться вже з карти в руках. Карта підказує, про що питати, але відповіді має людина.
Особливою темою є також оточення програми: сервери, мережа, запасні копії. Про документацію цього рівня ми писали в статті про аудит документації інфраструктури.
У ESKOM AI етап мапування проводимо командою високоспеціалізованих агентів AI під наглядом досвідчених інженерів: аналіз типової корпоративної системи займає робочі дні, а результатом є документація, читана для керівництва та технічної команди. Якщо після неї приймається рішення про модернізацію, подальші роботи проходять у автоматизованому процесі виробництва програмного забезпечення з повним спектром тестів — одиницевих, інтеграційних, E2E, UI, безпеки та продуктивності.
Від чого почати у себе
Виберіть одну систему: ту, яку модернізацію відкладаєте найдовше або якої найбільше боїтеся торкатися. Замовте відновлення її карти як самостійний, невеликий етап, перш ніж попросите когось про оцінку перебудови. На безкоштовній консультації підкажемо, як такий етап спланувати та чого від нього очікувати.
Заплануйте безкоштовну консультацію через контактну форму →