ПРО АНАЛИТИКА | СИСТЕМНЫЙ АНАЛИТИК | АЛЕКСАНДР НЕЗДЕМИНА

Очень часто вижу новости о том, что свершилось чудо и в HTTP протоколе появился новый метод - QUERY. Если так подумать, то это не сильная революция, но она сможет снять головную боль в кейсах, когда вам надо было сделать гигантские фильтры. ➡️ Почитать про метод можно тут Интересно, как быстро его начнут внедрять в проекты, что думаете?

Вчера наткнулся на классичейский кейс, который любят давать продакты на интервью, после технички. Звучит так:

"Хочу, чтобы каждое утро у меня на столе лежал бутерброд. Как ты это реализуешь?"

Кому попадался такой кейс - ставьте 🔥 Что обычно делает аналитик? Правильно, идет копать эту тему и начинает мучать продакта. - Какой хлеб, - какая начинка, - во сколько положить, - кто готовит, - что с бутиком делать в выходные. Ну вы поняли, то есть начинает собирать контекст. Однако, это типичная ситуация на которой вы завалитесь, потому что не надо сразу бежать и крафтить бутики, пока не поймете, а ЗАЧЕМ он хочет его получить. ➖➖➖ Что нам надо выяснить в самом начале? Почему бутерброд? Это можно делать через пять ПОЧЕМУ. Исходя из ответов, уже будет понятно, что с этим делать. Действительно нужен бутер или может быть нужен комплексный завтрак, а может быть нужно альтернативное решение и вообще надо такси заказать и в рестик отвезти. Ну вы поняли 😉 Когда понятно стало зачем, допустим, хочет сытно завтракать, начинаем углубляться и выяснять глубинные потребности: ✔️ Какая цель? Что он этим завтраком хочет получить? Взбодрится, отвлечься, что-то еще. ✔️ Что для него "сытный завтрак"? ✔️ Есть аллергии, ограничения, рекомендации врача? ✔️ Во сколько он в офисе и обязательно ли еда должна ждать на столе? ✔️ Кто это готовит, заказывает и оплачивает? Поняв ответы на все вопросы, в итоге у вас вряд ли по итогу окажется бутерброд 😁 У вас будет совершенно другое решение. ➖➖➖ Подытожу 2 мыслями: ✔️ Если вам задают такие абстрактные вопросы на собесе, то не бегите вперед паравоза и не сразу решайте задачу, а повыясняйте. ✔️ Когда мы работаем в проектах, очень часто при интеграциях всплывают такие хотелки заказчика. Только они не выглядят, как бутик, а просто заказчик приходит не с потребностью, а с готовым решением, например, "сделай мне выгрузку в Excel", "прикрути вебхук", "добавь поле status". При этом часто, то что он себе придумал делать - ну вообще не надо и это так не работает. Поэтому не тащите в разработку первое, что озвучил клиент, а отделить его решение от настоящей потребности.

