Оценка legacy-системы без подсчёта строк

Число строк показывает объём исходного текста. Оно не говорит, сколько поведения должна сохранить новая система, сколько ветвей у этого поведения и какая часть исходников до сих пор выполняется. Если считать эти величины взаимозаменяемыми, внешне точная оценка модернизации ошибётся в разы.

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

Полезная единица измерения здесь не строка, а фрагмент поведения, который нужно обнаружить, отделить от зависимостей, реализовать и проверить на эквивалентность. Эту работу показывают пять показателей: глубина решений, fan-in постоянных данных, доля мёртвого кода, поверхность интеграций и доля поведения, известного только по выходным данным продакшена. Ни один показатель сам по себе не выдаст правильную цену. Вместе они дают инженерно обоснованный профиль системы.

Число строк измеряет объём исходников, а не переписывание

Число строк кода отвечает на узкий вопрос: какой объём текста конкретное правило подсчёта отнесло к исходникам? В отчёте Роберта Парка для Software Engineering Institute, Software Size Measurement: A Framework for Counting Source Statements, много внимания уделено точным определениям физических строк и логических операторов. Это первое предупреждение. Два инструмента могут дать разные результаты ещё до обсуждения комментариев, сгенерированных copybook, раскрытых макросов, встроенного SQL и нескольких members с одной и той же процедурой.

Даже полностью нормализованный подсчёт измеряет только объём исходников. Он помогает оценить загрузку репозитория, хранение, пропускную способность анализатора или грубо сравнить версии на одном языке с одинаковыми соглашениями. Но он не покажет, реализуют ли 40 строк прямое преобразование или правило с состоянием и 16 путями. Не покажет, выполняются ли 4 000 скопированных строк. Не покажет и того, что одно присваивание в поле статуса меняет работу восьми последующих задач.

Язык тоже искажает знаменатель. Разделы данных COBOL могут визуально раздувать описание записей. APL или SQL выражают значительное поведение в нескольких операторах. Сгенерированный Java добавляет тысячи однотипных методов доступа. Коэффициент по числу строк молча считает всё это равноценными единицами мысли. Они не равноценны.

Не пытайтесь исправить ситуацию таблицей пересчёта языков, где одна строка COBOL равна некоторому числу строк Go. Этот совет популярен, потому что быстро создаёт таблицу и напоминает старое планирование производительности. При модернизации он не работает: целевая архитектура не должна сохранять текстовую форму исходной системы. Общий copybook может превратиться в схему и сгенерированные клиенты. Двадцать почти одинаковых пакетных программ могут стать одним сервисом с конфигурацией. Плотное вычисление может остаться плотным в Rust, поскольку объём работы задаёт математика, а не синтаксис исходного языка.

Оставьте число строк в отчёте, но назовите его честно. Отдельно укажите физические строки, логические операторы, сгенерированные строки, комментарии и дубликаты. Этими данными описывайте корпус. Их сумма не должна обозначать трудозатраты на поставку или риск расхождения поведения.

Цикломатическая глубина показывает дорогие решения

Цикломатическая сложность считает независимые пути в графе потока управления. Томас Маккейб ввёл эту меру в статье 1976 года A Complexity Measure и записал её через выражение теории графов, которое обычно выглядит как V(G) = E - N + 2P. Мера полезна, потому что объём проверок растёт вокруг решений, а не вокруг форматирования. В более позднем обзоре технологии от Software Engineering Institute есть важная оговорка: высокое значение само по себе не доказывает, что модуль опасен или требует переработки.

При оценке legacy-системы распределение важнее среднего по репозиторию. Среднее значение шесть может описывать равномерную кодовую базу. Оно же может скрывать базу, где большинство процедур тривиальны, а несколько расчётных модулей содержат сотни путей. Для таких систем нужны разные планы. Покажите как минимум медиану, 90-й процентиль, максимум и долю достижимых процедур выше порога ручной проверки. Не включайте сгенерированные и мёртвые процедуры в основное распределение, но укажите их рядом.

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

