Вдохновившись выступлениями прошлых лет, побывал тут на ArchDays 2024.

Были доклады поверхностные – за всё хорошее, против всего плохого, были доклады, где люди просто плохо готовились к выступлению или рассказывали сырой материал.

Однако удалось послушать и два хороших выступления:

▫️Замечательный своей концептуальностью доклад Александра Поломодова про архитектуру Т-Банка, в процессе которого было множество полезных отсылок, которые он опубликовал у себя в канале, и куда можно уже врываться и изучать.

▫️И очень практический доклад Виталия Минко на тему архитектурных принципов. Как только доклад появится на ютубе, обязательно сделаю пост о нём. А пока от него же доклад с одной из прошлых конференций на тему Технического радара. В нём затрагиваются темы: что такое Технический радар, для чего он нужен, когда и как его внедрять в своей компании.

#systemdesign

When to write strategy, and how much?

Отличная статья Will Larson. Она посвящена созданию стратегии в инженерной команде с акцентом на выборе подходящего момента для её написания, определении оптимального объёма и способе внедрения.

В самом начале автор рассуждает о моментах, когда работа над стратегией действительно оправдана, таких как конфликт между командами или важные кадровые изменения, и объясняет, что не всегда правильным решением является создание стратегии "здесь и сейчас". Автор предлагает рассматривать три стратегических состояния: глобально согласованное, частично согласованное внутри команд и несогласованное, указывая, что разработка стратегии наиболее актуальна для ситуаций, когда команда находится во втором или третьем состоянии. Кроме того, если ситуация в компании ухудшается, но состояние стратегий ещё приемлемо, это может стать стимулом к началу работы над ними.

Следующим рассматривается вопрос оптимального количества стратегий. Автор рекомендует ограничивать количество одновременно разрабатываемых стратегий одной или двумя, чтобы обеспечить их успешное внедрение и избежать перегрузки организации. При этом подчеркивается важность постепенного роста стратегий и гибкого видения конечного результата, которое поддерживает принятие мелких шагов. На примере Uber: в какой-то момент возникла проблема надёжности сервисов и скорости их разработки. Для её решения была создана стратегия, направленная на обеспечение безболезненного деплоя и функционирования сервисов. Реализация этой стратегии постепенно привела к решению более глобальной исходной проблемы.

Далее самое интересное. Для внедрения стратегии нужно учитывать масштаб внедрения (команда или вся организация) и стиль изложения стратерии: запретительный (proscriptive, пример: "блокировать MR, если код не прошёл линтеры") или разрешительный (permissive, пример: "давайте использовать линтеры, вот основные правила, в каждой команде можно кастомизировать под себя"). Чем больше масштаб внедрения, например, на уровне всей компании, тем больше разрешительных пунктов должно быть. Иначе вряд ли стратегию получится внедрить.

Немаловажный момент, на который обращает внимание автор – оценка эффективности стратегии, а также её влияние на принятие различных решений.

Статья любопытная, как и многие другие от этого автора :)

#edu #systemdesign

Закон Конвея

Как-то так получилось, что в последнее время вокруг меня несколько раз упоминали закон Конвея.

На волне этого вспомнил статью от Фаулера, в которой он рассказывает о важности закона Конвея в разработке. Согласно этому закону, что любая разрабатываемая система будет отражать организационные связи между командами, которые создают эту систему.

Фаулер предлагает три подхода к учёту закона Конвея:
🔹 Игнорирование — не учитывать закон, что обычно приводит к проблемам в архитектуре.
🔹 Принятие — проектировать систему так, чтобы архитектура соответствовала структуре взаимодействия команд.
🔹 Инверсный манёвр Конвея — перестроить организацию команды для достижения желаемой архитектуры (часто применяется в микросервисах).

В заключении подчеркивается, что важно учитывать закон Конвея не только при создании архитектуры, но и на протяжении всего жизненного цикла проекта, организуя эволюцию архитектуры и организационных структур вместе.
#edu #systemdesign

Недавно делился ощущениями от конференции ArchDays.

Хочу рассказать ещё об одном замечательном докладе "Как мы в Tinkoff принимаем архитектурные решения" от Александра Поломодова.

Особенно мне откликнулись следующие темы:

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

Более детально рассматривается Software Architecture, в том числе о внедрении работы над архитектурой внутрь команд.