Всем спасибо за участие 🔥 Вы капитальные красавчики и красавицы! Что мне понравилось из ваших ответов: 1. Почти все нашли бесконечный цикл на схеме; 2. Дубль задачи "Проверить оплату"; 3. Неподписанные ветки у шлюза "Оплата есть?"; 4. Менеджер запустил процесс, а ответного действия у него нет. В целом, это закрывает практически все. Но я чуть-чуть дополню мысли. ➖➖➖ Был комментарий, что с точки зрения логики все ок, а вот с точки зрения схемы - нет. Если нас просят разробрать на собеседовании именно схему, то обычно хотят понять: ✔️ понимание поведения, ✔️увидеть понимаете ли вы ошибки на самой схеме или нет. ✔️ шарите ли вы за BPMN, в целом, но если вы еще найдете ошибку в логике, то это будет супер 🔥 Теперь к схеме. ✖️ Первое, что мне не нравится на ней, в целом нейминг: "Нужно проверить факт оплаты." Это бантик, но лучше писать: «Проверка оплаты». Или вообще, это вынести в название схемы. ✖️ Дальше, самая главная ошибка, бесконечный цикл, в случае, если оплаты нет. В ветке с таймером. Если клиент вообще не делал оплату, то и бухгалтер устанет проверять, и менеджер будет в неведении и будет слать повторные запросы. Поэтому тут нам нужно сделать или поток со счетчиком (сколько мы можем сделать проверок, и после нескольких ретраев уведомлять менеджера, что оплаты нет). Либо, я бы вообще убрал такой цикл и просто проверял бы есть оплата или нет и отдавал сразу ответ менеджеру без доп проверок. И вообще убрал этот не нужный цикл. Понятное дело, что для того, чтобы сделать финальное решение, надо понимать еще бизнес-контекст, зачем тут таймер. Но все же, люблю процессы с наименьшим сопротивлением. Поехали дальше. ✖️ Еще одна из ошибок - это то, что у процесса всегда есть только один конец процесса. То есть пока мы оплату не получим - процесс не завершится. Тут стоит добавить еще выход в случае, если оплата не получена. В принципе это вытекает само собой из предыдущего пункта. ✖️ Еще один глобальный косячек состоит в том, что задачу инициирует Менеджер, но закрытие процесса происходит на уровне Бухгалтера, а при этом менеджер остается в неведении. По -хорошему, нужно добавить действие на уровень Менеджер. Например, "Обработка ответа от Бухгалтера" и уже на его уровне сделать, если оплатил, то закрыть процесс, если не оплатил, то завершить процесс с негативным сценарием или отправить повторный запрос. ➖➖➖ Дальше будут чисто визуальные мелочи, но на собесе за них могут зацепиться. ✖️ Ветки шлюза не подписаны. Там где стоит IF на вопрос Оплата есть, нет подписи да/нет. ✖️ Две одинаковые "Проверить оплату" В идеале цикл должен возвращаться к существующей задаче, а не к копии, но если схема сложная и громосткая, то такое допустимо. ✖️ Название действий немного длинные. "Запросить у бухгалтера проверить оплату" можно заменить на "Запросить проверку оплаты". На этом пожалуй все. Было полезно - ставьте 🔥 и я разберу еще какую-нибудь задачку.

Давненько у нас с вами не было задач 😉 Последнее время мне часто попадаются задачки на BPMN на собесах у СА. Честно, не знаю с чем связано, возможно у всех CAMUNDA зависли, но все же, давайте покрутим задачку 🔥 Ваша задача - найти, что не так с этой схемой Погнали 🚀

Почему 6 TCP-соединений, а не 4? В посте про HTTP/1.1 и HTTP/2 прилетел классный вопрос:

почему на схеме HTTP/1.1 стоит 6 TCP-соединений, а не 4, если запросов всего 4?

Давайте разбираться ➖➖➖ Начну с того, что цифры 4 и 6 на картине - это про разные вещи. Цифра 4 - это сколько запросов шлет страница в примере из поста. 6 - это лимит браузера, т.е. сколько параллельных TCP соединений он готов открыть К ОДНОМУ ХОСТУ. В Chrome и Firefox по умолчанию их как раз 6. И тут пожалуй надо дать пояснение, ЗАЧЕМ вообще открывать несколько соединений? Помните, что когда я приводил примеры, то я сказал что в HTTP/1.1 одно соединение - это одна однополосная дорога, где машины едут строго друг за другом, один запрос за раз. Теперь представьте, что нам нужно передать данные параллельно. В этом случае браузер откроет несколько TCP соединений. И максимальное количество будет равно 6 на один хост, то есть фактически у нас есть 6 дорог. А что будет, если запросов будет 20? То в этом случае у нас откроется 6 соединений, а остальные 14 будут ждать на обочине, пока освободится любая из дорог. Надеюсь с аналогией стало понятно? Если по схеме остались вопросы - кидайте в комменты, разберем.

Люблю элегантные решения на экранах ошибки и не видео одно из них 😉 Это в мобильном приложении Дом от ГосУслуг такая милая идея. Единственное, когда я первый раз увидел этот экран, то знатно завис, потому что на экране не работали стандартные паттерны, например, скрол вниз. Поэтому, когда проектируете какие-то экраны, то не забывайте про поведение пользователя 😉 Кстати, как вам такая идея и чтобы вы, как СА добавили, чтобы улучшить UX для пользователя?

