Источник
Software Engineering at Google (part 1)
Первый пост из серии book_cube с базовым тезисом и ключевыми идеями книги.
Источник
Software Engineering at Google (part 1)
Первый пост из серии book_cube с базовым тезисом и ключевыми идеями книги.
Software Engineering at Google (Делай как в Google. Разработка программного обеспечения)
Авторы: Titus Winters, Tom Manshreck, Hyrum Wright, Google Contributors
Издательство: O'Reilly Media; Питер (русское издание)
Объем: 2020 (оригинал)
Сборник практик и инженерных уроков Google о том, как проектировать и развивать программные системы в долгосрочной перспективе.
Оригинал
ПереводSoftware Engineering / Leadership / Processes
Software Engineering at Google это не «как повторить Google», а как мыслить системно: проектировать инженерную среду, где качество и скорость сохраняются даже при росте команды, кода и операционной сложности.
TL;DR
- Главная идея книги: software engineering это программирование во времени, а не разовая поставка кода.
- Google-фокус на процессах и инструментах нужен не ради бюрократии, а ради управляемости на масштабе.
- Культура командной работы и обмена знаниями рассматриваются как часть инженерной системы.
- Большинство принципов применимы и вне BigTech, если адаптировать практики под свой контекст.
1. Структура книги: 5 частей и 25 глав
I. Thesis
Глава 1
Что такое software engineering
Постановка базового тезиса: мы строим эволюционирующие системы, которые должны жить, меняться и оставаться поддерживаемыми годами.
II. Culture
Главы 2-7
Командная работа, лидерство и продуктивность
Работа в командах, knowledge sharing, лидерские практики и измерение инженерной продуктивности как управленческой дисциплины.
III. Processes
Главы 8-15
Стандарты, review, документация, тестирование
Системные процессы качества: style guides, code review, документация, unit/integration/e2e-подходы и безопасное deprecation.
IV. Tools
Главы 16-25
Инструменты масштаба
Монорепо, code search, build systems, static analysis, dependency management, large-scale changes, CI/CD и compute-платформа.
V. Conclusion
Финал
Культура + процессы + инструменты
Итог книги: устойчивость инженерной системы рождается на стыке организационной культуры, рабочих практик и инженерной платформы.
Разбор Culture
Software Engineering at Google (part 2)
Подробности про главы раздела Culture: командная работа, knowledge sharing и лидерство.
Разбор Culture
Software Engineering at Google (part 2)
Подробности про главы раздела Culture: командная работа, knowledge sharing и лидерство.
2. Ключевые принципы книги
Programming over time
Код живет дольше, чем один релиз. Значит, ключевой критерий качества это способность безопасно менять систему через месяцы и годы.
Processes and scale
Code review, тестовая стратегия и стандарты нужны для снижения вариативности и операционного риска в больших кодовых базах.
Tools and infrastructure
Инструменты не просто ускоряют разработку, они задают границы допустимой сложности и улучшают collaboration между командами.
Culture and collaboration
Инженерные практики работают устойчиво только в культуре, где есть доверие, понятные интерфейсы команд и обмен знаниями.
Practical lessons
Не каждая практика Google переносится напрямую, но принципы системности, наблюдаемости и эволюционности универсальны.
3. Что важно из раздела Processes
Style guides и правила
Консистентность кодовой базы снижает трение и делает автоматизацию качества реальной, а не декларативной.
Code review как механизм обучения
Review одновременно повышает качество, распространяет контекст по команде и ускоряет онбординг новых инженеров.
Документация как актив
Документация поддерживает долгосрочную эволюцию системы и снижает bus factor в критичных областях.
Тестирование по слоям
Unit, test doubles, integration и e2e работают как единая система, где каждый уровень отвечает за свой риск.
Deprecation discipline
Удаление устаревшего кода это часть инженерной гигиены, без которой поддержка старых путей начинает тормозить развитие продукта.
Разбор Processes
Software Engineering at Google (part 3)
Разбор глав 8-15: style guides, review, documentation, testing и deprecation.
Разбор Processes
Software Engineering at Google (part 3)
Разбор глав 8-15: style guides, review, documentation, testing и deprecation.
4. Что важно из раздела Tools
Monorepo + trunk-style flow
Единая кодовая база повышает прозрачность зависимостей и облегчает широкие изменения при наличии зрелых инструментов.
Code search и build philosophy
Быстрая навигация по коду и предсказуемая сборка становятся обязательными, когда размер системы измеряется миллионами строк.
Static analysis и dependency management
Автоматические проверки и контроль зависимостей смещают обнаружение рисков влево и уменьшают цену ошибок в production.
Large-scale changes
Инженерная платформа должна уметь безопасно проводить массовые изменения API, библиотек и контрактов между командами.
CI/CD как инфраструктурная норма
Частая интеграция и поставка изменений требуют не героизма команд, а стабильного pipeline и надежной вычислительной платформы.
5. Типичные антипаттерны внедрения
«Мы не Google, нам это не нужно»
Отказ от базовой инженерной гигиены из-за масштаба компании обычно приводит к росту техдолга и операционных инцидентов.
Процессы ради процессов
Копирование ритуалов без ясной цели перегружает команды и не дает прироста качества или скорости.
Инструменты как замена культуре
Даже лучший toolchain не исправит низкое доверие, слабую коммуникацию и отсутствие ownership у команд.
Игнорирование удаления legacy
Если не управлять устареванием, система превращается в набор компромиссов, где каждый новый релиз дороже предыдущего.
6. Рекомендации для teamlead/EM/Staff+
Сформулируйте engineering-принципы команды
Зафиксируйте 5-7 правил уровня «как мы делаем изменения безопасно» и используйте их в review и архитектурных обсуждениях.
Укрепите контур качества
Проверьте связку style guide -> code review -> test strategy -> CI, чтобы каждый этап ловил свой класс рисков.
Вложитесь в внутренние инструменты
Даже небольшие улучшения DX (поиск кода, шаблоны, automation) окупаются быстрее, чем кажется на длинной дистанции.
Планируйте deprecation заранее
Для каждой новой фичи фиксируйте срок жизни старых путей, миграционный план и owner, чтобы не копить вечный legacy.
2-недельный стартовый план
- Проверить качество code review: SLA, размер PR и ясность комментариев.
- Собрать карту тестового контура: что ловим unit/integration/e2e уровнями.
- Выбрать один legacy-поток и зафиксировать deprecation-план с owner.
- Ускорить поиск контекста: улучшить docs, ADR/RFC и кодовую навигацию.
- Зафиксировать 2-3 инженерные метрики, которые реально помогают принимать решения.