Измеряйте оба показателя для каждой достижимой процедуры. Для глубины считайте вложенные условия, циклы, исключения и специфичные для языка ветвления после раскрытия препроцессинга, который меняет поток управления. Затем изучите процедуры с высоким значением по любой оси. Проверка должна ответить на четыре вопроса. Зависит ли ветвь от постоянного состояния? Меняет ли она данные, которые позже читаются в той же транзакции? Повторяется ли условие в другом месте? Могут ли записанные входные данные привести к обоим результатам?

Не складывайте все значения сложности в одно огромное число. Сумма вознаграждает разбиение процедуры, даже если число реальных решений в системе не уменьшилось, и скрывает их концентрацию. Используйте тепловую карту или отсортированную таблицу, где сохраняются имя модуля, контекст вызова и затронутые данные. Для оценки переписывания нужно знать, где решения связаны друг с другом, а не только сколько условных элементов нашёл анализатор.

Сложность также задаёт объём доказательств. Для линейной процедуры могут хватить показательных граничных случаев. Для глубоко вложенной процедуры, которая выбирает цены, налоги или результат проверки права, нужна матрица наблюдаемых и специально построенных случаев. Это не означает, что каждый математически возможный путь требует отдельного теста. Некоторые пути недостижимы, а часть сочетаний исключает предшествующая проверка. Оценка должна включать работу по определению значимых путей, а не предполагать, что их уже учло число строк.

Fan-in данных раскрывает настоящий радиус изменений

Fan-in показывает, сколько вызывающих компонентов или потоков сходятся в одном компоненте. Для legacy-систем полезен fan-in на уровне кода, но fan-in уровня данных часто точнее описывает риск. Посчитайте независимо развёртываемые программы, задания, экраны, отчёты, хранимые процедуры, файловые потоки и операторские утилиты, которые читают или записывают каждую постоянную запись, таблицу, файл, очередь и общую область данных.

Fan-in чтения нужно отделять от fan-in записи. Пятьдесят отчётов, которые читают журнал только с добавлением новых записей, создают работу по миграции и совместимости. Но одна сверочная задача, записывающая исторические строки, может наложить гораздо более жёсткое ограничение на переключение. Смешанная ответственность ещё сложнее: онлайн-транзакция обновляет основную запись, ночной пакет исправляет её, а операторская утилита при исключении может перезаписать поле. Схема данных показывает общий объект. Она не показывает порядок, полномочия и эксплуатационную причину этих записей.

Сначала найдите статические ссылки, затем сопоставьте их с данными времени выполнения. Статический анализ разрешает прямой SQL, известные имена файлов, использование copybook и вызовы с литералами. Он пропустит динамический SQL, имена из переменных, подстановки планировщика, псевдонимы, exits и доступ из инструментов вне репозитория. Журналы аудита базы данных, логи заданий, метаданные сообщений и история файлового каталога обнаружат часть отсутствующего fan-in. Из разговоров можно узнать об операторских утилитах, но воспоминание остаётся зацепкой, пока его не подтвердят данные.

Ранжируйте хранилища не только по числу ссылок. Отделяйте читателей от писателей, онлайн-доступ от пакетного, синхронные обновления от отложенных. Отмечайте, охватывает ли граница транзакции несколько хранилищ. Выделяйте поля, смысл которых зависит от программы. Например, пустой статус одна задача может понимать как «ожидает обработки», а другая как «не применяется». Такие смысловые конфликты создают больше работы, чем чистая таблица со множеством обычных читателей.

Практичная запись fan-in может оставаться компактной:

asset,readers,writers,execution_modes,transaction_peer,observed
CUSTOMER-MASTER,14,4,online|batch,ADDRESS-HISTORY,yes
RATE-CONTROL,6,1,batch,none,no
CLAIM-QUEUE,3,3,online|operator,PAYMENT-FILE,partial

Последний столбец добавлен намеренно. Статическая ссылка и наблюдаемый доступ подтверждают разные факты. Сохраняйте оба. Если оценка смешивает их, ни разу не выполненная ссылка может раздуть объём, а незамеченный динамический доступ исчезнет.

Высокий fan-in не означает, что компонент нужно переписать первым. Часто вывод обратный. Для широко используемого хранилища может понадобиться явная граница совместимости, поэтапная передача ответственности или период одновременной работы старых и новых компонентов. Показатель меняет порядок работ, потому что отмечает места, где локально правильное изменение способно сломать всю систему.

Мёртвый код меняет знаменатель