5 КНИГ, КОТОРЫЕ Я ХОЧУ ПРОЧИТАТЬ В 2026 ГОДУ ПО СИСТЕМНОМУ АНАЛИЗУ Если бы меня спросили еще год назад, что почитать, чтобы прокачать себя в теме СА, то я смело бы назвал неизменную классику: 1. Software Requirements — Карл Вигерс, Джой Битти 2. Writing Effective Use Cases — Алистер Коберн 3. User Story Mapping — Джефф Паттон 4. Clean Architecture — Роберт Мартин 5. И что-нибудь вроде паттернов проектирования. Но не в этом году С учетом того, что у нас все больше становится популярен подход, когда мы используем ИИ, работаем с Event-Driven Архитектурой, уже надо классику знать, а читать что-то новенькое. Вот открыл для себя такую подборку: 1. AI Engineering. Chip Huyen (2025) Как устроены системы на LLM: RAG, агенты, оценка моделей. 2. Designing Machine Learning Systems. Chip Huyen (2022) Полный цикл ML в продакшене: фичи, пайплайны, дрейф, мониторинг. 3. Software Architecture: The Hard Parts. Ford, Richards, Sadalage, Dehghani (2021) Про сложные компромиссы в распределённых системах. 4. Team Topologies. Skelton, Pais (2019) Книга про фреймворк организации команд, предназначенный для улучшения производительности и достижения более высокой гибкости в разработке и внедрении продуктов и услуг. 5. Building Event-Driven Microservices. Bellemare (2020) Кто хочет понять асинхронщину вариант отличный. Я пока на 3-ей книге, 5-ую читал. А вы что сейчас изучаете? Что почитываете? Посматриваете? Поделитесь в комментариях, плиз. Ну и если было полезно, то ставим огонецкий 🔥

ТАЙМ-АУТЫ. ЧЬЯ ЗОНА ОТВЕТСВЕННОСТИ? АНАЛИТИКА ИЛИ РАЗРАБА? Очень часто я встречаю ситуацию на ревью, да и просто при обсуждениях, когда пропускают тему таймаутов. Чаще всего их втыкают везде по умолчанию и тянут из конфига. Но бывают ситуации, когда просто отдать на откуп разрабу эту тему - не самая лучшая затея, потому что это может стоить вам кучи времени. Был у нас как-то кейс на мобильном проекте: UI обращался в мидл сервис, который в свою очередь тянул данные из внешнего бэка, а у них что БД, что бизнес-логика на хранимых процедурах. Понимаете, чем пахнет? Правильно! Лютыми тайм-аутами, так как при возрастании нагрузки, мы начинали ловить лютые лаги и UI начал отваливаться, потому что тайм-ауты на фронте были стандартные. И все бы ничего, но UI это не веб приложение, где можно накинуть быстро изменение, это мобилка, а все же знают, что чтобы релизнуть мобилку надо пройти 100 кругов ада и все равно где-то старые версии будут использоваться? Так вот. Когда появились таймауты разумеется кто негодяй? Правильно, наша команда. И поэтому нас удостоили чести решать этот вопрос 😂 В итоге, как в любой сказке есть 3 пути: ✔️ пойти по-длинному, но безопасному, ✔️ по-короткому, ✔️ по-среднему, но с танцами и потерей коней по дороге. Идеальный и длинный путь - это пойти и попросить команду доработать запросы, но они не быстрые - бэклог забит, на полгода вперед, и в целом функциональность-то работает, поэтому вы и решайте. Поэтому мы с командой решили идти по пути не очень правильному, но 100% рабочему. Подкручивали таймауты на разных уровнях цепочки, чтобы поведение было предсказуемым. Почему на разном уровне? Потому что на просто накинуть чуть времени на UI не достаточно, так как это не решит проблему отвала при доп нагрузке, а значит надо подкручивать и делать доп инструменты по пути: UI, Балансир, Твой сервис, внешний сервис. И только так можно получить какой-то качественный и устойчивый вариант. Так что после таких кейсов, даже если не надо продумывать таймауты, я все равно обращаю на них внимание, чтобы не отдавать это на откуп разработчику и значениям по умолчанию. ➖➖➖ На что важно обратить внимание в постановках? ✔️ Сколько ждать ответ В идеале не больше 3-5 секунд. Все что больше - уже не очень и надо продумывать другие механизмы, например, кэширование, перевод этапа в асинхрон или что-то еще выдумывать. Возможно чинить на других этапах. ✔️ Ретраить или нет Если операция отваливается по таймауту, то можно сделать повторный вызов, если операция идемпотентная, но если нет, то нужно продумывать работу с дублями. Обычно про это забывают. ➖➖➖ Так что, если вы думали, что таймауты - это мелочь и можно отдать это разрабам, то увы, нам с вами лучше поучаствовать в этом вопросе.