Как принимаются архитектурные решения
– RFC (Request for Comments) – документ с описанием проблемы, предложением и обоснованием. Он публично обсуждается, после чего фиксируется решение.
– ADR (Architectural Decision Records) – все решения документируются, включая компромиссы и условия, при которых решение может быть пересмотрено.
– Рабочие группы – временные группы из активных участников разрабатывают предложения и координируют обсуждения.

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

#systemdesign

The implementation of Rewind in Braid

Игра Braid написана одним разработчиком. Доклад от автора, как он реализовал бесконечную перемотку времени назад, учитывая ограничение игровых консолей, где нет условно бесконечной оперативной памяти.

Предлагается занятный вариант реализации – давайте хранить весь мир и его состояние сериализовать. И дальше куча хаков для оптимизации: неизменяемые объекты хранить в единственном экземпляре, фоновые частицы (чисто визуал, условно листья на заднем фоне) перегенерировать в похожем виде на основе случайного числа и текущего времени. Состояние мира хранится в виде цепочек с опорными кадрами (похоже на кодирование видео). Тут я не совсем понял, он предлагает хранить состояние целиком, а не разницу кадров.

Потом обсуждается хранение звука при перемотке. Завершает доклад ещё одна хитрая оптимизация. В раунде с кольцом замедления его способ хранения "примерного" состояния фоновых частиц не работает. Пришлось отдельное решение делать. Приятного просмотра!

#youtube #systemdesign

Задача на собеседовании — проектируем динамическую фильтрацию

Проводили собеседование на разработчика. Задачу для технической части взяли из практики, то есть это прямо то, чем в будущем предстояло заниматься собеседуемому, разве что с упрощением предметной области для понятности. Задача такая:

При поиске товаров на любой торговой площадке есть разухабистые возможности фильтрации товаров. Ваша задача — спроектировать функционал фильтрации результата поиска товаров.

Если вам на собеседовании поставили задачу в такой размытой формулировке, не пытайтесь сразу приступать к её решению. В первую очередь уточните требования и ограничения.

После уточнения задачи получаем следующие вводные:
— имеется клиент-серверное приложение интернет-магазина с возможностью поиска товаров

— количество записей в результате поиска может доходить до 1кк

— к полученным в результате поиска товарам можно применять множественные фильтры, у каждого фильтра есть набор значений

— у разных категорий товаров разный набор фильтров

— после применения конкретного фильтра появляется новая выборка и для нее также должны отображаться только актуальные фильтры
Рассмотрим пример. Для телефонов должны быть фильтры "производитель" и "операционная система". После применения фильтра "производитель: Apple" в фильтрах ОС уже не может быть значения Android.

— для каждого значения фильтра необходимо отображать количество подходящих товаров. После выбора одного фильтра все счетчики должны пересчитываться.
Было "производитель": "Apple: 10", "Xiaomi: 20", "Встроенная память": "128 Гб: 10", “256 Гб: 20". Выбрали "128 Гб", после применения станет, например, "производитель": "Apple: 7", "Xiaomi: 19". То есть 3 модели Apple и 1 модель Xiaomi не попали под выбранный фильтр.

— данные хранятся в postgres. Отдельно подумайте, как можно решить задачу, если у вас не стоит ограничение на базу данных

Как на настоящем собеседовании, уточняющие вопросы можно задать в комментариях. Наше решение задачи в 15:00 понедельника.
#devfm #systemdesign #резюме

Value Stream Mapping

В рамках анализа затыков в процессе поставки релизов наткнулся на статью, рассказывающую о Value Stream Mapping (VSM).

Value Stream Mapping — метод визуализации процесса работы. Он помогает увидеть весь процесс от начала написания кода до деплоя в прод, выявить узкие места и наметить улучшения.

Но, прежде чем строить карту потока, важно понять, зачем мы это делаем. Здесь помогает Outcome Mapping:
1. Собираем ключевых участников.
2. Формулируем, какую стратегическую задачу мы хотим решить.
3. Записываем проблемы, вопросы, идеи.
4. Группируем их, выбираем главную область для улучшения.
5. Формулируем конкретный и измеримый результат.

В статье ещё приводится несколько конкретных примеров Outcome mapping.

