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

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

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

Как и во многих компаниях, в Google разработчики имели возможность самостоятельно выбирать IDE, и из-за этого возникла высокая степень фрагментированности. В 2011 году одним из самых опытных разработчиков-сениоров задали вопрос: «Можно ли как-то сделать так, чтобы все гуглеры пользовались одной хорошей IDE?». Если вкратце, они ответили «Нет». Джефф Дин ответил так:

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

И такое мнение долгие годы оставалось доминирующим. В конце концов, не важно, какими IDE пользуются коллеги, если их код остаётся качественным. Но я двенадцать лет занимался в Google инструментами разработчика, поэтому время от времени задумывался над этим вопросом.

Можно взглянуть на это с точки зрения продуктивности компании: мы не хотим, чтобы каждый разработчик тратил слишком времени на настройку своего редактора. Хотя инженеры пользуются разными IDE, полезные интеграции рано или поздно приходится реализовывать везде: поддержку Bazel, инструментарий Starlark, инструменты автоматического форматирования кода, интеграцию поиска кода и так далее. Эта задача была вполне решаемой благодаря внутренней культуре Google. Разработчики часто органически начинали проекты по созданию инструментария, другие находили их благодаря общей кодовой базе и становились контрибьюторами. В общем случае подобный вклад приветствуется (он мотивируется через систему 20% времени и вознаграждения от коллег). Со временем на критичные проекты официально выделяется штат разработчиков. Например, приблизительно в 2015 году была собрана команда для разработки интеграции с IntelliJ.

Кто-то может задаться вопросом, зачем для этого вообще нужна отдельная команда. Разве IDE изначально не была достаточно качественной? Частично это вызвано тем, что у Google есть набор уникальных инструментов, и обеспечение их удобной интеграции с IDE повышает продуктивность разработчиков. Кроме того, определённые проблемы возникали вследствие самого размера монорепозитория. В традиционных IDE подразумевается, что весь исходный код, метаданные сборки, индексирование и анализ находятся и выполняются локально. В масштабах Google это предположение становится ошибочным.

Cloud IDE

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

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

Но удивило меня то, что Cider в конечном итоге стал пользоваться популярностью у инженеров. поначалу с ним в основном работали технические писатели, которые хотели редактировать markdown-файлы без заморочек с управления версиями. При исправлении опечаток такой рабочий процесс оказался крайне эффективным. За один щелчок можно было отправить пул-реквест с опцией автоматического слияния после его одобрения. Сегодня подобная фича есть и в GitHub, но в то время она казалась мне новой.

Постепенно команда добавляла всё больше фич, ориентированных на разработчиков. Поворотным моментом стало добавление поддержки автодополнения кода через LSP.

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

Code intelligence требует связи каждого идентификатора с его типом и ссылками. Это образует огромный языковой граф, который нужно обновлять при каждом коммите. А в кодовую базу за секунду происходит множество коммитов. Но IDE требуется и доступ к историческим данным. Если я работаю над проектом и мой коллега выполняет мердж своего кода, то мне не нужно подхватывать эти изменения мгновенно. То есть моему редактору нужно использовать граф, соответствующий дате моей последней синхронизации... очевидно, дополненный моими локальными изменениями.

Благодаря этой фиче популярность Cider в некоторых областях продолжала расти. Например, убедить перейти на него было гораздо проще разработчиков на Go, чем на Java (потому что они привыкли к гораздо более многофункциональному редактору). Однако удовольствие от возможности поиска и наличия перекрёстных ссылок между миллиардом файлов было реальным.

Cider V: VSCode в качестве фронтенда

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

Направление развития проекта сменилось в 2020 году, когда я присоединился к нему в качестве одного из техлидов. На тот момент Cider уже была доминирующей IDE в компании, поэтому встал вопрос о её будущем. Было решено использовать в ней фронтенд VSCode. Это было абсолютно логично: VSCode уже доминировала в мире IDE, была языконезависимой, расширяемой и рассчитанной на веб.

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

Даже имея дюжину разработчиков в команде фронтенда, для создания полнофункционального потомка Cider нам понадобилось два года. В 2021 году открытой бета-версией пользовались пять тысяч инженеров, но оставалось ещё много работы по интеграции и совершенствованию UX. Команде нужно было реализовать поддержку управления версиями, интегрировать инструмент для ревью кода, добавить фичи автозавершения кода и рефакторинга с использованием бэкенда Cider, изменить способ выпуска и обновления расширений и так далее.

Многие пользователи полюбили редактор Cider и ожидали, что в Cider V сохранятся все его мельчайшие детали. Небольшие изменения рабочего процесса или лишний щелчок могли препятствовать переходу некоторых пользователей, поэтому совершенствование проекта требовало месяцев итераций. Даже цветовые схемы вызывали абсурдно долгие обсуждения. Как сказал в 2011 году Джошуа Блох, «единственное, что вызывает религиозного рвения, чем языки программирования — это текстовые редакторы и IDE».

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

Общая IDE

Я начал этот пост с вопроса про «общую IDE для всех гуглеров». Процесс ещё не закончен, но к 2023 году 80% разработки в основной кодовой базе Google велось в Cider V (и процент продолжал увеличиваться).

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

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

В 2023 году руководство стимулировало все команды интегрировать всё больше ИИ-фич. Это привело к появлению таких замечательных фич, как Resolving Code Review Comments with Machine Learning и Smart Paste for context-aware adjustments to pasted code. И, разумеется, автозавершение кода при помощи ИИ.

Чем больше ИИ-фич интегрируется в IDE, тем очевиднее становятся преимущества наличия единой расширяемой платформы. Разумеется, она была крайне дорогой и в очень немногих компаниях подобная работа будет оправдана. Но я считаю, что переход к «стандартной» (пусть и не требуемой руководством) IDE оказал очень сильный эффект.

В конечном итоге, стандартный инструментарий становится движущей силой.