Time To Market за один день Был сегодня на встрече и там прозвучала мысль, о том, что надо стремится делать Delivery так, чтобы фичи появлялись за 1 день. Звучит здорово, однако у меня всегда в этом желании возникакет только один вопрос: а насколько это жизнеспособно внутри крупной компании, а не на слайде? Вообще с появлением ИИ-движухи эта идея может взлететь, однако это сейчас разбивается о то, что есть 2 лагеря сотрудников. Одни говорят - погнали внедрять ЫЫ, токины палить, а другие - считают, что этот ИИ дичь лютая. Только продуктивность роняет и ничего не дает. ➖➖➖ А я, сейчас в такой позиции, где-то между. С одной стороны, инструменты сейчас реально огонь, последние модели позволяют лепить такие прототипы, что даже школьник соберет что-то рабочее и будет счастлив. С другой - в энтерпрайзе все это вязнет. Архитектура слишком вязкая и громоздкая со своими нюансами + есть регуляторка + своя внутренняя кухня в компании. И ребятки, которые играют в политику на локальном уровене. Короче цирк с конями 😂 Поэтому вся эта красота точно за один день не взлетает. Но можно ли реально ужать time-to-market до дня? Наверное, да, я такие компании даже видел. Недавно слушал подкаст про одну компанию из Штатов - Manifest. Они автоматизируют работу юристов и выкупают самых дорогих инженеров по всему миру, не только в Долине. И, если верить владельцу, от запроса клиента до реализации у них уходит 2-6 часов на внедрение каких-то быстрых фичей. Но это компания стартап, поэтому там обвесов в виде легаси еще нет. Но для СА важно критически научиться работать с этими инструментами. Мне в проекте некоторые моменты ИИ-шка точно облегчает. Ну и ниже, слайдик из выступления на data day про агентов, который показывает, что в финтехе не везде надо делать TTM 1 день и доверятся агентам и ИИ в целом. Было полезно - ставь 🔥

Я как-то на конференции DUMP разговорился с Егором Марюшко - он рассказал, что решил запустить институт системного анализа и собирает под него базу знаний. Вот сегодня он написал, что у института появилась платформа с моделью знаний, умений и навыков. Платформа новая, и пока там не сильно много инфы, но по направлению СА уже есть скелет из 300+ разделов: от BPMN и трассировки требований до Swagger, SQL и event-driven архитектуры. Опубликованных вопросов пока немного, база только растет, но сама карта навыков уже стоящая, по ней видно, что вообще должен знать и уметь системный аналитик. Так что если вы хотите понять, какие навыки нужны и в целом поучаствовать в наполнении базы, то вот ссылочка

Вчера был на Data Day 2026, вся конфа посвещена самой важной теме к этому часу - кто и как юзает ИИ. Там выступали ребята из финтеха, ритейла и не других сфер. Короче было интересно. Но... Я поймал себя на мысли, что ребята рассказывают какие-то кейсы про ИИ очень бодро и задорно, сыпят кучей терминов, рассказывают как круто все работает. Но я или слабо понимаю о чем они, потому что много терминологии с которой я не работал и это чисто их локальная кухня или все презентуется так абстрактно, что хочется сказать: "так *лять... собрались и дали конкретный кейс по шагам, что делать" А то кейс прикольный, а как мне его применить непонятно. И таких докладов 90%. Очень интересные, а забрать практически нечего. Ладно, кое какие мысли я оттуда взял и принес вам 😉 И вот они: ✔️ Компании, которые поувольняли спецов заменив их на ИИ в 55% случаев жалеют об этом и возвращают квалифицированные кадры. ✔️ Агенты, которые сейчас есть, отлично покрывают рутинную работу среднего сотрудника, помогают ему обучиться за пару месяцев вместо пары лет, но не покрывают корнер кейсы. И в итоге у нас среднячки, которые не могут перформить. ✔️ Не во все дырки надо пихать ИИ. И в большинстве кейсах нужен человек хотя бы, как смотрящий за тем, что выдает ЫЫ-шка. Так что ребят, качаемся в агентности, но не забываем про БАЗовые навыки, чтобы понимать, где у ИИ правда, а где она словила галюнов 😅

Как выбрать метод сбора требований, когда все запутано? Увидел недавно одно интересное обсуждение. Пишет аналитик:

Я знаю кучу методик по сбору требований: воркшопы, карты стейкхолдеров, модели процессов, root cause, матрицы решений. Но есть проблемка, не знаю когда какой использовать.