Доля мёртвого кода показывает часть корпуса, которая не может выполниться в заданной конфигурации продакшена. Она должна уменьшать объём реализации, но только после доказательства причин недостижимости. Удаление каталога, о котором никто не помнит, нельзя считать анализом.

Используйте три категории. У недостижимого кода нет пути от настроенной точки входа. У ненаблюдаемого кода возможный путь есть, но за период наблюдения он не выполнялся. Для выведенного поведения владелец подтвердил, что новая система не должна его сохранять. Эти категории нельзя подменять друг другом. В документации IBM по поиску недостижимого COBOL-кода прямо сказано, что результат получен статическим анализом и не отражает фактический путь выполнения. Именно поэтому статические и динамические доказательства нужно хранить отдельно.

Достижимость определяется конфигурацией. Модуль, который не используется в расписании по будням, может запускаться при закрытии квартала. Транзакция CICS может быть выключена в одном регионе и работать в другом. Members JCL могут выбираться через переменные планировщика. Настольное приложение может загружать плагин, указанный в локальном конфигурационном файле, который никогда не попадал в систему контроля версий. Соберите точки входа из производственных расписаний, определений транзакций, манифестов развёртывания, командных процедур, зарегистрированных заданий и инструкций операторов, а не только из графа вызовов с очевидной главной программой в корне.

Затем посчитайте несколько долей: статически недостижимые операторы, достижимые, но ненаблюдаемые операторы, достижимые дубликаты и поведение с подтверждённым выводом из эксплуатации. Для каждой доли укажите уровень уверенности и ссылку на доказательство. Из оценки нужно исключать только выведенную часть. Недостижимый код с неясной конфигурацией отправляется на уточнение, а ненаблюдаемый код всё ещё требует направленных тестов или решения владельца процесса.

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

Поверхность интеграций нужно считать контрактами

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

Один ночной файл с фиксированной шириной полей может потребовать больше работы, чем десять обычных HTTP-методов. Для файла могут быть обязательны точное имя, кодовая страница, длина записи, порядок сортировки, контрольный итог, окно доставки, правило повторного запуска и ручное подтверждение. Получатель может разбирать недокументированные байты заполнения. Ничего из этого не видно в числе строк. Многого нет и в отправляющей программе, потому что часть поведения реализуют планировщик, средство передачи и инструкция оператора.

Проведите инвентаризацию каждой внешней связи и каждой внутренней связи, которая пересекает границу ответственности или развёртывания. Включите базы данных другой команды, входящие и исходящие файлы, очереди, удалённые вызовы процедур, терминальные протоколы, электронную почту, печатные выходные данные, поставщиков идентификации, аппаратные интерфейсы, таблицы-шаблоны для импорта и ручные передачи, запускаемые отчётом. Не объединяйте пять файлов в «партнёрский поток», если у них разные расписания или обработка ошибок.

Для каждого контракта запишите направление, протокол, расположение схемы, частоту, пиковый режим, порядок, идемпотентность, правило повторной попытки, тайм-аут, аутентификацию, шифрование, производителя, потребителя, тестовую среду и пример из продакшена. Значение «неизвестно» допустимо. Оно также обозначает работу. Пустая ячейка не должна молча превращаться в предположение, что стандартное поведение целевой платформы совпадёт со старым.

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

Особенно внимательно изучите отрицательные сценарии. Потребители могут зависеть от пустого файла, конкретного кода возврата, отложенной повторной попытки, дублированной доставки или отсутствия строки. Примеры успешной работы редко фиксируют такие контракты. Соберите логи сбоев и записи повторных запусков. Спросите операторов, что они делают, если ожидаемый объект не приходит. Их действие часто входит в систему, хотя ни один компилятор его не видит.

Выход продакшена может быть единственной спецификацией

Некоторое поведение legacy-системы существует только в выходных данных продакшена. Код его вычисляет, пользователи и последующие системы от него зависят, но актуальные требования его не объясняют. Этот пробел заслуживает отдельного показателя, потому что меняет объём исследования и проверки.

