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