Не знаю, как вас, но на старте карьеры такое часто стреляет у аналитиков, потому что когда ты только изучаешь тему, навыки и познал сокральные знания, то инфы много, а практических навыков нет, так как не встречается так много всего на одном проекте. Так как же понять, когда какой способ сбора требований использовать? Все просто, надо понять, что у тебя сейчас за ситуация и чего не хватает, чтобы подвинуться дальше. И понять это можно только исходя из кейсов, которые мы можем получить на практике, или прочитать, или получить опыт из блогов, книг, статей. Вот давайте приведу парочку кейсов, чтобы было понятно, что делать и какой инструмент применять. ➖➖➖ Кейс 1️⃣ Представьте, что у вас 2 стекхолдера и каждый описывает процесс по-своему и возникает спор между ними, и тебя как аналитика затягивают. Какой инструмент можно применить? Поиск причинно следственных связей. Берем и рисуем AS-IS схему. Дальше совместно со стекхолдерами проходимся по схеме и на каждом этапе верифицируем всех стеков и находим противоречия и пересечения. ➖➖➖ Кейс 2️⃣ Размытый скоуп и нечеткие границы. Вам дали задачу, которая ну очень большая. Например, спроектировать функциональность торговли на криптобирже. Для вас, как аналитика, такая постановка может означать все, что угодно. Поэтому надо сужать скоуп и приводить все к какому-то более четкому знаменателю. Поэтому тут нужно будет делать несколько итераций. И начать с такого инструмента, как assumption mapping (карта гепотиз), то есть накидываете, что имелось ввиду, а уже потом обсуждаете со всеми, что можно реализовать из этого, что вообще не туда. ➖➖➖ Кейс 3️⃣ Несколько вариантов решения. Вам дали задачу спроектировать отображение торговых идей на бирже. Вы видите несколько вариантов решения, но не понимаете, а какой из них выбрать. Вот для такого кейса отлично подходит матрица принятия решений (decision matrix). Просто разбираете на плюсы/минусы, ограничения, возможности каждый из вариантов и потом груммите и обсуждаете с командой и стеками. ➖➖➖ Короче, если вы понимаете, что у вас есть набор инструментов, который вы не знаете куда применить и сомневаетесь в его использовании, то: во-первых, попробуйте поискать кейсы, где такое применимо; во-вторых, попробуйте к какой-то конкретной задаче, которая у вас есть сейчас, применить любой, кажущийся правильным. Поверьте, на собственной практике, вам через пару тройку задач станет понятно, где отлично работает research, где интервью, где матрицы или живое общение.

ОГНЕННОЕ ВИДЕО ПРО ТО, КАК РАБОТАЮТ ЯЗЫКОВЫЕ МОДЕЛИ Я думаю, что только ленивый не изучает сейчас ИИ, и я уверен, что среди вас есть те, кто хочет хочет понять, как это все работает. Потому что не понимая БАЗЫ, трудно делать какие-то более глобальные штуки правильно. Так вот, наткнулся на очень крутое видео с объяснением, как устроены большие языковые модели (LLM).  И мне очень зашло, так как моменты, которые были просто по умолчанию из разряда "просто так все делают и так говорят делать" - я понял зачем их применять. Например, что такое температура, как подбираются веса, зачем надо обязательно добавлять ролевую модель и как указание роли влияет на выбор и предсказание.  Короче, мне зашло и думаю вам тоже залетит.  Так что рекомендасьен 🔥 ➡️ ССЫЛКА НА ВИДЕО ➡️ ССЫЛКА НА ВИДЕО ➡️ ССЫЛКА НА ВИДЕО Ставьте 🔥, если тема ИИ заходит

КАК ЗАГРУЖАТЬ ФАЙЛЫ В API? Представьте, что вам надо сделать загрузку документов, например, сканы паспорта. Как правильно это сделать? Первое, что может прийти в голову - это воткнуть в JSON в формате base64, но так делать не надо! Потому что кодировка может очень сильно раздуть файл. - если это маленькая картиночка, то это еще терпимо, - если это pdf со сканами всех страниц документа, то это будет полная жесть. И ладно, что нам это надо отправить, но нам еще стороне API такое добро нужно обработать, а обработка такой дикой JSON-ины заставит сервер не то что задуматься, а дико затупить и подвиснуть. И есть риск, что результат будет плачевным 🥲 Поэтому давайте обсудим, как лучше грузить файлы? ➖➖➖ 1️⃣ Content-Type: Multipart/form-data. Отправка файла через ваш бэкенд. Это классический способ. Клиент отправляет файл на сервер, как multipart, вместе с метаданными в виде байтиков, а бэк принимает байты и кладёт их в хранилище. Пример,

POST /documents Content-Type: multipart/form-data (file=скан.pdf, type=passport)

