Архитектурная ката

Архитектурная ката

07.12.2024

Архитектурные каты — это групповые упражнения, которые помогают развивать навыки проектирования программ. Слово ката пришло из японского языка, оно означает приём, который ученики отрабатывают путём многократного повторения. В программировании каты популяризировал Роберт Мартин. Есть упражнения по TDD, алгоритмам, паттернам и, в том числе, по архитектуре.

В субботу 7 декабря московский клуб программистов провёл архитектурный ретрит. Приглашали тех, кто пишет бекенд, миддлов, сеньоров и тимлидов, тех, кому интересна архитектура и кто хотел в ней прокачаться.

Собрались в анти-кафе CheckPoint. Ката шла около двух часов. Поделились на команды и решали архитектурную задачку.

Платформа для совместной разработки

Мы хотим разработать платформу для совместной разработки — аналог GitHub, GitLab, Bitbucket. Пользователи: сотни тысяч разработчиков. Требования: Пользователи могут:

  • Регистрироваться
  • Создавать репозитории
  • Управлять доступами
  • Работать с задачами (issues): создавать, проводить по статусам, комментировать. Статусная модель фиксированная.
  • Делать форки
  • Работать с запросами на изменение (pull requests): создавать, одобрять, сливать, оставлять замечания, видеть историю изменений.

Последующие требования: Если осталось время, можно подумать про:

  • Масштабирование (что если десять миллионов разработчиков).
  • Уведомления (в браузер, на почту, SMS, push).
  • Внешняя аутентификация через OAuth, LDAP (Active Directory).
  • Десктоп и мобильные клиенты.
  • Прикрепление файлов (изображений, видео) к задачам и комментариям.

Правила

  • Сначала каждый участник оценивает свой опыт проектирования: опытный, неопытный и нулевой. Нулевой уровень означает, что участник не обладает опытом разработки, например, он менеджер проекта или владелец продукта.
  • Затем разбиваем участников на команды по 4–6 человек. Сначала распределяем опытных участников: их должно быть приблизительно поровну в каждой команде. Затем распределяем остальных участников. Важная рекомендация: не идти в одну команду со своими коллегами.
  • Команды получают одну и ту же задачу. Цель — разработать архитектуру веб-приложения. Задача формулируется в общем виде. Команды могут задавать модераторам уточняющие вопросы. Сбор требований обычно длится 15-20 минут, но вопросы можно задавать до самого конца обсуждения.
  • Основную часть выделенного времени команда обсуждает разные варианты архитектуры и готовит проект. Важные аспекты проекта перечислены в нашей Памятке, которая выдаётся каждой команде.
  • Команда должне не только разработать архитектуру, но и представить её другим участникам. На это выделяется 20–30 минут в конце обсуждения. Надо выбрать участников, которые будут представлять архитектуру, их может быть несколько. Подготовьте план презентации. У вас будет флип-чарт и фломастеры. На представление выделяется 5 минут.
  • Ещё несколько минут другие участники могут задавать команде уточняющие вопросы. Вопросы могут быть самые разные, например: почему здесь реляционная база, а не документная? Как приложение будет масштабироваться, если на сайт придёт миллион человек? Не надо вступать в дискуссию, за этим будут следить модераторы. Дискуссии можно продолжить после завершения официальной части.
  • После презентации участники в зале оценивают проект путём голосования. Есть три варианта:
    • команда знает, как решать технические сложности;
    • команда в целом знает, как решать технические сложности, но некоторые аспекты не проработаны;
    • в представленном проекте есть существенные пробелы, в представленном виде он не заработает;
  • В конце подводим итоги, делимся инсайтами. Затем — неформальное общение.

План проведения

Предполагаемое количество участков: 10 и больше. Предполагается, что в каждой команде будет около 5 человек, так что если собирается 25 участников, всего получится 5 команд.

00:00-00:10 Объяснение правил В это время народ может собираться. Правила лучше распечатать и раздать командам.
00:10-00:20 Разбиение на команды Каждый участник должен оценить себя как опытного или неопытного. Нужно следить за тем, чтобы количество опытных людей в каждой команде было приблизительно одинаковым.
00:20-01:30 Проектирование Сбор требований, непосредственно проектирование, подготовка презентации.
01:30-02:00 Презентация проектов Каждой команде выделяется 5 минут на презентацию. Другие участники могут задавать вопросы, но не вступать в дискуссии. В конце участники оценивают проект (большой палец вверх, вбок, вниз).

Памятка

  • Доступность и Надёжность
    • Распределение на несколько дата-центров
    • Балансировка нагрузки
    • WebSockets, polling, stream API
    • CDN (Content Delivery Network)
    • DNS
    • Метрики
    • Недоступность внешних сервисов
  • Безопасность
    • Аутентификация/Авторизация
    • Rate limiting (ограничение числа одновременных запросов)
    • Circuit Breaker
    • Шифрование данных
    • Аудит
    • Спам, вандализм
    • Резервное копирование
  • Масштабирование
    • UUID/автоинкремент/автоинкремент с шагом
    • Идемпотентность
    • Распределённые транзакции
    • Конкурентность
    • Горизонтальное, вертикальное
  • Кэширование
    • Объём дисковой и оперативной памяти
    • Инвалидация
    • Очистка (eviction)
  • Базы данных
    • Реляционные, колоночные, документные, ключ-значение, графовые, географические, full-text
    • Шардирование, партиционирование, репликация
    • ACID/CAP
  • Внешние сервисы
    • Платёжные системы
    • Google Maps, Open Maps
    • 1С, CRM, HR-директории в компании
    • SMS-шлюзы, E-mail, Push-сервисы
  • Сопутствующие сервисы
    • Уведомления
    • Логирование
    • Поиск
    • Аналитика
  • Технические решения
    • Фоновые процессы, задачи по расписанию
    • Очереди сообщений
    • Файловые хранилища
    • Стриминг (видео, аудио)
  • Развёртывание
    • CI/CD
Архитектурная ката
Архитектурная ката
Архитектурная ката