Как оценивать сроки ревью кода и рефакторинга без самообмана

Почему оценка «быстро посмотрю» почти всегда врёт

«Тут только ревью и небольшая чистка» — плохая оценка, если за ней нет списка работ. Проверить один изолированный модуль и безопасно изменить код, связанный с базой данных, очередями и внешним API, — разные задачи. Но в планировании обе часто получают одинаковые полдня.

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

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

Сначала разделите работу на части

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

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

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

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

Три подхода к оценке — и цена каждого

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

Как оценить ревью кода

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

1. Зафиксируйте границы: что меняется и что намеренно остаётся прежним. Проверка понятна, если по описанию можно назвать затронутый сценарий и ожидаемое поведение.
2. Выделите зоны риска: например, изменение схемы БД, прав доступа или повторной обработки сообщения. Результат шага — список конкретных мест, где ошибка может повлиять на данные или пользователей.
3. Оцените проходы: отдельно заложите чтение изменения и повторный просмотр после исправлений. Если автор пока не закончил работу, ревью не начинается с чистого листа — но и заранее считать его завершённым нельзя.
4. Проверьте готовность к ревью: есть ли описание цели, тесты и инструкции по проверке. Если этого нет, оцените подготовку или попросите автора дополнить изменение до начала содержательной проверки.

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

Как оценить рефакторинг, не обещая «попутно почистить»

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

До оценки ответьте на четыре вопроса:

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

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

Когда выбирать диапазон

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

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

Что ломает оценку

• Скрытые зависимости. Изменение затрагивает соседний сервис или устаревшую документацию. До начала проверьте вызовы, потребителей и договорённости между компонентами.
• Слабые тесты. Рефакторинг трудно безопасно проверить, если прежнее поведение не закреплено. Включите в объём создание проверок либо обозначьте риск отдельно.
• Смешение исправления и перестройки. В одной ветке одновременно меняются структура и поведение. Разделите их, если это возможно; иначе договоритесь, как отличать ошибки от ожидаемых изменений.
• Много мелких итераций. Комментарий вызывает правку, правка — новый вопрос, затем нужен ещё один проход. Учитывайте повторное ревью, а не только первую проверку.
• Параллельные задачи. Переключение контекста и ожидание ответа увеличивают календарный срок, даже если чистое время работы не выросло.

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

Что делать дальше

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

Термин: неопределённость оценки — разница между тем, что вы уже знаете о задаче, и тем, что выяснится во время работы. Это не ошибка в расчёте, а часть задачи, которую стоит явно обозначить.