План модернизации готов, бюджет предварительно одобрен. Подрядчик задаёт первый вопрос: «Где документация системы?». Оказывается, есть вики, обновлённая в последний раз пять лет назад, несколько схем «где-то на сетевом диске» и код, который сам себе служит документацией. Смета вырастает на треть. Потому что подрядчик оценивает не работу, а неопределённость.
Этот текст описывает практику, которая снимает эту неопределённость со стола: прежде чем кто-либо коснётся кода старого приложения, восстанавливаются знания о нём. Ещё недавно такой этап означал недели работы аналитика, и мало кто на него решался. Сегодня AI выполняет большую часть этого анализа за рабочие дни. И это меняет порядок всего проекта.
Сначала карта, потом код
Модернизация системы без актуальной документации напоминает ремонт здания без плана коммуникаций. Сделать можно, но каждый пробитый простенок — лотерея: может, за ним ничего нет, а может – труба, от которой зависит пол-этажа. В приложениях такой трубой бывает интеграция с хранилищем данных, о которой помнил только автор кода, или ночной экспорт, которым втихую пользуется бухгалтерия.
Поэтому разумный порядок обратен интуитивному. Начинают не с написания нового кода и даже не со сметы. Начинают с карты.
Что AI извлекает из кода, базы данных и логов
Современные инструменты анализа умеют читать три источника правды о системе: исходный код, структуру базы данных и логи промышленной эксплуатации. На их пересечении возникает карта системы, охватывающая четыре слоя.
Первый – модули: из чего состоит система и за что отвечает каждый фрагмент, описанные языком, понятным и людям вне IT. Второй – потоки данных: откуда данные входят, что с ними происходит по пути, где они оказываются в итоге. Третий – интеграции, то есть все места, где приложение общается с другими системами: бухгалтерией, складом, магазином, партнёрами. Именно они чаще всего ломаются при изменениях.
Четвёртый слой наименее очевиден: мёртвый код. Анализ логов показывает, какие функции не вызывались годами и в какие таблицы никто не пишет с 2019 года. В более старых системах такой балласт часто составляет значительную часть целого. Каждая строка, которую не нужно переносить, – реальная экономия в проекте.
Что карта меняет в решении «переписать или модернизировать»
О самом решении мы писали отдельно, в тексте о четырёх критериях: фреймворк принятия решения. Карта системы даёт этим критериям твёрдые данные. Без неё технический долг оценивают на глазок, а риск – по анекдотам. С ней видно чёрным по белому: какие модули несут бизнес-ценность, какие мертвы, где сидят интеграции, повышающие риск каждого изменения.
Результаты бывают неожиданны в обе стороны. Иногда система, которую «надо переписать с нуля», оказывается на три четверти здоровой, и достаточно заменить два модуля. Иногда наоборот: приложение выглядит безобидно, а карта раскрывает десяток недокументированных соединений, из-за которых частичная модернизация обходится дороже переписывания. В обоих случаях решение принимается на данных, а не на эмоциях. А подрядчик, получивший карту вместо загадки, оценивает работу, а не риск.
На наш взгляд, восстановление карты должно быть отдельным, первым этапом договора о модернизации, со своей собственной приёмкой. Даже если после этого этапа вы решите, что модернизацию делает кто-то другой или не делает вовсе, документация остаётся в компании и продолжает работать.
Как проверить то, что сгенерировал AI
Автоматически сгенерированная документация не является истиной в последней инстанции. Её нужно проверить. Самый эффективный метод прост: обзор с человеком, который знает систему лучше всех, часто единственным таким в компании. Отличие от классического подхода – в роли этого человека. Вы не просите его записать знания, чего никто не любит и что тянется месяцами. Вы просите отрецензировать готовое описание, а указать «здесь верно, здесь нет» получается в разы быстрее, чем писать с нуля.
Хорошая практика – пройти несколько важнейших процессов от начала до конца: заказ, счёт, рекламация. Если карта корректно описывает критичные потоки и выборочно проверенные детали, ей можно доверять и в остальных областях. Это можно сделать за день.
Чего AI не восстановит
Здесь честная оговорка: код говорит, что система делает, но не говорит, зачем. Странное исключение при начислении скидки может быть ошибкой, а может быть коммерческой договорённостью 2016 года, которая до сих пор действует для одного крупного клиента. Ни один анализ кода этого не разрешит. Бизнес-намерения десятилетней давности восстанавливаются интервью: короткими разговорами с людьми из продаж, бухгалтерии и операционного отдела, проводимыми уже с картой в руках. Карта подсказывает, о чём спрашивать, но ответы даёт человек.
Отдельная тема – окружение приложения: серверы, сеть, резервные копии. О документировании этого слоя мы писали в тексте об аудите документации инфраструктуры.
В ESKOM AI этап картирования мы ведём командой специализированных AI-агентов под надзором опытных инженеров: анализ типичной корпоративной системы занимает рабочие дни, а результатом становится документация, понятная и руководству, и технической команде. Если по её итогам принимается решение о модернизации, дальнейшая работа идёт в автоматизированном процессе разработки ПО с полным набором тестов – модульных, интеграционных, E2E, UI, безопасности и производительности.
С чего начать у себя
Выберите одну систему: ту, модернизацию которой откладываете дольше всего, или ту, которую боитесь трогать больше всего. Закажите восстановление её карты как самостоятельный, небольшой этап, прежде чем просить у кого-либо смету на перестройку. На бесплатной консультации мы подскажем, как спланировать такой этап и чего от него ожидать.
Записаться на бесплатную консультацию через контактную форму →