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 один к одному, но вы возьмёте принципы мышления: фокус на долгосрочных последствиях, масштабируемость процессов и осознанные компромиссы.