Теперь можно перейти к построению VSM.
Что нужно отразить на карте:
— Ключевые шаги — от написания кода до деплоя, тут важно выбрать для себя достаточный уровень детализации процесса, но это можно сделать только эмпирическим путем.
— Задержки — проанализировать и отразить места, где работа простаивает.
— Хенд-оффы — уделить особое внимание на передачу задачи между командами, например, между анализом и разработкой.
— Время ожидания — время, когда кто-то на каком-то этапе кого-то ждет

В целом и раньше подобное делали, но не использовали какую-то конкретную практику. Теперь попробуем применить. Расскажите, применяете ли вы что-то подобное на практике? Как ищете узкие места?

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

#systemdesign

Backup: архитектура систем

Про system design часто пишут в контексте подготовки к собеседованиям. Мы же в первую очередь пишем про практический аспект — зачем архитектура вообще, как её описывать, какими инструментами мы пользуемся, как вообще процесс можно организовать.

— Для чего нужны архитектурные схемы
— Как документировать архитектуру
— Google design docs
— C4 model для документирования архитектуры
— Анализ источника багов как начало улучшения процессов работы в команде
— Фиксируем зоны ответственности проекта
— визуализируем работу с помощью Value Stream Mapping

Это продолжение цикла тематических подборок. Предыдущая подборка материалов по базам данных.

#backup #systemdesign

Прокачать навыки System Design

Периодически коллеги или друзья спрашивают о хороших материалах для подготовки к интервью по System Design или в целом о том, как подтянуть свои навыки по System Design.

И уже достаточно давно я рекомендую небольшой курс (просьба не пугаться слова «курс») по System Design.

– если готовитесь к интервью, вы получите базу о том, как такие интервью проводятся, что важно для интервьюера, и достаточно оперативно получите фундаментальные знания, чтобы проходить такие интервью
– если хотите подтянуть навыки проектирования – этот курс даёт структурированную базу, и вы будете понимать, куда копать дальше, чтобы расширить знания

Начать рекомендую с видео от автора курса на YouTube.

Если никогда не проходили интервью по System Design, обязательно посмотрите мок-интервью от коллег из Тинька. Отличный разбор того, как проходит интервью, как правильно строить ответ, какие вопросы задавать и как углубляться в темы.

#systemdesign

Шаблонный сервис

Я всячески люблю, когда разработка идёт предсказуемо – и многое для этого делаю.
Давно хотел написать пост о важности шаблонного сервиса, но не было хорошего примера под рукой. И тут мой коллега выложил наш шаблонный сервис на FastAPI, который мы долгое время использовали и развивали.

Так зачем же нужен шаблонный сервис?

Легко ориентироваться в других сервисах. Иногда нужно залезть в сервис коллег, или поддерживаешь несколько сервисов. Никаких проблем – структура везде одинаковая, всё знакомо, не нужно тратить время на раскопки.

Быстрый старт. Стартуете новый сервис? Полчаса – и он готов. Никаких лишних приседаний.

Единые практики. Шаблон определяет, не только структуру, но и то, как мы, например, делаем ретраи, какие у нас зависимости. как устроен circuit breaker, обработка ошибок и т.д.

Лучшие практики – в одном месте. Если появляется что-то классное, мы добавляем это в шаблон и новые сервисы сразу это наследуют.

Обсервабилити, логирование, работа с секретами – готово из коробки. И меньше шансов, что кто-то забьёт на логирование до лучших времён»:)

Онбординг на кошечках. Новый человек сначала изучает шаблонный сервис, понимает подходы, а потом уже ныряет в боевые системы.

Просто экспериментировать. Создал веточку от шаблона – и прикручиваешь свою новую махарайку, не тратя время на базовую структуру.

Унификация линтинга. Конфиги линтеров лежат в шаблоне. Ничего настраивать не нужно, а код-ревью идёт быстрее – обо всём уже однажды договорились и зафиксировали.

Базовый CI/CD. Для шаблонного сервиса существует шаблонный ci/cd – и это очень удобно.

Мы активно использовали шаблонный сервис в микросервисной архитектуре, но и для монолитных решений он тоже отлично зашёл – стартовали с ним несколько проектов.

Понимаю, что это нужно не всем. Но если вы занимаетесь продуктовой разработкой и играете вдолгую — на мой взгляд, это мастхев.

В общем – заходите, смотрите, ставьте звездочки. И если с чем-то не согласны – пишите в комменты, автор обязательно ответит 🙂

#devfm #systemdesign