Эволюция ide в Google

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

Так вот, в Google с этим столкнулись ещё в 2011 году. И ответ, который дали senior-инженеры на вопрос «можем ли мы сделать единую IDE для всех?», меня поразил.

Фрагментированная экосистема

В 2011 году один из самых известных инженеров Google — Джефф Дин — получил вопрос: «Есть ли способ сделать хорошую унифицированную IDE для всех Googlers?» Ответ был примерно такой: «Попытка заставить группу разработчиков договориться об общем редакторе — это рецепт несчастья. У каждого разные мнения о том, что важно, и в конце концов это не так уж и важно».

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

Но вот проблема: полезные интеграции всё равно приходилось переписывать для каждого редактора. Поддержка Bazel (система сборки — по сути, «компилятор на стероидах»), Starlark (простой язык для настройки сборки проекта), форматеры кода, интеграция с поиском кода — всё это нужно было делать с нуля для каждой IDE.

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

Например, команда, занимающаяся интеграцией с IntelliJ (мощная среда разработки для Java и не только), появилась около 2015 года. Но зачем целая команда для IDE? Частично потому, что у Google есть уникальный набор инструментов, и хорошая интеграция реально повышает продуктивность. А частично — из-за масштаба монорепозитория (когда весь код компании лежит в одной «коробке», а не разбросан по разным проектам).

Традиционные IDE предполагали, что исходный код, метаданные сборки (настройки того как собирать проект), индексация и анализ происходят локально на компьютере разработчика. При масштабе Google это предположение начинает ломаться.

Облачная ide

Где-то около 2013 года случилось то, чего я не ожидал. Несколько человек начали создавать веб-редактор под названием Cider («Cloud IDE» с добавлением буквы r для запоминаемости).

В компании, большинство инструментов веб-основанные, где люди проводят время в браузере для код-ревью (проверка чужого кода перед его принятием), навигации по кодовой базе через Code Search… в компании, которая использует Chromebook — иметь быстрый способ редактирования файлов из браузера действительно имело смысл.

Но меня удивило другое: Cider стал популярным среди инженеров. Сначала его в основном использовали технические писатели, которые хотели редактировать markdown-файлы без возни с системой контроля версий (программа, которая хранит историю изменений). Рабочий процесс был очень эффективным для исправления опечаток: одним кликом отправляешь pull request (предложение добавить свои изменения в общий код) с опцией автоматического merge после одобрения.

Со временем команда добавляла всё больше функций для разработчиков. Поворотный момент наступил, когда они добавили поддержку автодополнения кода через Language Server Protocol (LSP — протокол, позволяющий редакторам общаться с языковыми серверами, которые анализируют код).

Cider был лёгким клиентом, который открывался намного быстрее традиционных IDE. Вся магия происходила на сервере, который индексировал всю кодовую базу, так что данные были готовы, когда кто-то открывал веб-страницу.

Для понимания: кодовая интеллектуальность требует соединения каждого идентификатора с его типом и ссылками. Это огромный языковый граф (связи между частями кода: где определена переменная, кто её вызывает, какие функции зависят друг от друга), который нужно обновлять при каждом коммите (сохранение своих изменений в истории проекта). А кодовая база Google получает много коммитов в секунду. Плюс IDE нужен доступ к историческим данным — если я работаю над проектом, а мой коллега мерджит свой код, я не хочу сразу видеть эти изменения. Редактор должен использовать граф, соответствующий моей последней дате синхронизации… плюс мои локальные изменения.

С такими функциями популярность Cider продолжала расти. Например, Go-разработчиков убедить перейти было легче, чем Java-разработчиков, потому что те ожидали более продвинутого редактора. Но радость от поиска и кросс-ссылок через миллиард файлов — это реально ощутимо.

Cider v: vscode в качестве фронтенда

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

Всё изменилось в 2020 году, когда автор статьи присоединился к команде tech lead’ом. В то время Cider был доминирующей IDE в компании, и встал вопрос о её будущем. Решили использовать фронтенд VSCode (Visual Studio Code — бесплатный редактор кода от Microsoft).

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

Но даже с дюжиной инженеров во фронтенд-команде потребовалось пару лет, чтобы построить полного преемника Cider. В 2021 году открытая бета использовалась 5000 инженеров, но много работы оставалось по интеграции всего и полировке опыта.

Команде нужно было поддержать контроль версий, интегрировать инструмент код-ревью, предоставить автодополнение и рефакторинг (переписывание кода, чтобы он работал лучше, но без изменения его работы для пользователя) с использованием бэкенда Cider, переработать способ доставки и обновления расширений…

Многие пользователи были преданы старому редактору Cider и ожидали, что каждая маленькая деталь будет такой же в Cider V. Небольшие изменения рабочего процесса или лишний клик здесь и там могли стать блокером для adoption’а. Так что полировка потребовала месяцев итераций. Даже цветовые схемы вызвали невероятное количество дискуссий.

Как заметил Джошуа Блок ещё в 2011 году: «Единственное, что генерирует больше религиозного рвения, чем языки программирования — это текстовые редакторы и IDE».

Единая ide

Я начал пост с вопроса о «единой IDE для всех Googlers». Это не произошло полностью, но к 2023 году 80% разработки основной кодовой базе происходило в Cider V, цифра продолжала расти.

У каждой IDE есть свои плюсы и минусы, но Cider привлёк пользователей лучшими интеграциями с инструментами компании: отличная поддержка контроля версий, интеграция код-ревью, где комментарии ревьюера показываются прямо в редакторе.

Что меня больше всего воодушевляло, это побочные эффекты от того, что большинство пользователей используют один и тот же инструмент. Это означало, что можно инвестировать больше ресурсов в инструмент, потому что каждое изменение имеет больший эффект. Автор статьи был tech lead’ом по расширяемости IDE (технический лидер, главный по технологическим вопросам), и скоро команды по всей компании стали обращаться разрабатывать свои собственные расширения. Через два года около ста внутренних расширений находилось.

В руководство стало продвигать интеграцию AI. Это привело к новым возможностям и улучшениям.

По мере того как больше AI интегрировалось в процесс разработки, инструменты становились всё более мощными.

Конечно, это только начало.

ЭВОЛЮЦИЯ GOOGLE IDE ──────────────────────►
                 
2011        2015        2020        2023│           │           │           │
▼           ▼           ▼           ▼Фрагментация ──▶ IntelliJ ──▶Cider V───▶80% adoption(хаос)       (команда)   (VSCode)    AI‑фичи

Итог такой: история показывает, как Google прошёл путь от фрагментации к единой IDE.

Интересный парадокс: единая IDE появилась не сразу. А потому, что это стало стандартом. И уже потом, когда стал стандартом, это привело к новым возможностям.

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

  idea ──▶ draft ──▶ review ──▶ publish

Ссылки

• Language Server Protocol — протокол для взаимодействия редакторов и языковых серверов
• VSCode — бесплатный редактор кода от Microsoft
• Bazel — система сборки от Google