Sobesin — Frontend Developer/
🏗️
Архитектура/
Стратегии организации кода (Уровень репозитория)
Search

Стратегии организации кода (Уровень репозитория)

🎯 Зачем спрашивают
Интервьюер хочет понять:
  • Насколько кандидат мыслит системно и архитектурно, а не на уровне «одного приложения».
  • Понимает ли он, что организация кода — это часть инженерной культуры, а не просто структура папок.
  • Умеет ли он взвешивать компромиссы между скоростью, масштабируемостью и удобством разработки.
  • Имеет ли опыт работы в разных организационных моделях (монорепо, полирепо, гибрид) и осознаёт их влияние на CI/CD, тестирование и командные процессы.
  • Может ли кандидат аргументированно защищать выбранную стратегию, а не «следовать моде» (например, не говорить «монорепо модно, значит лучше»).
 
📝 Ответ
Что это: Решение о том, как мы храним наш код в системах контроля версий (Git).
Стратегии хранения кода влияют на процессы разработки и сборки.
Виды стратегий
Монорепозиторий (Monorepo)
Код для нескольких проектов/приложений/пакетов хранится в в едином репозитории, но с разделением на независимые пакеты/папки (по сервисам, библиотекам, приложениям).
1 репозиторий = 1+ проектов Технологии для поддержки монорепозиториев:
  • Nx
  • Turborepo
  • Lerna
  • Rush
  • Bazel
  • pnpm workspaces / Yarn Workspaces
 
Мультирепозиторий (Multirepo)
Каждый проект/сервис/пакет хранится в своём собственном изолированном репозитории.
1 репозиторий = 1 проект
 
⚖️ Компромиссы
TLDR: Монорепо — больше контроль и унификация. Мультирепо — больше автономии и простоты.
 
Управление зависимостями
Монорепозиторий:
✅ Можно централизованно обновлять общие пакеты (например, shared utils) ✅ Единая версия зависимостей в проектах
 
 
Мультирепозиторий:
✅ Изоляция, меньше неожиданных конфликтов ❌ Разные проекты могут использовать разные версии библиотек. Это может приводить к долгой цепочке обновлений зависимостей: библиотека А → библиотека Б → приложение.
 
Кейс В одном из моих рабочих проектов было 40 микрофронтовых приложений (каждый в своей репе). Каждый такой проект тянул связку библиотек: types, components, core-utils 
graph TD
    A[app] --> B[components]
    A --> C[core-utils]
    B --> D[types]
    C --> D
Проблема начинается тогда, когда необходимо сделать правку в одной из библиотек, то приходиться проходить весь процесс разработки: код-ревью, публикация новой версии, а это все занимает время.
 
Совместная разработка
Монорепозиторий:
✅ Легко вносить сквозные/комплексные изменения в несколько сервисов/модулей за раз
 
 
Мультирепозиторий
✅ Каждый репозиторий независим — меньше риска случайных изменений
❌ Трудно сделать глобальный рефакторинг между всеми проектами
 
 
CI/CD и сборка
Монорепозиторий:
✅ Можно делать инкрементальную сборку с Bazel/TurboRepo/Nx.
❌ Долгие билды и тесты (если не оптимизировать. Можно настроить сборку и прогон тестов только изменившихся модулей).
 
 
Мультирепозиторий
✅ Атомарные (маленькие и быстрые CI пайплайны) ❌ Необходимо обеспечить единые стандарты (единые пайплайны, единые настройки, единые конфиги, вынесененные в отдельную библиотеку, к примеру).
 
 
 
Контроль версий и релизы
Монорепозиторий:
✅ Можно версионировать всё вместе (например, один тег релиза).
❌ Иногда слишком жёсткая связанность версий
 
 
Мультирепозиторий
✅ Можно релизить сервисы независимо ❌ Сложнее отслеживать совместимость между версиями (сервисы и микрофронты могут зависеть друг от друга в сквозном функционале. Нередки случаи, когда один из сервисов уже зарелизили с новым функционалом, а другой еще нет. Но это лечится через feature toggle).
 
 
Developer Experience (DX)
Монорепозиторий:
✅ Единая структура, стандарты, линтеры, форматтеры, скрипты.
 
 
Мультирепозиторий
✅ Простота для атомарных и независимых команд. ❌ Нужно синхронизировать практики между репами за счет отдельных библиотек с конфигами и задокументированных договоренностей
 
 
 
Code ownership / review
Монорепозиторий:
✅ Единая система ревью и правил.
❌ Может быть «шум» от чужих изменений.
 
 
Мультирепозиторий
✅ Каждый репо имеет свою команду и ревьюеров. ❌ Каждая команда может начать вариться в своем собственном соку, не погружаясь в проекты соседних команд. Требуется кросс-опыление через ревью рулетки, чтобы команда была погружена не только в своей проект.
 
Масштабируемость
Монорепозиторий:
✅ Google, Facebook, Microsoft успешно масштабировали monorepo (с нужными тулзами). Пример
❌ Требует сильных DevOps-инструментов.
👉
Но эти компании вкладывают миллионы в tooling (Bazel, Buck, internal CI/CD). Для компаний меньшего масштаба такая модель часто избыточна.
 
 
Мультирепозиторий
✅ Масштабируется организационно (каждая команда — свой репо).
 
Инфраструктура и инструменты
Монорепозиторий:
❌ Нужны специальные тулзы: Bazel, Lerna, Nx, Turborepo, Pants.
❌ Сложнее настроить CI/CD без таких тулзов.
 
 
Мультирепозиторий
✅ Можно использовать обычные CI/CD пайплайны GitHub Actions, GitLab CI.
❌ Нет централизованного управления сборками.
 
 
🔎 Встречные вопросы
  • Как организовать монорепо в компании с десятками команд?
  • Когда стоит перейти с полирепо на монорепо?
  • Когда стоит перейти с монорепо на полирепо?
  • Какие инструменты помогают оптимизировать CI/CD в монорепо?
  • Можно ли смешивать подходы (часть сервисов — монорепо, часть — отдельные репы)?
 
🚩 Красные флаги
  • Монорепо — это просто когда всё в одной папке
  • Полирепо всегда лучше, потому что независимость
  • Монорепо невозможно масштабировать
 
🛠 Практика
 
📚 Источники / ссылки
  • YouTubeYouTubeArc — внутренняя VCS для монорепозитория Яндекса / Степан Полохин (Yandex Infrastructure)
    Arc — внутренняя VCS для монорепозитория Яндекса / Степан Полохин (Yandex Infrastructure)

    Arc — внутренняя VCS для монорепозитория Яндекса / Степан Полохин (Yandex Infrastructure)

    Приглашаем на конференцию HighLoad++ 2025, которая пройдет 6 и 7 ноября в Москве! Программа, подробности и билеты по ссылке: https://highload.ru/moscow/2025 ________ Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем Highload++ 2023 Презентация и тезисы: https://highload.ru/moscow/2023/abstracts/10676 Репозиторий Яндекса просто громадный и, для того чтобы с ним вообще можно было работать, приходится прибегать к куче хитростей. В докладе мы расскажем вам: * Какие системы контроля мы перепробовали... Нашли ошибку в видео? Пишите нам на support@ontico.ru

    YouTubeYouTube