Сначала посчитайте поверхности поведения: ответы API, изменения базы данных, файлы, сообщения, поля экранов, печатные отчёты, записи аудита, коды возврата, временные события и запросы оператору. Для каждой поверхности укажите источник спецификации: актуальная документация, выполняемые тесты, вывод из кода, подтверждение специалиста или наблюдение в продакшене. Источников может быть несколько. Опасная категория называется «только продакшен»: ни надёжный документ, ни тест не определяют результат, а правильность оценивают сравнением с выходом старой системы.

Категория «только продакшен» не обязана навсегда оставаться загадкой. Соберите показательные пары входных и выходных данных, нормализуйте изменчивые поля, например временные метки и сгенерированные идентификаторы, и по возможности воспроизведите входы на старой системе в контролируемых условиях. Сохраните порядок, округление, кодировку, обработку пробелов и сообщения об ошибках до того, как кто-то решит их «почистить». Конечный пробел может не иметь значения в одном отчёте и разделять поля в другом.

Измеряйте взвешенную долю, а не простое число выходов. Дайте больший вес выходам, которые перемещают деньги, закрывают книги, управляют физической работой, используются при аудиторской проверке или питают другую систему. Также укажите покрытие: разнообразие входов, календарных условий и ошибок в записанном трафике. Тридцать дней онлайн-запросов могут покрыть обычные пути и пропустить закрытие года. Миллион повторяющихся проверок состояния почти ничего не добавит к знанию о поведении.

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

Записанный трафик даёт доказательство, но не абсолютную истину. В нём могут быть неверные результаты, скрытые дефекты, чувствительные данные и случайные зависимости. Ограничьте доступ и минимизируйте данные, найдите поля, которые нельзя выносить за периметр заказчика, и попросите ответственного владельца решить, показывает ли расхождение регрессию или старый дефект, который пора убрать. Автоматическая проверка эквивалентности без такого решения может с высокой точностью сохранить ошибки.

Профиль размера не смешивает разные риски

Объедините показатели в профиль, а не в универсальную взвешенную оценку. Одно число кажется удобным, но уничтожает сведения, необходимые для выбора архитектуры, порядка работ и глубины проверки. Две системы могут получить одинаковый балл, хотя в одной сосредоточена сложная логика решений, а в другой простой код скрыт за десятками хрупких интерфейсов.

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

Запись о достижимости содержит доли выведенного и неразрешённого кода рядом со статическими корнями, окном наблюдения и решениями владельцев. Запись о контрактах содержит отдельные интерфейсы, семейства механизмов, примеры сбоев и доступ к тестам. Запись о доказательствах поведения содержит взвешенные поверхности из категории «только продакшен», разнообразие записанных входов, календарные пробелы и владельца решений по расхождениям. Используйте стабильные идентификаторы во всех записях, чтобы проверяющий мог перейти от горячей точки к доказательству без ручного сопоставления описаний.

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

Используйте диапазоны, а не ложную точность. Для глубины решений диапазоны могут разделять обычные процедуры, горячие точки для ревью и кандидатов на декомпозицию. Для fan-in данных они могут разделять изолированные хранилища, общие модели чтения и спорную ответственность за запись. Определяйте каждый диапазон через действие. Красная ячейка должна означать «нужна граница совместимости и проверка владельца», а не «выглядит страшно».

Профиль также показывает неопределённость. Для каждого значения отметьте источник: статический анализ, наблюдение во время выполнения, конфигурационные записи или решение владельца. Добавьте ссылку на доказательство и уровень уверенности. Неизвестное правило повтора интеграции и точный результат в 200 000 строк нельзя усреднять до успокаивающего балла. Неизвестное правило может определять риск переключения.

Храните исходные наблюдения рядом с производными значениями. Если анализатор сообщает о 26 вызывающих компонентах, а данные выполнения показывают 19, сохраните оба числа и статус сверки. Позднее может выясниться, что пять компонентов относятся к выведенным расписаниям, а два вызова используют динамические псевдонимы. Замена прежнего числа уничтожает аудиторский след и делает оценку увереннее, чем она когда-либо была. То же правило относится к нормализации сложности, поиску дубликатов и покрытию трафика.

