Software Engineering at Google: инженерная культура в масштабе

О чём книга

Титус Уинтерс, Том Маншрек и Хайрам Райт собрали опыт Google в области инженерных практик: code review, тестирование, управление зависимостями, CI/CD, документация, управление знаниями. Книга вышла в 2020 году и доступна бесплатно на сайте Abseil. Это ни учебник по программированию, ни гайд по архитектуре. Авторы разбирают вопрос, который формулируют в первой главе: чем software engineering отличается от programming? Ответ: программирование — это написание кода, а software engineering — написание кода, который живёт и развивается годами, и который поддерживают и модифицируют сотни или тысячи людей.

Книга толстая (500+ страниц), местами читается тяжело, но каждая глава существует как самостоятельное эссе и читается отдельно.

Ключевые идеи

Три фундаментальных принципа

Книга выстроена вокруг трёх осей. Time and Change: код адаптируется на протяжении всего срока жизни проекта. Решение, принятое в 2015 году, придётся пересмотреть в 2020-м — изменятся зависимости, инфраструктура, требования. Scale and Growth: практики, работающие для команды из десяти человек, сломаются при переходе к тысяче. Каждый повторяющийся процесс должен масштабироваться линейно или лучше с ростом организации. Trade-offs and Costs: каждое инженерное решение — компромисс, и зрелая организация принимает решения, осознанно взвешивая стоимость.

Закон Хайрама

Хайрам Райт сформулировал принцип, который назвали его именем: при достаточном количестве пользователей API контракт значения не имеет — кто-то будет зависеть от любого наблюдаемого поведения системы. Каноническая формулировка лежит на hyrumslaw.com.

Закон меняет подход к проектированию API. Можно написать идеальную документацию и зафиксировать контракт, но если API сортирует результаты определённым образом (даже без обещания), кто-то построит на этом свою логику. Поменяется порядок сортировки — их код сломается. Любое изменение наблюдаемого поведения становится потенциально ломающим.

Масштабируемые процессы

Google делает ставку на автоматизацию через политики. Регулярно выполняемая задача должна масштабироваться по человеческим затратам не хуже чем линейно. Политики (code review checklist, style guides, автоматические анализаторы) позволяют сотням инженеров работать в одном монорепозитории без хаоса.

Code review как культурная практика

Google требует одобрения для каждого изменения кода. Книга разбирает, почему выбран такой подход: code review передаёт знания, выявляет баги до мержа, поддерживает единый стиль. Авторы честно признают условия, при которых это работает: быстрое время ответа (часы, не дни), чёткие гайдлайны для ревьюеров и культура, где ревью воспринимают как помощь, а не как контрольно-пропускной пункт.

Тестирование в масштабе

Google классифицирует тесты по размерам: small (unit), medium (integration), large (end-to-end). Соотношение в пирамиде критично: избыток large-тестов делает CI медленным и нестабильным (flaky tests), их недостаток оставляет пробелы в покрытии. Отдельно описано Beyoncé Rule: «если тебе это нравилось, нужно было покрыть тестом».

Что можно применить

Идея трёх осей (Time, Scale, Trade-offs) применима к любым инженерным решениям. Перед архитектурным выбором — три вопроса: как решение будет выглядеть через пять лет? Сработает ли оно при росте команды втрое? Какова цена в сравнении с альтернативами?

Закон Хайрама полезен любой команде, создающей API или библиотеки. Перед каждым релизом стоит спросить: какие наблюдаемые поведения создаются, которые пользователи примут за контракт? Побочные эффекты минимизируются, гарантии документируются отдельно от деталей реализации.

Style guides и автоматические линтеры — самая доступная практика из книги. Масштаб Google не нужен, чтобы завести .editorconfig, настроить ESLint и написать три страницы о том, как команда именует переменные и структурирует модули. Инвестиция окупается каждый день при code review.

Критика

Главная претензия: авторы редко выходят за рамку «это работает для Google» и почти не приводят эмпирические данные для обоснования рекомендаций. Рецензент Мариан Юречко написал разбор, указав на отсутствие контекста применимости за пределами Google.

Многие практики привязаны к масштабу, которого большинство компаний никогда не достигнут. Google работает с монорепозиторием на миллиарды строк кода и инструментами (Blaze/Bazel, Critique, Borg), описанными как решения конкретных проблем, — но эти проблемы возникают при масштабе в десятки тысяч инженеров. Команда из пятидесяти разработчиков столкнётся с другими задачами.

Open-source и взаимодействие с внешней экосистемой почти не освещены. Внутри Google всё завязано на внутренние инструменты: свой CI, свой code review (Critique), свой build system (Blaze), свой монорепозиторий. Команды, работающие с GitHub, Jenkins, Gradle и полирепозиториями, найдут мало практических рекомендаций для своей реальности.

Часть рецензентов на Goodreads отмечает, что книга местами читается как корпоративная самореклама, а авторы недостаточно критичны к собственным процессам.

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