Event storming для проектирования сервисов

Скажу честно, я в event storming не бум-бум и никогда не применял на практике. На просторах хабра нашел вводную статью — Моделирование микросервисов с помощью Event storming.

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

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

А вот официальный сайт, если заинтересовались концепцией.

#systemdesign

Как проектировать бизнес-логику приложения?

Вопрос подписчика: с ростом сложности разработки возникает необходимость в проработке логики приложения и будущего интерфейса. Есть ли какие-то приложухи, приёмы, фреймворки, тулзы для помощи в создании абстракций будущего проекта? Слышал про UML-диаграммы, но хочется уточнить, что сейчас в сфере разработки действительно применимо, что нужно и что не нужно.
----------

При нашем участии создавались проекты от месяца до полутора лет и коллективами от 1 до 10 участвующих лиц. Были мы и рядовыми разработчиками, и тимлидами, и даже чисто создавали ТЗ для дальнейшей реализации сторонними силами. По нашему опыту проектной работы, функционал приложения удобно излагать в техническом задании (ТЗ). Подробное ТЗ в текстовом виде содержит набор требуемых фич и покрывает нюансы вроде разграничения ролей, планируемых интеграций и так далее. Само ТЗ можно компоновать по-разному. Довольно удачным является описание через раскрытие сценариев работы приложения. Оттолкнуться можно от user story – это краткое описание функциональности в стиле "возможность добавлять тег к задаче". В ТЗ такую фичу надо детализировать: кто именно может добавлять тег? Теги фиксированные или настраиваются? Настраиваются пользователем или админом приложения? На какие экраны надо выводить тег и где их можно редактировать? Ответы на эти вопросы складываются в кучу нюансов. Удобнее всего описывать ТЗ по экранам будущего приложения, а потом рядом прописать сценарии работы, в каком порядке эти экраны позволят выполнить те самые user story. При этом не надо из ТЗ пытаться делать огромный бюрократический документ. Размер, конечно, зависит от сложности системы, но вот наполнять ТЗ канцеляризмами совсем зло. Формальные подходы типа UML, на наш взгляд, в индустрии не взлетели.

После ТЗ или одновременно с ним неплохо бы нарисовать макеты будущего приложения. Они упрощают восприятие ТЗ и позволяют согласовывать отдельные элементы с широким кругом заинтересованных лиц. Посмотреть картинку приложения куда проще, чем читать ТЗ. Нужные элементы, то есть условные формочки, выпадающие списки и кнопочки нужно накидать на будущие экраны. Сразу становится понятно, не перегружены ли экраны избыточной функциональностью. Рисовать макеты можно хоть от руки, хоть в paint. Конечно, есть более подходящие инструменты вроде figma, но глобально можно использовать что любой инструмент. Figma предоставляет разные библиотеки элементов и берёт на себя вопросы расшаривания макетов – макеты можно отдать дизайнеру, который в фигме же прорисует нормальный интерфейс, из которого потом верстальщик перенесёт всё в код. Дальше вопрос объёма приложения и опыта. Условно, если в paint макет я отрисую за 10 часов, а в figma за 1 час, казалось бы, paint совсем плох. Но! Для освоения figma я потрачу кучу времени, условные 4 часа. Тогда соотношение времени уже не 1 к 10, а 1 к 2. Плюс, сколько всего времени займут макеты? Обычно это относительно малая часть работы. По нашему опыту, для приложения со сроком разработки в год на ТЗ и макеты выделяется меньше 1 месяца, большая часть из которого тратится на выяснение фич и их согласование с заказчиком.

#devfm #systemdesign

RESTful web API design

У Майкрософта есть годный гайд по проектированию RESTful веб-API. Там и фундаментальные вещи, и конкретные рекомендации:
— во главу угла ставить ресурс, а не действие. Не делать ручку create-order, вместо неё делать POST-запрос на orders/<id>. При этом подчёркивается, что внутреннее представление данных не должно просачиваться наружу. То есть за сущностью orders может быть несколько сущностей реальной базы данных