Для оценки превратите элементы профиля в пакеты работ с наблюдаемыми условиями завершения. Горячая точка решений готова, когда приняты таблица поведения, реализация и примеры эквивалентности. Хранилище данных готово, когда учтены ответственность, транзакционное поведение, правило миграции и потребители. Интеграция готова, когда успешные сценарии, сбои, повторы и передача в эксплуатацию работают в целевой среде. Поверхность из категории «только продакшен» готова, когда записанные случаи совпадают или владелец одобрил каждое намеренное различие.

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

Оценивайте единицы доказательств, а не новые строки

После построения профиля оцените единицы сохраняемого поведения и его доказательства. Начните с достижимых возможностей, затем разделите их там, где отличаются ответственность за данные, интеграционные контракты или способы проверки. Число строк в целевой системе неизвестно и почти не имеет значения. Новая архитектура может убрать повторения, объединить программы или заменить процедурную обвязку возможностями платформы.

Для каждой единицы оцените четыре вида работы: исследование, проектирование и реализацию целевой системы, построение доказательств и приёмку. В исследование входят динамические вызовы, отсутствующие макеты, владельцы и правила из категории «только продакшен». В построение доказательств входят запись трафика, тестовые данные, средства сравнения и ожидаемые случаи сбоя. Приёмка включает разбор отличий человеком, который вправе решить, нужно ли сохранять старое поведение.

Не прячьте неопределённость внутри большего числа трудозатрат. Ведите реестр предположений с проверкой и владельцем. Утверждение «у RATE-CONTROL нет интерактивных писателей» проверяется по журналам доступа и с операторами. Утверждение «в выгрузке планировщика есть все задачи закрытия квартала» проверяется по истории выполнения. Рано разбирайте предположения с сильным влиянием, потому что они меняют границы системы, а не только часы.

Практическое сравнение проясняет подход. В системе A есть 700 000 логических операторов, 45 процентов подтверждённого к выводу поведения, средняя глубина решений, два хранилища с интенсивной записью и шесть семейств интеграций с записанными случаями ошибок. В системе B есть 180 000 операторов, почти нет выведенного поведения, несколько глубоко вложенных расчётных процедур, девять хранилищ со спорной ответственностью и выходы, правила которых существуют только в отчётах закрытия месяца. Оценка по строкам делает A почти в четыре раза крупнее. Профиль поведения может обоснованно показать, что B требует больше исследования и приёмки. Профиль не доказывает цену. Он показывает, почему цена должна следовать за доказательствами, а не за объёмом текста.

Метод также позволяет сравнивать предложения поставщиков. Попросите каждого вернуть посчитанные точки входа, классификацию достижимости, распределение сложности, хранилища с высоким fan-in, реестр контрактов, поверхности из категории «только продакшен» и неразрешённые предположения. Если один поставщик даёт коэффициент по строкам, а другой называет девять хранилищ с конкурирующими писателями, видно, кто изучил систему, а кто оценил красивую историю.

CodeHero параллельно читает всё дерево исходников, а затем проверяет модернизированное поведение на записанном трафике продакшена с помощью стенда эквивалентности. Такое сочетание разделяет масштаб корпуса и доказательство поведения. Это различие важнее любого заявления о числе строк, которое способен загрузить инструмент.

Согласование должно следовать за измерениями

Обоснованная оценка legacy-системы позволяет другому инженеру проследить объём работ до доказательств. Для любого крупного пакета работ должны находиться достигающие его точки входа, содержащиеся в нём решения, читаемые и записываемые данные, пересекаемые контракты и примеры из продакшена, по которым пройдёт приёмка.

Перед утверждением плана спросите, что оценщик исключил и кто это разрешил. Спросите, какие периоды работы охвачены наблюдением, включая закрытие квартала и года. Запросите крупнейшие горячие точки сложности вместо среднего. Уточните, у каких хранилищ несколько писателей. Найдите интерфейсы без примеров сбоев. Найдите выходы без спецификации кроме продакшена. В прямом ответе может быть неопределённость. Расплывчатая уверенность должна остановить согласование.

Число строк всё ещё уместно на первой странице, поскольку описывает изученный материал. Поставьте его рядом с долей мёртвого и сгенерированного кода, а не над показателями поведения. Оценка должна меняться при обнаружении скрытого писателя, активной задачи, которую считали мёртвой, или нехватки примеров выхода. Если она меняется только после обнаружения ещё одного каталога исходников, модель измеряет объём файлов и называет его инженерной работой.

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