Этот способ хорошо использовать, когда файл имеет небольшой размер, например, аватарка или один документ. Ну и тогда, когда не хочется заморачиваться, так как в этом случае у нас один запрос и валидация проходит прям на серваке, то есть никакой доп логики и усложнений. Однако, этот способ очень плох, когда у вас файлы много весят или их очень много, например, вы хотите передать не один документ, а пачку док разом. При использовании этого варианта в какой-то момент бэк может начать захлебываться и вальнется по таймауту, поэтому для этого используем способ 2. 2️⃣ Presigned URL При этом варианте мы отправляем файлы напрямую в хранилище, то есть API-шки у нас тут участвуют только в роли указателя, что сделать с файлом, но не передают его. При этом сервер выдает просто доступ к хранилищу и никак не взаимодействует с самим файлом. Как это выглядит: 1. Клиент дергает API и говорит: хочу загрузить файл.

POST /uploads → { "uploadUrl": "https://storage/...&sig=...", "key": "docs/abc123", "expiresIn": 600 }

2. Клиент грузит файл НАПРЯМУЮ в хранилище по ссылкам при помощи PUT метода. 3. Клиент дергает бэк, чтобы проверить, что все загрузилось. Если загрузлось, то возвращается ключ, по которому можно работать с документами.

POST /documents { "key": "docs/abc123", "type": "passport" }

Главный жирный плюс такого подхода это то, что тяжёлую работу берёт на себя хранилище и этот подход легко масштабировать. Однако, в использовании такого подхода есть нюанс в сложности его проектирования. Например, надо учитывать типы данных, которые вы готовы отправлять и их максимальный размер. Еще, стоит продумывать проверку таких загруженных файлов на вирусы. И конечно же, надо продумывать правила доступа, кто может писать файлы напрямую, а кто нет. ➖➖➖ Подытожу Первый мы используем когда надо прокидываь низковесные файлы в единственном числе, загружать файлы на диск лучше, когда у вас большой скоуп или вес файлов. Было полезно - ставь 🔥

Я ЖИВОЙ, НЕ ТЕРЯЙТЕ 😄 Так, кажется, я на пару недель выпал из канала и меня даже кто-то успел потерять, но нет, не дождетесь 😎 Я все еще с вами)) А пропал я по хорошей причине. Последние 2 недели с головой ушёл в курс: собрался активный поток, я вёл ребят по этому пути, разбирал их работы, а вопросы сыпались нон-стоп. Признаюсь честно, выдавать такой объем вдумчивой обратной связи на каждую работу и каждому ученику - очень энергозатратно и съедает время подчистую. Потому что я убежден, что если делать что-то, то лучшим образом, поэтому на качественные посты сил не было, а выкладывать что-то на отъ*бись не хотелось. И вот поток уже почти завершен, я немного выдыхаю и возвращаюсь. Тем более, что накопилось много интересных тем, которые стоит разобрать. И первая тема, которой хочу с вами подробнее обсудить - это как правильно формировать ошибки. Очень часто на эту тему забивают и зря, потому что в зависимости от того, как вы проектируете негативный ответ - зависит очень много. Если статья полезна - ставьте 🔥 ➡️ ссылка на статью ➡️ ссылка на статью ➡️ ссылка на статью

Думаю, что уже только ленивый не посмотрел фильм про Platа 😉 Так вот, тут попался пост РО, который ищет к себе в команду джуников. Вдруг вам актуально ➡️ ссылка на пост

АЛЛО ЭТО МОШЕННИКИ? НЕТ, ЭТО HR ИЗ КОМПАНИИ N Последнее время заметил, что HRы и рекрутеры стали звонить просто на телефон, а не пишут в чат или на почту. Первый раз, когда меня так набрали, я признаюсь честно, сильно удивился, потому что с незнакомых номеров часто звонят или мошенники, или реклама. И вот я задумался, почему они вдруг решили звонить? Первая мысль, что они решили проверить не ИИ ли ты случаем. Думаю вы видели приколы, когда ИИ HR разговаривает с ИИ кандидатом 😄 Вторая мысль, возможно это из-за того, что не у всех работает телега, а ИТишники это последние люди, которые пойдут в ВК или MAX. Ну и третья, походу рынок начинает оживать и люди хотят быстрее всех закрыть вакансию. Например, мне вчера позвонила девушка, мы с ней пообщались и через 10 минут от другого рекрутера в чат прилетела та же вакансия. Разумеется я буду общаться с первым человеком. ➖➖➖ Ну и да, это все круто, но как на это реагировать? Первое и главное: не теряйтесь. Если неудобно говорить, то сами переведите на мессенджер, или попросите перезвонить в конкретное время. Мне ни разу не отказывали перейти в тележку. И держите наготове мини-рассказ на 60 секунд про себя, что ищете и на каких условиях.

