Google: Software Engineering at Google

Монорепозиторий как философия

Google хранит весь свой код в одном репозитории. Не метафорически, не «большую часть», а буквально всё: больше миллиарда файлов, 35 миллионов коммитов, 86 терабайт данных. Ежедневно 25 000 инженеров вносят 16 000 изменений, а ещё 24 000 коммитов делают автоматизированные боты. Единственное исключение из монорепозитория — проекты Android и Chrome, которые живут в отдельных репозиториях по историческим причинам.

Titus Winters и соавторы объясняют логику этого решения так: Google предпочитает проблемы version control проблемам dependency management (подробнее о trade-offs — в главе про monorepo vs polyrepo). Когда весь код лежит в одном месте, инженер видит все зависимости. Если команда А меняет API библиотеки, она может найти всех потребителей этого API через Code Search и обновить их вызовы в том же коммите. В мире polyrepo эта же задача превращается в координацию между пятью командами, тремя версиями библиотеки и бесконечной матрицей совместимости.

Внешние зависимости (open source библиотеки, лицензированный код) тоже живут в монорепозитории, но в отдельной директории third_party, которая маркирует код с потенциальными лицензионными ограничениями.

Инструменты, которые делают масштаб возможным

Монорепозиторий из миллиарда файлов работает только потому, что Google построил целый стек кастомных инструментов. Ни один из существующих на рынке инструментов не справился бы с такими объёмами, и Google пришлось создавать всё самостоятельно.

Piper — система контроля версий. Google мигрировал на Piper с Perforce, когда тот перестал справляться с нагрузкой. Piper работает поверх Spanner (распределённая база данных Google), реплицируется через 10 дата-центров по всему миру и обрабатывает десятки тысяч операций в секунду.

Clients in the Cloud (CitC) — облачная рабочая среда. Инженер не клонирует репозиторий локально (86 терабайт на ноутбук не поместятся). Вместо этого CitC через FUSE-файловую систему показывает весь репозиторий как локальную директорию, а хранит локально только изменённые файлы. Средний рабочий набор содержит меньше 10 файлов. Инженер открывает любой файл в репозитории мгновенно, без git clone и git pull.

Blaze — система сборки, которую Google позже открыл как Bazel. Blaze умеет собирать только то, что изменилось, кэширует артефакты между всеми инженерами и распределяет компиляцию по кластеру. В монорепозитории без инкрементальной распределённой сборки каждый коммит превратился бы в часовое ожидание.

Critique — система code review. Все изменения в Google проходят через review до коммита. Critique показывает diff, запускает автоматические проверки (линтеры, тесты, статический анализ) и хранит обсуждение. По данным из книги, культурное давление «не коммитить плохой код» работает мощнее любого формального гейта.

Code Search — полнотекстовый поиск по всему репозиторию с индексацией. Инженер вводит имя функции и за секунды находит все её использования среди миллиарда файлов. Code Search интегрируется с CitC: можно перейти из результатов поиска в режим редактирования, внести изменение и отправить на review, не покидая браузер.

Tricorder — платформа статического анализа, встроенная в процесс review. Rosie — инструмент для массовых рефакторингов через весь репозиторий.

Trunk-based development без исключений

Google практикует trunk-based development в его чистом виде: никаких feature branches, никаких long-lived веток. Все 25 000 инженеров коммитят в одну ветку (trunk), которая в каждый момент времени должна быть рабочей. Winters и соавторы пишут, что «существует только одна версия, которая имеет значение».

Это решение ставит жёсткие требования к тестированию. Каждый коммит должен проходить через набор тестов, и Google вкладывает огромные ресурсы в скорость и надёжность тестовой инфраструктуры. Flaky-тесты (тесты, которые падают нерегулярно) Google рассматривает как баги инфраструктуры, а не как мелкие неудобства: ненадёжный тест подрывает доверие ко всей системе тестирования.

Readability — уникальная практика

Одна из самых необычных практик Google — процесс «readability». Для каждого языка программирования (C++, Java, Python, Go) существует группа экспертов, которые проводят readability review. Инженер, который хочет коммитить код на определённом языке, должен получить одобрение от человека с readability-статусом для этого языка.

Readability обеспечивает консистентность по всему репозиторию. Инженер читает чужой код чаще, чем пишет свой, и предсказуемый стиль снижает когнитивную нагрузку при чтении.

Trade-offs подхода Google

Первый и самый очевидный: инструменты Google невозможно скопировать. Piper, CitC, Blaze (в полной внутренней версии), Critique — всё это продукты многолетних инвестиций, которые имеют смысл при масштабе Google. Компания с 200 инженерами не получит тех же преимуществ от монорепозитория, но заплатит высокую цену за настройку инфраструктуры.

Второй: монорепозиторий создаёт зависимость от внутренних инструментов. Инженер Google привыкает к Piper и Critique, а при переходе в другую компанию обнаруживает, что git и GitHub работают иначе.

Третий: trunk-based development без веток требует зрелой культуры тестирования и feature flags. Без возможности коммитить незавершённый код за флагом trunk превращается в хаос.

Что можно позаимствовать

У Google стоит учиться принципам, а не конкретным инструментам. Три идеи из книги «Software Engineering at Google» применимы на любом масштабе.

Первая: инвестируйте в code search. GitHub Code Search, Sourcegraph, OpenGrok экономят часы в неделю даже в репозитории из 500 файлов.

Вторая: стандартизируйте стиль кода через автоматизацию. Линтеры и форматтеры (prettier, black, gofmt) делают readability review ненужным для стилевых вопросов. Оставьте ревьюерам логику и архитектуру.

Третья: относитесь к flaky-тестам как к P1-багам. Если тесты проходят «через раз», инженеры перестают доверять CI. Через полгода ваш CI превращается в декорацию.