В Google обновление открытого пакета чаще занимает до четырёх часов

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

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

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

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

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

Проблема тогда не во внутренней заплатке, а в том, что новая версия самого пакета уже не соответствует прежним ожиданиям кода Google и приходит по чужому графику выпусков. Ещё 31% задержек отнесли к несовместимым изменениям в коде Google: внутренние системы успели измениться так, что старый способ использовать пакет больше не подходит. Общую сложность пакета назвали причиной в 29% случаев.

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

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

Неотданные патчи, число зависимостей и размер upstream-сообщества предложены как метрики, по которым более тяжёлое сопровождение можно пытаться предсказать, а не обнаруживать, когда адаптация уже встала. Даже передача правки в общий проект не снимает остальные причины: на несовместимость upstream пришлось 37% случаев, на изменения кода Google — 31%, на общую сложность пакета — 29%. Опрос не задаёт отраслевой норматив и не сообщает, какую долю открытых компонентов компания обновляет вообще.

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