А если нужно выбрать несколько статусов, то их либо можно перечислить в одном параметре: status=PROCESSING,SHIPPED, либо повторить параметр: status=PROCESSING&status=SHIPPED. Оба варианта рабочие, главное, зафиксировать в спеке, как именно надо передавать. ➖➖➖ И финалочка :) Если мы посмотрим наш начальный запрос: GET /orders?min_total_price=10000&status=обработка&sortByDate=desc&sortByPrice=asc И на тот, который получился по итогу: GET /orders?priceFrom=5000&priceTo=10000&status=PROCESSING&dateFrom=2026-06-01&dateTo=2026-06-30&sort=createdAt,desc то, на первый взгляд, он значительно удлинился, но при этом стал более гибким и универсальным и подходит под различные кейсы. И главное, спасает от ненужных доработок 😉 Если эта инфа была вам полезна - ставьте ОГНИЩЕ!

КАК ПРАВИЛЬНО ПРОЕКТИРОВАТЬ QUERY-ПАРАМЕТРЫ: ФИЛЬТРЫ И СОРТИРОВКА Представьте, что вы проектируете админку, где по списку заказов надо поставить фильтры и сортировку. Отфильтровать по цене и статусу, ограничить период, да ещё и отсортировать. Кажется, легко на первый взгляд. Накидал параметров в URL и готово, но именно тут есть загвоздочка, что на скорую руку, может получится не очень гибкое решение. Например, такое: GET /orders?min_total_price=10000&status=обработка&sortByDate=desc&sortByPrice=asc Вроде все ок, на первый взгляд, правда? Но все же я бы докрутил. Как? Давайте разбираться. ➖➖➖ 1️⃣ ДИАПАЗОН значений Возьмем дату и цену. На первый взгляд, хочется запихнуть эти значения в один параметр, но на самом деле это всегда пара, а не одно поле. Возьмем пример. Мы хотим вернуть список заказов, которые были дешевле 10 000. Ну логично же, что min_total_price вообще огонь вариант? Нет, не огонь, потому что, во-первых, слово min само по себе говорит про нижнюю границу, но если нам понадобится фильтр по верхней границе, то с этим значением уже не сработает. во-вторых, заказчики люди переменчивые и там, где говорят, что хотят сейчас фильтровать только по минимальному значению, то завтра захотят не только по верхнему значению, но еще и в промежутке, например, "от 5 000 до 10 000", и хочешь-не хочешь, нам в любом случае придется вводить второй параметр. Поэтому лучше сразу выделить 2 параметра парой: ✖️ min_total_price=10000 ✔️ priceFrom=5000&priceTo=10000 В этом примере у нас и имя однозначное и гибкость и уберегли себя от уведомления старых потребителей о том, что что-то поменяли. Кто-то скажет:

Ну это же почти то же самое!

Не совсем, давайте накину деталей Пара закрывает все случаи: ✔️ нужна только верхняя граница - отправляем priceTo ✔️ нужна нижняя - отправляем priceFrom ✔️ нужен диапазон, оба сразу ➖➖➖ 2️⃣ ОДНО СОГЛАШЕНИЕ по именам на все параметры Когда у вас появляется большое количество параметров, то можно легко начать делать имена на параметры, которые уже есть. Например, в одном месте - min_price, в другом - priceTo, в одном месте - date_from, в другом - createdBefore. Каждый лепит свой нейминг. А потом у вас на проекте зоопарк похожих фильтров, а какой из них эталонный не понятно. Поэтому, если вам надо спроектировать стиль для ваших query параметров, то подсмотрите у коллег, как лучше. Можно на текущем проекте, если уже что-то есть, а можно подсмотреть у коллег во вне, через devtools, если проектируешь что-то с нуля. ➖➖➖ 3️⃣ СОРТИРОВКА - ЭТО ОДНИ ПАРАМЕТР, а не несколько Люди, которые проектируют редко это добро, часто хотят разбить сортировку на максимальное количество параметров. Есть у тебя табличка визуальная на 10 колонок. Вот втыкаем 10 разных, например, sortByDate, sortByPrice. И в целом, если у нас сортировок не сильно много, то так спроектировать ок, но если надо сортировать сразу по двум и более значениям, сразу, то тут надо продумывать, что главнее. Поэтому проще сортировку держать в одном параметре, где есть и поле, и направление: ✖️ sortByDate=desc&sortByPrice=asc ✔️ sort=createdAt,desc&sort=price,asc Выглядит вроде похоже, но в первом случае параметры независимы, а во втором - у нас порядок задает приоритеты. Сначала по дате, при равенстве по цене и при этом, так как параметр у нас один sort, то вы сможете докручивать логику и расширять сортировку новыми значениями, если потребуется. ➖➖➖ 4️⃣ ФИЛЬТРАЦИЯ ПО КОДАМ, а не по подписям Вернёмся к нашему параметру status=обработка. Иногда, люди любят воткнуть кирилицу и сортировать по ней, но это просто текст с экрана. Это ненадежно, так как описание сегодня одно, а завтра другое, поэтому для статусов надо задавать ENUM значения, которые будут всегда стандартные и не будут зависеть от локализации. Поэтому в значениях фильтра передаем так: ✖️ status=обработка ✔️ status=PROCESSING