— стараться не усложнять ручку больше, чем двойная вложенность collection/item/collection, например, /customers/<id>/orders. При этом следует найти баланс. С одной стороны, запросы лучше экономить (много запросов = больше нагрузка на сервер и клиент), но при этом на каждый чих слать весь мир в ответе тоже не стоит

— приводятся типовые HTTP-методы. Нередко достаточно GET/POST/DELETE, можно добавить PUT и PATCH. К сожалению, часто семантика этих запросов понимается всеми по-разному. В этом гайде представлено довольно практичное описание. По каждому методу даны нюансы как по применению, так и по особенностям реализации в части возврата ошибок и асинхронным операциям. Важно не забывать про идемпотентность (пост о ней) некоторых методов

— не забыта постраничная навигация в запросе, HATEOAS и версионирование API

#systemdesign

Прекрасная статья ARCHITECTS, ANTI-PATTERNS, AND ORGANIZATIONAL FUCKERY, написанная по мотивам треда в твиттере. Название говорит само за себя.

Очень рекомендую к прочтению.

Свою позицию я выражу двумя цитатами из этой же статьи: «It treats architecture is a job to be done, not a role to be occupied.» и «Don’t become that sad architect. Be an engineer. Own your own code in production. This is the way.»

#systemdesign

Google design docs

Перед тем как разрабатывать что-то серьёзное – расскажи, как ты это будешь делать. Для этого существуют design docs.

В статье рассказывается о том как, устроены design docs в гугле.

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

Автор говорит, что в целом нет каких-то жёстких правил по составлению подобных документов, но указывает набор важных аспектов, которые нужно покрыть:
– Контекст документа
– Цели
– Собственно, дизайн, который должен включать некую системную диаграмму, апишки, хранилища данных, а также ограничения, в которых проектируется система
– Альтернативные решения – супер важный раздел, который расскажет о других рассмотренных решениях и причинах, почему эти решения отбросили

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

#systemdesign

Оффтоп: включили на канале платные реакции, чтобы вы могли нас поддержать. Уверены, это именно то, чего вы все ждали! :D

Всё ли так просто с ретраями?

На первый взгляд ретраи кажутся простым способом улучшить отказоустойчивость. Что может пойти не так? Ребята из Яндекса написали на эту тему большую и захватывающую статью.

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

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

Для решения этих проблем и повышения отказоустойчивости в статье выделяется три способа:
– retry budget – ограничивает количество ретраев в зависимости от количества успешных запросов
– circuit breaker – полностью отключает ретраи, если процент ошибок превышает заданный порог
– deadline propagation – в запросе содержится таймаут, после которого сервер может прекратить обработку запроса

Ссылочка на код, чтобы самостоятельно поэкспериментировать.

В столь же интересном формате у нас был обзор на статью об идемпотентности.

На эту же тему стоит посмотреть видео.

#skills #systemdesign

Для чего нужны архитектурные схемы

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

В недавнем диалоге обсуждали, для чего конкретно нам нужна архитектурная схема? Конечно, кроме того, что это просто красиво.

Пост как раз об этом.

Онбординг. Обычно технический онбординг мы начинаем с архитектурной схемы. Это позволяет новому сотруднику посмотреть на систему с высоты птичьего полета, начать ориентироваться, кто на ком стоял. Тут же можно бегло рассказать о каждом компоненте, внешних зависимостях и способах их взаимодействия. Причем это работает не только с разработчиками. Приходит к тебе нагрузочник и говорит, ну, давай рассказывай, что у вас тут. И перед тем, как кидаться в него жирной пачкой документации, ты такой опа: давай пробежимся по архитектуре, расскажу тебе, как всё устроено.

Обсуждение работ со смежными командами. Обычно разрабатываемая система работает не в соло. И есть соседние сервисы, с которыми нужно интегрироваться. Первичные обсуждения всегда удобно делать с наглядной картинкой.

Обсуждение и планирование больших фичей. Когда планируется разработка чего-то сложного, затрагивающего многие компоненты/сервисы. Опять же, можно собраться с командой разработки, аналитиками, обсудить и зафиксировать первичные договорённости. Эта же картинка будет полезна, когда перед стартом разработки будет презентоваться окончательное решение. При разработке разухабистых фичей, кстати, могут быть полезны design docs.

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

