Инструменты, которыми пользуются каждый день, один за другим переписывают на Rust: линтеры, форматтеры, сборщики, менеджеры пакетов, транспиляторы. Разница в скорости там действительно велика, и вопрос «переезжать ли» звучит риторически — пока не начинаешь считать.
Ниже модель расчёта в часах, куда подставляются ваши значения. Она одинаково работает и для команды из трёх человек, и для платформенной команды, обслуживающей полсотни репозиториев.
Тупик: сравнить время одного прогона
Первое, что пробуют, — запустить старый инструмент и новый на своём проекте, сравнить время и умножить разницу на число запусков в день. Получается впечатляющее число, и на нём обычно и останавливаются.
Не помогает это по трём причинам.
Экономия на прогоне — не экономия времени человека. Если проверка идёт в фоне, пока разработчик пишет дальше, ускорение не превращается ни во что. Освобождается машина, а не человек.
Умножение на число запусков предполагает, что все запуски одинаково ценны. Это неверно: важен один запуск — тот, которого ждут, — и десятки, которых не ждут.
И главное: сравниваются две величины, а решение принимается по третьей. Переезд стоит часов, и не только на замену команды в конфигурации.
Что считать
Разовые часы на переезд. Заменить инструмент в конфигурации проектов — самая маленькая строка. Дальше начинается настоящее: перенести правила, которые накопились годами; разобраться с правилами, у которых нет прямого соответствия; переписать самописные расширения, если они были; починить то, что новый инструмент считает ошибкой, а старый не замечал; обновить документацию и шаблоны; провести это через все репозитории.
Разовые часы на несогласие. Новый инструмент почти всегда чуть иначе форматирует и чуть иначе ругается. Это порождает разовую волну правок во всех файлах и обсуждения, которые стоят дороже, чем кажется.
Регулярные часы после переезда. Обычно отрицательные, и это хорошая новость: меньше ожидания в интерактивной проверке, быстрее реакция на сохранение файла, короче цикл в непрерывной интеграции.
Регулярные часы на риск. Молодой инструмент чаще меняет поведение между выпусками, и у него меньше готовых ответов на редкие ситуации. Заложите часы на «разобрались, что это его особенность».
Выгода в человеческих часах. Считается только там, где человек ждёт. Три места: проверка при сохранении файла, локальный прогон перед отправкой, ожидание результата сборки, когда от него зависит следующий шаг. Всё остальное ускорение — про загрузку машин, и его считать в этой модели нельзя.
Как измерить своё ожидание
Величина, вокруг которой строится весь расчёт, — сколько раз в день человек ждёт инструмент. Её не надо угадывать, её можно наблюдать неделю.
Попросите нескольких человек отмечать три вещи: сколько раз за день они ждали проверку перед отправкой изменений, сколько раз ждали результат сборки, чтобы сделать следующий шаг, и сколько раз выключали проверку, потому что она мешала. Третий пункт важнее первых двух: выключенная проверка — это не ноль ожидания, это перенесённая на потом ошибка.
Полученные числа умножаются на разницу во времени прогона, и получается недельная выгода в часах. Обычно она оказывается меньше ожидаемой в фоновых сценариях и больше ожидаемой в интерактивных — именно поэтому считать надо раздельно, а не одним числом.
Где проходит граница
Соотношение, которое обычно определяет ответ: переезд окупается, когда инструмент стоит на пути человека, а не в фоне.
Форматирование и проверка при сохранении, подсказки в редакторе, локальная проверка перед отправкой — здесь каждая доля секунды превращается в поведение: медленную проверку выключают, быструю оставляют. Это самая большая и наименее очевидная выгода — не сэкономленное время, а восстановленная привычка.
Ночные прогоны, полные пересборки, задачи по расписанию — здесь ускорение не даёт человеческих часов совсем. Оно даёт деньги за вычисления, и это отдельный расчёт с другими величинами.
Второй признак — число репозиториев. Разовая часть расходов умножается на них почти линейно, а выгода — на число людей. Много репозиториев и мало людей — худший случай для переезда.
Третий — возраст конфигурации. Набор правил, который собирали годами и который никто целиком не помнит, переносится дорого и с потерями. Молодая конфигурация переносится почти бесплатно.
Промежуточный вариант, который пропускают
Не обязательно переезжать целиком. Быстрый инструмент можно поставить только туда, где человек ждёт, — в редактор и в предотправочную проверку, — оставив старый в непрерывной интеграции как окончательное суждение.
Схема выглядит компромиссной, но у неё есть отдельная ценность: она даёт основную выгоду сразу, а разовую часть расходов растягивает. Плата — расхождение между тем, что видит разработчик локально, и тем, что скажет сборка. Терпимо, пока набор правил близок, и мучительно, когда нет.
Второй промежуточный вариант — переехать на одном репозитории и посмотреть, сколько часов это заняло на самом деле. Оценка по факту одного переезда точнее любых рассуждений, а масштабировать её на остальные легко.
Чего расчёт не покажет
Он не покажет качество проверок. Быстрый инструмент, который находит меньше, — это не выигрыш, а размен, и его надо сравнивать отдельно, на своей кодовой базе.
Он не покажет стоимость раздвоения экосистемы: если половина инструментов новая, а половина старая, появляется класс задач «согласовать их между собой», которого раньше не было.
И он ничего не говорит про язык, на котором инструмент написан. Rust здесь причина скорости, но не аргумент: выбирают инструмент по поведению, а не по тому, на чём он собран.
Он не покажет и того, что часть выигрыша съест привычка. Инструмент, который отвечает мгновенно, начинают запускать чаще — и суммарное время ожидания иногда не падает, а перераспределяется. Это не аргумент против переезда: ждать по чуть-чуть и видеть ошибку сразу лучше, чем ждать долго и узнавать о ней через полчаса, — но в арифметике это надо учитывать честно.
Позиция редакции
Мы считаем, что переезд на быстрые инструменты окупается прежде всего там, где человек ждёт результата, и почти не окупается в фоновых прогонах. Практический вывод: начните с редактора и локальной проверки, оставив сборку как есть, — так основная выгода приходит в первую неделю, а расходы распределяются.
Мы неправы, если ваша боль — не ожидание, а счёт за вычисления в непрерывной интеграции. Тогда считать надо не человеческие часы, а машинное время, и порядок действий обратный: сначала фоновые прогоны, потом всё остальное.