Из чего складывается оценка переписывания ПО?

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

Я видел, как на замену компактных расчетных систем уходило больше времени, чем на огромные приложения для отчетности. Небольшая система прятала правила в глубоко вложенных ветках, хранила промежуточное состояние в никем не описанных таблицах и вызывала сервисы, поведение которых менялось при закрытии месяца. Более крупная система повторяла простые CRUD-шаблоны и вела чистые журналы запросов. Оценка, которая начинается и заканчивается словами «300 000 строк», приклеивает точную этикетку к неизмеренной работе.

Что можно узнать по количеству строк

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

Определите правила подсчета до сравнения предложений. Как минимум разделите рабочий исходный код, сгенерированный код, сторонние зависимости, тесты, код базы данных, управление заданиями, конфигурацию и комментарии. Миллион строк вместе со сгенерированными клиентскими заглушками отличается от миллиона вручную написанных строк COBOL, JCL, SQL и copybooks. Если оценщик не показывает эти категории, проверить итоговую цифру нельзя.

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

cloc . --exclude-dir=vendor,node_modules,dist --by-file --json --out=cloc.json
jq '.SUM | {blank, comment, code}' cloc.json

Результат выглядит так:

{"blank":18420,"comment":27116,"code":263904}

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

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

Ветвление измеряет поведение, которое нужно сохранить

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

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

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

Просите распределение, а не среднее значение. Среднее по репозиторию скрывает пять процедур, которые управляют движением денег или работой предприятия. Полезно выделить процедуры выше согласованного порога цикломатической сложности, максимальную глубину вложенности, fan-in, fan-out и объем кода, доступный из точек входа с серьезными последствиями. Порог должен отмечать работу для изучения, а не объявлять код «плохим».

Уточните, разрешает ли анализ динамическую диспетчеризацию, сгенерированные вызовы, макросы и правила из базы данных. Статический анализ может пропустить имя программы, прочитанное из таблицы, собранный во время выполнения COBOL-CALL или событие формы VB6, подключенное за пределами видимой процедуры. Честный отчет помечает неразрешенные ребра. Он не выдает отсутствие данных в графе за низкую сложность.

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

Внешние интеграции создают риск на границах

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

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

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

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

Наличие владельца влияет на сроки и не сводится к примечанию об оргструктуре. Отметьте, кто может ответить на вопросы, выдать учетные данные, согласовать правило межсетевого экрана, предоставить пример и наблюдать за тестом. Если владельца нет, отдельно заложите исследование и резерв. Не прячьте этот риск в общем буфере проекта: до подписания договора руководитель должен иметь возможность назначить ответственного.

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

Поверхность тестирования задает уровень уверенности

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

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

Записанный рабочий трафик особенно полезен, поскольку содержит сочетания, которые никто не вспомнил при составлении плана тестирования. Но для его обработки нужны правила. Секреты и персональные данные может потребоваться скрыть, запросы могут зависеть от уже истекшего состояния, а повтор команды может вызвать внешний побочный эффект. Трасса дает доказательство, но не становится автоматически безопасной фикстурой.

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

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

В оценке нужно указать предложенный уровень доказательств. Для внутреннего справочного инструмента с небольшими последствиями могут хватить репрезентативные примеры и пользовательская приемка. Система проводок может потребовать воспроизведения записанного трафика, фикстур для отдельных веток, контрольных итогов и управляемого внесения сбоев. Желаемый уровень уверенности меняет объем работы. Фраза «переписать тот же код» не определяет эту цель.

Семантика данных может перевесить размер приложения

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

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

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

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

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

Эксплуатационный код входит в границы системы

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

Пакетные системы показывают это особенно ясно. JCL или CL могут определять зависимости, условное выполнение, выделение наборов данных, точки перезапуска и уведомления. Код приложения может выглядеть просто, хотя настоящий поток управления находится в сети заданий. В настольных системах ту же роль играют сценарии установки, настройки реестра, общие папки и запланированные задачи. В веб-монолитах пробел часто заполняют записи cron и ручные действия администратора.

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

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

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

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

Для изменения архитектуры нужны две отдельные оценки

Модернизация архитектуры и сохранение поведения связаны, но это разные направления работы. Оценивайте их отдельно, чтобы проектное решение не снижало незаметно обещанный уровень доказательств. Граница сервиса может улучшить распределение ответственности и развертывание, но она также создает контракты, варианты сбоев и решения о целостности данных, которые монолит обрабатывал локальными вызовами и одной транзакцией.

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

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

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

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

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

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

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

Взвешенная модель делает предположения видимыми

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

Начните с таблицы инвентаризации на уровне подсистем. Одна строка на развертываемую единицу или связную бизнес-функцию обычно информативнее строки на репозиторий. Используйте такие столбцы:

Рядом с каждым измерением укажите уровень уверенности. «42 интерфейса, 39 изучены, 3 выведены косвенно» полезнее, чем «42 интерфейса». Запишите источник доказательства: статический анализ, производственная трасса, проверка конфигурации, интервью или образец данных. Косвенно выведенный пункт требует большего резерва, чем наблюдаемый.

Затем представьте оценку в виде диапазонов по направлениям работы. Простая внутренняя модель может выглядеть так:

replacement = source inventory adjusted for repetition and generated code
behavior proof = consequential paths x fixture cost x evidence gap
integration work = contract implementation + failure proof + owner delay risk
data work = mapping + transformation + rehearsal + reconciliation
operations = deployment + observability + recovery exercises

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

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

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

Как оценка ломается на небольшой системе

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

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

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

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

Оценка меняется, потому что единицей работы стали доказанные варианты поведения вместо замененных строк. Команда может по-прежнему переписать только 38 000 строк. Ей также нужно найти пути решений в интерфейсе, извлечь историю правил, воспроизвести проверку партнера и сравнить старые и новые результаты на записанных примерах. Нечестно называть это превышением, если первоначальное предложение никогда не измеряло эти пункты.

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

Запросите пакет измерений до подписания

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

Пакет должен отвечать на небольшой набор вопросов:

1. Какие категории исходников посчитали, что исключили и можем ли мы повторить инвентаризацию?
2. Где находятся самые глубокие и значимые пути решений, включая неразрешенные динамические вызовы?
3. Какие внешние контракты существуют, кто ими владеет и какие можно проверить вне рабочей среды?
4. Какие значения данных, миграции и правила сверки остаются неразрешенными?
5. Какие входные данные можно воспроизвести, какие результаты сравнить и как нормализуются допустимые различия?

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

Коммерческие условия должны следовать измерениям. Фиксированный объем подходит, когда известны границы и доказательства приемки. Платный этап исследования может быть разумным при отсутствии доступа, владельцев или производственных трасс, но его результатом должны стать пригодные для повторного применения материалы, а не слайды: реестры, графы, соответствия, образцы и обновленный диапазон. Резерв нужно привязать к названным неизвестным и уменьшать, когда заказчик их устраняет.

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

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