О том, как документировать архитектуру у нас был отдельный пост.

#devfm #systemdesign #edu

Снова о необходимости архитектурных схем

Продолжим пост об архитектурных схемах с более практической стороны.

– Как-то так повелось, что мы используем C4 model. Не нагромождённая и достаточно лаконичная. Если вдруг кому-то кажется, что C4 – это какая-то новомодная модель, спешу разочаровать. Придумана она была почти 20 лет назад.

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

– C4 несложная, но глаз может замылиться, а всё ли сделано правильно? На этот случай на официальном сайте есть чеклист (там же можно скачать pdf), по которому можно быстро проверить вашу схему на соответствие правилам и адекватность.

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

– По моему опыту очень полезной может оказаться Deployment диаграмма. Её можно немного извратить, отойти от канонов и получить примерно такое изображение. Особенно удобно, когда существует целый зоопарк самых разнообразных сервисов. Все они в разных закрытых сетевых контурах, с разными командами поддержки. Кто-то должен предоставить вам кубер, кто-то базы, кто-то s3. Что-то будет в Harvester, что-то в Proxmox. Такая диаграмма поможет разобраться во всём этом и как-то структурировать. А новый девопс на вашем проекте скажет за такое большое человеческое спасибо.

#devfm #systemdesign #tools

Недавно говорили за архитектурные схемы. Ещё одним полезным артефактом команды разработки проекта является табличка с зонами ответственности и компетенциями. И вроде банально, но смотрел в разные проекты и не везде подобное видел.

Структура подобной таблички:
– сервис - самая верхнеуровневая сущность для удобной навигации по табличке. Если у вас монолитная архитектура, то можно эту колонку опустить или взять любую другую верхнеуровневую единицу разделения. Тут главное, чтобы вам удобно было ориентироваться
– модуль – более конкретное уточнение функционала
– ответственный разработчик – кто именно отвечает за этот модуль, с ним советуются, если что-то хотят туда внедрить, его тегают в МРах, к нему идут, если что-то сильно сломалось
– разработчики – те, кто принимал участие в разработке модуля и представляют, что там происходит
– аналитик – если в вашей команде есть системные аналитики, то имеет смысл указать этих ребят в этой же табличке

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

Есть несколько причин, почему это полезно:
– если проект долгоиграющий, то в целом хорошо бы понимать, кто за что отвечает, кто в чём разбирается. На длинной дистанции найдется достаточно количество заинтересантов, которые будут приходить с разными вопросами
– позволяет отслеживать bus factor. Табличка даёт очень наглядное представление, где у нас проблема с зонами ответственности, за какой функционал отвечает всего один человек, и нет у него никакой подмены
– более вдумчиво планировать отпуска. Сразу понятно, кого нельзя отправлять в отпуск одновременно
– и ещё один пункт, который совсем недавно поймали. У нас была проблема, что баги тестироващиками классифицировались по направлениям бек/фронт, но далее они падали на тимлидов, которые должны были вникать и распределять по ответственным и, самое печальное, – тратить свое драгоценное время. Потом мы показали тестировщикам табличку с зонами ответственности, они теперь дотошно диагностируют проблему и закидывают баг сразу на исполнителя. Получилось очень хорошо, ошибок минимальное количество
#devfm #systemdesign

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

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

Всё шло как обычно, тестировщики тестировали, баги заводились, баги фиксились.

Но тут мы решили посмотреть на природу багов. Из-за чего они возникают? Где что-то ломается?

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

Такая классификация позволила нырнуть глубже и посмотреть, в каких местах стоит что-то чинить.

Меня, конечно, в первую очередь интересует системный анализ и разработка, на этом и сосредоточились.

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

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

Вот такие жирные проблемы удалось выявить в результате анализа природы багов и решения, к которым удалось прийти.
#devfm #systemdesign

Вдохновившись выступлениями прошлых лет, побывал тут на 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