Event storming — метод, который смещает акцент у событий с технического на организационный и бизнес уровни и помогает создать устойчивую модульную систему. Он нередко используется в контексте моделирования микросервисов. Но как применить его на практике?

При создании системы на микросервисах можно легко получить распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск этого события. О том, как именно этого добиться, рассказал в своем докладе на конференции TechLead Conf 2020 практикующий консультант по архитектуре, процессам разработки и продуктовым практикам Сергей Баранов.

Меня зовут Александр Донсков и я архитектор в компании REG.RU. Сегодня я расскажу о том, что такое Event Storming и что будет, если запереть 10 человек в одной комнате (в том числе виртуальной). Цель статьи не столько в том, чтобы рассказать, как это работает, сколько показать действенность подхода на реальных кейсах.

Сформировать 400 000 документов за рабочий день, одновременно загрузить информацию о тысячах доменов, в 10 раз увеличить скорость обработки данных сайта, обеспечить стабильность интернет-магазина при росте посещаемости — решать такие задачи помогает горизонтальное и вертикальное масштабирование. Разбираем на примере наших проектов и кейса клиента, как повысить производительность веб-проекта. 

Канбан-доски помогают обеспечить гибкость и прозрачность процессов в управлении задачами и проектами. Выбор подходящего инструмента может существенно повлиять на продуктивность команды, упрощая планирования и отслеживание прогресса. В этой статье рассмотрим 9 сервисов для работы с канбан-досками в 2024 году. 

Привет, Хабр! Я Владимир Хрыпун, руководитель центра компетенций по развитию BPM-систем в Первой грузовой компании. Сегодня разберем с вами, чем бизнес-аналитик отличается от системного и почему для проектов цифровой трансформации вам нужно два специалиста. Статья будет полезна менеджерам, продуктам, руководителям проекта. Всем кому надо объяснять, или кто сам хочет разобраться, в чем отличие бизнес и системных аналитиков. 

Часто всем участникам проекта хочется оптимизировать трудозатраты и бюджет. И очень светлая мысль, которая возникает у каждого второго продукта или РП: “А давайте у нас будет один аналитик, который сделает всё!”. У руководителей более высокого уровня, топов и собственников это идея возникает в 9 случаев из 10. В результате сроки сорваны, бюджет превысили в два раза. Почему так происходит и будет происходить разберем ниже. 

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

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

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

Эта статья сборник небольших рекомендаций как работать с Kafka-consumer в Spring основанных на личном опыте.

С развитием веба сайты превратились в сложные приложения, которыми ежедневно пользуются десятки и сотни миллионов людей: почта, облачные хранилища, соцсети, маркетплейсы, стриминговые платформы и т. д. И каждое из них должно работать корректно. Как это сделать? Конечно писать хороший код, а потом и тестировать его. Хотя кто‑то обходится без тестов, тем не менее тестирование — важная часть инженерных практик наравне с мониторингом. Оно помогает нам заблаговременно находить и исправлять баги (или незапланированные фичи) в приложениях. Основная цель тестирования — получить гарантию корректной работы любого ПО .

При этом тестировать современный фронтенд сложно: неуправляемая асинхронность (событийная модель браузера), различие браузеров, тяжелое окружение — это лишь малая часть сложностей. Можно ли все возложить на ручных тестировщиков или исправлять баги после жалоб пользователей? Однозначно нет. В большинстве случаев такой подход в скором времени приведет к оттоку пользователей: не все пишут о багах, просто уходят к конкурентам. Безусловно, ручное тестирование остается важным элементом разработки, но тестировщики не могут держать сотни или тысячи сценариев, которые нужно пройти перед релизом или запуском новой фичи. Так где нам получить гарантии, что ключевые сценарии приложения работают корректно? Автоматическое тестирование.

Всем привет! Меня зовут Миша, работаю фронтэнд‑разработчиком в VK в команде Облака Mail.ru, и я хочу разобрать различные виды тестов, дать их сравнительный анализ и применимость. Сразу скажу, тут не будет практики написания тестов. Потому что это нереально сделать внутри одной статьи, необходимо разобрать: теорию тестирования, классов эквивалентности, различие подходов/методов к тестированию, комбинаторику состояний, правильное использование моков и стабов, понимание чистых функций, знание архитектуры приложения. Поэтому предлагаю сконцентрироваться на видах тестирования и начать с «идеального теста».