КОНТАКТЫ В API: КАК ПОМЕТИТЬ ПРЕДПОЧТИТЕЛЬНЫЙ СПОСОБ СВЯЗИ Представьте, что вам надо спроектировать экран с контактами человека и напротив одного из них поставить маркер - связываться сюда. У нас на курсе в уроке про JSON как раз есть такой кейс и многие указывают вариант вида: "preferredContactMethods": ["Телефон", "Почта"] В целом вариант рабочий, и логика понятна, но если присмотреться, в нём есть пара слабых мест, и всплывут они уже на интеграции. Давайте разбираться почему и как сделать лучше. ➖➖➖ Что не так с массивом строк? 1️⃣ "Телефон" и "Почта" - это просто подписи с экрана, а не коды. Если завтра придёт локализация на английский или дизайнер переименует "Почта" в "E-mail", то у нас на фронте может поехать вся логика. 2️⃣ И это главное, предпочтение тут висит в воздухе. Оно говорит "звоните на телефон", но не говорит на какой именно, а если у человека два телефона? Т.е. получается, что маркер есть, а к конкретному значению он не привязан. Поэтому давайте посмотрим, как передавать эти признаки по-другому. Сразу скажу, что вариант зависит от кейса 😉 ➖➖➖ Кейс 1️⃣. Массив контактов с флагом или приоритетом. Самый частый и гибкий случай - вы храните сами значения, и контактов у человека может быть несколько. "contacts": [ { "type": "PHONE", "value": "+79991234567", "isPreferred": true }, { "type": "EMAIL", "value": "ivan@mail.ru", "isPreferred": false } ] Тут у нас есть: type - это код (PHONE, EMAIL, TELEGRAM, и так далее), а не подпись с экрана, поэтому бэк его валидирует, а UI сам решает, как отрисовать. И флаг isPreferred привязан к конкретному контакту, а не к абстрактному телефону. Но может быть так, что предпочтений нужно несколько по порядку? Тогда мы можем поменять флаг например на priority со значениями 1, 2, 3 и получить список отсартированный по важности контктов. Кейс 2️⃣. Ссылка на предпочтительный контакт по id Часто нам нужно выбрать какой-то один конкретный контракт, тогда мы можем реализовать это через ссылку на конкретный идентификтаор или на название параметра, если у нас только по одному значению. "contacts": [ { "id": "c1", "type": "PHONE", "value": "+79991234567" }, { "id": "c2", "type": "PHONE", "value": "+79990000000" } ], "preferredContactId": "c1" Очень похож пример из начала поста, но тут есть нбанс. Вы показываете не просто, что предпочтение телефон, а на какой конкретно телефон надо звонить. Кейс 3️⃣. Отдельное поле с типом, когда предпочтение одно Если по бизнес-правилу предпочтительный канал ровно один и привязка к значению не нужна (например, "пишите в телеграм, а не звоните"), то можно сделать не очень гибкий вариант вида: "preferredContactType": "TELEGRAM" Но если вдруг у нас появятся два и больше предпочтиемых значения, то этот вариант не подойдет. ➖➖➖ Подытожу Жёстко правильного варианта нет, всё зависит от кейса с которым вы работаете. И чтобы было легче сделать выбор можно ответиь на три вопроса: • Контакт один или их несколько? • Нужен один предпочтительный или может быть больше одного? • Есть ли у контактов свои id? Зная ответы на эти вопросы - уже будет проще сформировать контракт 😉