Микросервисная архитектура Amediateka была спроектирована более 6 лет назад предыдущей командой разработки. С тех пор добавилось много новых микросервисов, но фундаментальная часть архитектуры осталась прежней. В этом году мы решили внедрить несколько глобальных изменений, одно из которых - API Gateway. Статья расскажет о том, что это такое, какие преимущества дает, как просто и безопасно мигрировать функционирующую систему на API Gateway и сделает обзор готовых решений.

35 вопросов для быстрой оценки качества IT проекта

Привет, дорогие читатели! Хочу поделиться с вами моим чек-листом для проверки состояния IT проекта (преимущественно web, но адаптируется и под другие). Особенно пригодится предпринимателям и управленцам, которые попали на новый проект. После проверки вы получите результат по 100-балльной системе!

О сложных системах простыми словами.

В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.

Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.

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

System Design (сборник на английском языке).

Всем привет, на связи снова Павел Кондратьев из ГК Юзтех. Я продолжаю работать в продуктовой команде по разработке b2b-приложений, и на горизонте прошедшего полугода мы с Заказчиком пришли к вопросам — как измерить производительность нашей команды и выявить слабые места в процессах, чтобы сделать разработку более эффективной?

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

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

Наверняка у многих бизнес-аналитиков есть цель использовать особые артефакты: Impact Map, CJM (Customer Journey Map), USM (User Story Map). Особые, т. к. не так часто они встречаются в бизнес-требованиях, и даже бывалый аналитик может с непривычки растеряться, если не создаёт их каждый день. 

Меня зовут Ирина, я ведущий бизнес-аналитик с более чем пятилетним опытом. Сейчас работаю в X5 Tech в направлении “Цепочки поставок”.

В статье описываю общие принципы построения Impact Map, CJM и USM и вариации их использования не только на примере своих рабочих кейсов, но и на бытовых примерах (буквально на жареной картошке и строительстве дома). Для опытных специалистов разобранные примеры пополнят копилку насмотренности. А для новичков в бизнес-анализе статья будет полезна с точки зрения постижения азов.

Привет! Меня зовут Лёша, во фронтенде уже более семи лет, сейчас работаю фронтенд‑лидом в финтехе. А ещё я ментор на курсе «Мидл фронтенд‑разработчик» в Практикуме.

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

Практики работы с запросами на сервере значительно отличаются от того, к чему привык фронтенд-разработчик. ежедневно разрабатывающий SPA-приложения с клиентским рендерингом. Если не учесть эту разницу при разработке приложения с серверным рендерингом, то можно собрать довольно много граблей. Хочу поделиться опытом и рассказать про три практики, которые использую повседневно, а также о проблемах, предшествующих их появлению. Я буду ссылаться на веб-производительность и рассчитываю что вы уже знакомы с такими метриками как TTFB, LCP и FCP.

Сегодня мы расскажем реальную историю из жизни собственников бизнеса. И хотя ее сюжет напоминает какой‑то голливудский фильм, произойти она может с каждым, кто заявляет: «Да у нас маленькая компания! Кому мы нужны?»

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

Спустя несколько месяцев от заказчика приходит сообщение: нас зашифровали и требуют выкуп. Что делать?

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

Зато открывался документ с инструкциями. Взломщики обещали направить дешифратор за «скромную» сумму в 2000 долларов (на тот момент около 200 000 рублей), переведенную на указанный счет.

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

Привет! На связи лид команды аналитиков Magnus Tech Владислава Никитина.

В заказной разработке каждый проект начинается со сбора бизнес-требований к будущей системе. Это важный этап, ведь именно здесь определяются контуры задач, которыми займутся разработчики. И с ним связан вечный проблемный вопрос: как лучше собрать и зафиксировать эти требования, чтобы оптимизировать разработку?

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

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