Yet Another Analyst

#ненависть #оффтоп

Глядя на околообразование, все больше прихожу к мысли, что лицензировать нужно не школы и программы, а преподавателей и авторов. Чтобы как с адвокатом или хирургом - нет лицензии, не подходи к людям. И какую-нибудь Клятву Аристотеля придумать.

В душе я немного китаец, поэтому оставлю авторитетный прогноз на год грядущий.

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

Немного перепадет карьерным консультантам, коучам, психотерапевтам - за счет итшечки и около.

Не упусти свой шанс

#API #интеграция

Пока запись вебинара в пути, расскажу про наш курс по проектированию API.

Когда-то он возник как короткий интенсив для начинающих, чтобы научиться базовым вещам: протокол HTTP, каноничное REST API, документирование в OpenAPI (Swagger), тестирование через Postman.

Эта программа давала участникам набор инструментов, которые позволяли успешно работать “с классическим рестом”. Увы, мир несовершенен, и каждый однажды слышит:

— Зачем все эти ваши глаголы?! Я все через POST сделаю - упирается разраб

— Не трогайте статус коды, у нас на них мониторинг завязан! - кричит инфра

— Вот вам драфт макетов, сделайте хорошо - невинно заявляет заказчик


Поэтому мы добавили в программу:

• Проектирование взаимодействий от бизнес-требований до реализации в API

• Альтернативы REST API для сложных пользовательских сценариев

• Асинхронность и HTTP

• Что важно учитывать с точки зрения мониторинга и инфры

Так небольшой интенсив превратился в полноценную подготовку по проектированию боевых API, после которой можно осознанно принимать инженерные решения и защищать их перед коллегами, а не ссылаться на асбстрактное: “Так нам в REST завещали”.

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

Модели потребления сообщений
- Чем топики отличаются от очередей?
- Если кратко - это разные модели потребления

Что такое модели потребления?
Здесь сложнее, т.к. это понятие не слишком популярно в индустрии. В данном контексте модель потребления - это логика работы брокера при передаче сообщения потребителю.

Мой вариант классификации, который подробно разбираю на вебинаре:
• Queue
• Pub-Sub
• Log

Модели определяет два признака:
• Сколько потребителей может прочитать одно сообщение
• Что происходит с сообщением после прочтения

Часто выделяют две модели вместо трех: queue-based, log-based - т.е. объединяют модели Queue и Pub-Sub. Мне эта версия кажется менее наглядной, но тоже хорошо подходит для осмысления вопроса. Можно познакомиться в статье или послушать подкаст о брокерах.

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

#брокеры #интеграция

Прекрасное рядом. До истории с /getClientInfo не дотягивает, но тоже хорошо.

Интересно, а с кэшированием у них нет проблем?

#архитектура

В прошлом году мы запустили кейс-клуб, где регулярно собираемся и предаемся System Design’у здорового человека.

Что делаем:

• Разбираем реальные задачи из жизни, а не Key-Value Storage, URL Shortener и прочую дичь, которую вы никогда не будете пилить в реальной жизни

• Учимся использовать архитектурные паттерны и технологии там, где они действительно уместны

• Увеличиваем техническую насмотренность за счет кейсов из разных индустрий: финтех, ecomm, телеком и другие

Примеры кейсов:
- выпуск и доставка банковской карты
- история покупок и быстрый заказ на маркетплейсе
- программа лояльности в экосистеме

Ближайшая встреча в воскресенье, будет кейс три в одном: A/B-тесты, feature toggling, таргетированная реклама - все в одной архитектуре.

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

Don’t try to quit REST

Завтра вещаю на вебинаре, чтобы в очередной (третий) раз окончательно закрыть тему REST API. Наверное, это персональное проклятье. Вспомним, как появилась концепция, под какие задачи, и почему ее актуальность в 2025 стремится к нулю.

Приходите похоливарить, рега тут

#интеграция

Ничего мы вам не гарантировали

Меня умиляют истории, как кто-то в очередной раз сделал надежную exactly once доставку с помощью XXX и YYY. Обычно это либо оголтелый маркетинг, либо техническая наивность.

Существует ровно два гендера гарантии доставки:
• at most once
• at least once

Все, третьего не дано.
Вы не реализуете exactly once доставку, потому что это фундаментальное ограничение мира, такое же как вечный двигатель или перемещение материи свыше скорости света. За доказательством рекомендую обратиться к задаче двух генералов - она во многих задачах IT проявляется, пусть и неявно.

Тогда что такое exactly once?
Это гарантия обработки. Если говорить просто, то это at least once доставка, где каждое взаимодействие обвешано ретраями и идемпотентностью. Единственный способ обработать сообщение строго один раз - это любой ценой донести его до получателя, а потом уже отсеять дубликаты.

Потому нам нужны transactional in/out-boxы - чтобы корректно донести сообщение до брокера, и строго один раз обработать его на консьюмере. И все это поверх at least once гарантии доставки.

Про аутбоксы можно почитать тут.

А здесь хардкорно про устройство брокеров, и как устроена запись-чтение сообщений.

#интеграция #архитектура

Все, хватит салатов, просыпаемся.

Детальный разбор реализации Transactional Outbox, когда у тебя постгря с кафкой. Варианты реализации, проблемы, инструменты - просто и понятно. Отдельно можно скачать презу.

Здесь можно подробнее почитать, зачем нужны все эти аутбоксы, и что это такое.

С Рождеством и добро пожаловать в 2025!

Терпения и спокойствия всем нам 🎇

#оффтоп #манагерское

Внезапно осознал, что в около-образовании уже 6 лет. Началось все с обучения для аналитиков внутри компании, потом вел и делал курс по интеграциям в com-practice, теперь занимаюсь своей школой. А появилась она довольно забавно.

В тот момент я около полугода работал в компании, где у нас совсем не задались рабочие отношения с руководителем. Когда атмосфера стала откровенно взрывоопасной, понял что лучше уже не будет - решил уйти в закат и отдохнуть 2-3 месяца. С руководителем договорились быстро, ибо желание было обоюдным.

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

- Не нуачо? Раз народ сказал, надо идти делать

Так появился ArchWays. Потом решили объединиться с Аней, и он трансформировался в NextWay. Мораль я не придумал, но если вы узнали себя в это истории - спасибо за веру и чудесную возможность))

Ну что, пора вылезать из салатов?

В прошлом году мы запустили Клуб Проектирования NextWay, чтобы вместе качать архитектурные скиллы 🎓💪
Никита Ерилин, эксперт клуба, поделился полезным-архитектурным, чтобы почитать под мандаринки.

System Design Primer
Хорошая краткая выжимка по многим моментам и понятиям, используемым в системном дизайне. Сфокусировано на собеседованиях, но в качестве знакомства с основами или справочника подходит неплохо. Единственное - не заучивайте примеры, а постарайтесь докопаться до мотивации того, почему они предлагают сделать именно так.

Design It! From Programmer to Software Architect
Все еще лучшая книга для погружения в архитектурные практики от Майкла Килинга. Она больше заточена под разработчиков, поэтому там довольно много разжевываний вещей, которые могут показаться банальными, вроде: "Не придумывай требование, спроси ртом у заказчика" - но там есть много разных методик по работе со стейкхолдерами. В рамках собеса такое вред ли пригодится, но в работе поможет.

Книга с кабанчиком
Бессмертная классика от Мартина Клепмана. Может показаться сложной из-за обилия технических подробностей, но ее структура позволяет провернуть один лайфхак: как только вы чувствуете, что глава становится слишком сложной, и вы не понимаете технических деталей – переходите к следующей, они все идут по принципу "от простого к сложному”. Даже если вы по верхам пробежите все главы, получите много пищи для дальнейших размышлений.

Microservices.io
Большая подборка микросервисных паттернов Криса Ричардсона. Самый полезный раздел, на мой взгляд: "Transactional messaging".

@nextway_news

#книжное #оффтоп

А в 2023 открытием года стала Гарри Поттер и методы рационального мышления от Элиезера Юдковского. Точнее приоткрытием, т.к. некоторые главы читал раньше, но сначала не зацепило.

Автор предлагает альтернативную историю Гарри Поттера, в которой он не был дебилом с самого детства овладел логикой и рациональным мышлением. Фактически, это сборник логических ошибок, когнитивных искажений, парадоксов, и прочих несовершенств работы нашего мозга. И завернуто это все в реально интересный сюжет. Мне было куда интереснее, чем смотреть оригинальный фильм.

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

Книга свободно доступна в онлайне, но есть и печатные издания, если больше нравится.

#книжное #оффтоп

Биология добра и зла Роберта Сапольски стала для меня открытием 2024 года. Безумно интересно и доступно о том, как устроен человек, что определяет его поведение.

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

Например, внутри можно найти:

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

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

И практически полезного: чаще задумываешься, чем обусловлено свое или чужое поведение.

Из побочных эффектов: сложнее воспринимать всерьез часть идей психоанализа и медитаций.

За каникулы прочитать вряд ли получится, но оно того стоит. Если совсем лень, то у Сапольски много лекций и интервью в сети - там тоже много интересного.

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

Channel name was changed to «Yet Another Analyst»

#интеграция
Вот такая шикарная инфографика от Юрия Куприянова. Не со всем согласен, мои комменты тут.

Полезая штука, но как всегда буду душнить: пожалуйста, никогда (прописью: никогда) не принимайте боевые решения на основе таких таблиц / критериев / алогритмов - они никогда не будут отражать всех нюансов. А какие нюансы важны в вашем контексте, знаете только вы.

Тогда в чем польза? Систематизировать знания, сверить картину мира, если что-то кажется странным - погуглить и узнать что-то новое.

#манагерское

Собирайте грибы, а не требования

Если лень читать:
1. Требований не существует
2. Задача аналитика - не собрать требования

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

В этом высказывании есть ряд неявных допущений:

1. Существуют некоторые объективные “требования”
2. Существуют люди, которым “требования” известны - стейкхолдеры
3. С помощью особых техник можно собрать все “требования” у стейкхолдеров
4. Если реализовать “требования”, то мы получим результат, который нужен бизнесу

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

1. Требования - хотелки заказчика
2. Стейкхолдеры - сотрудники заказчика
3. Аналитики записывают хотелки заказчика, мы прикладываем их к договору
4. Реализуем хотелки, получаем деньги - профит

И то при особо злостном следовании “требованиям” заказчик может отказаться принимать работу или отправить нас в блеклист после сдачи проекта.

Когда мы пилим продукт, в роли “требований” могут выступать разве что ограничения регулятора и законы физики. Никаких “правильных требований”, которые можно "собрать", здесь нет. Как и нет людей, которые точно знают, что делать - мы оперируем гипотезами, исследованиями, данными разной степени достоверности.

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

А если без аналитика никак, то почему? Хотим работать по принципу: “Что нам сказали, то и делаем”?

#интеграция #архитектура

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

• Надежность взаимодействий: время отклика, таймайуты, хелсчеки - и как это считать реальными числами

• Проблемы взаимодействий поверх брокеров

• Согласованность и управление транзакциями

Рекомендуется к просмотру перед изучением статьи о способах обеспечения отказоустойчивости при синхронных взаимодействиях.

#оффтоп
Сисдизайн секция здорового человека:

- Вам нужно спроектировать Key-Value хранилище
- Зачем?
- ...
- Спасибо, я не перезвоню

#оффтоп #манагерское

Как интересно работает мозг. Существует 100500 методик, как эффективно давать фидбек. Многие сходятся на том, что в него обязательно нужно включать позитивные тезисы.

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

Периодически слышу конструкции вида: “ты классно сделал ХХХ”, “здорово, что ты YYY”, “в целом все хорошо” - а дальше следует содержательная часть что человека не устраивает.

В такие моменты слушаю и думаю: “Давай уже пропустим эту херню и перейдем к делу. Захочу узнать о хорошем - спрошу прямо”. А человек же старается как лучше.

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

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

И дай мне мудрость отличить одних от других

Тут всех приглашают поучаствовать в архитектурной кате. Онлайн, бесплатно.

Отличный вариант добрать опыта проектирования - зачем упускать?

📅 5 декабря, четверг, 19:00 мск

#оффтоп

Пока искал фотку с конфы...

Други, кто-нибудь обитает сейчас на Пхукете? Давайте соберемся на чаек.

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

Потому что выступление - это не только ценный самопиар и почесывание ЧСВ, но и мощный инструмент развития софтов (внезапно) и хардов (дада), которые потом можно и нужно применять в реальной работе. А для лидов еще способ прокачать HR-бренд, упростить хантинг, принести интереса-мотивации в команду.

Даже постил когда-то мини подборку, как и зачем выступать.

В общем, заходите.

Недостающие звенья кэширования

Статья, которую можно использовать для первого знакомства с темой.

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

Дополнил исходный пост, забирайте его полностью.

#архитектура #systemdesign

#шокконтент

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

Что. Здесь. Происходит?

Нашел перевод статьи на русский. Больше нет причин, чтобы откладывать

Yet Another Analyst pinned «Вводная (по мнению автора) статья о способах балансировки трафика. Хотя большинству смертных никогда не придется заглядывать глубже, если это не админы, сетевые архитекторы и т.п. Многобукв для тех, кто хочет окунуться в тему: - Балансировка, и зачем это…»

Integrations must go on

Давно хотел сделать программу по продвинутым интеграциям, где можно покопаться в технических деталях и поговорить о связи с архитектурой. Пока базовый курс в творческом отпуске, го на продолжение - Интеграции Систем. Next Level

Что внутри:

◽️Инфра, сети, протоколы, мониторинг

◽️Надежность и производительность: кеширование, балансировка, работа в режиме сбоев

◽️Брокеры сообщений в теории и практике: Kafka и RabbitMQ

◽️Интеграции и распределенные системы. CAP и PACELC теоремы.

◽️Управление бизнес транзакциями. Оркестрация и хореография

Курс для тех, кому интересно вот это все. И кто имеет уверенный опыт проектирования взаимодействий поверх HTTP.

📆 16 ноября - 14 декабря по четвергам и субботам

🔗 Рега тут

Утро начинается с кэша

Годная лекция о кэшировании от основ до сложностей реализации. Что интересного:

• Стратегии кеширования
• Считаем, когда кэш вреден
• Вытеснение данных из кэша
• Инвалидация кэша

Перед просмотром лекции советую прочитать вводную статью о кэшировании, так будет проще.

Небольшая статья о кэшировании, интересный разбор взаимодействия кэша с источником.

Где можно встретит кэши? Правильно, везде. Статья для расширения сознания.

#архитектура

#оффтоп #манагерское

Как же интересно работает мозг. Встретил тезис в духе:

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

Поток мыслей:

- Надо срочно ответить, в инете кто-то неправ!

- Как же хорошо, что большинство близких коллег не из этих

- Надеюсь, больше никогда не попаду в такой коллектив

- Интересно, как у людей формируется такая позиция?

- Подозреваю, ее формируют процессы, коммуникации и культура в компании

- Интересно, на сколько часто в моих командах складывалось такое отношение? Как избежать это или изменить?

Хотел набросить, ушел рефлексировать. Жизнь боль.

Пытаюсь понять, как у людей (команды) в рамках одной активности одновременно уживаются понятия «заказчик» и «продукт».

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

Как правильно выбрать хранилище под задачу

Словом идемпотентность уже никого не напугаешь. Все разобрались, что это и почему важно. А важно для ретраев. А эффективная организация ретраев - тот еще адок.

Тот самый Вася из Яндекса разбирает проблемы, которые могут вызывать ретраи при падениях системы, показывает варианты решения, сравнивает на графиках и циферках. Из интересного:

◽️Exponential backoff - чтобы адекватно настроить время между ретраями

◽️Сircuit breaker и adaptive retry - чтобы не положить сервис ретраями

◽️Deadline propagation - думал, что это фишка gRPC, но нет

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

#интеграция #архитектура

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

Многобукв для тех, кто хочет окунуться в тему:

- Балансировка, и зачем это нужно
- Функции балансеров
- L7 / L4 балансеры и зоны применения
- Типовые топологии и способы масштабирования

P.S. Нашел перевод на русский

Если хочется понять, зачем вообще что-то балансировать, то есть наглядный кейс.

#интеграция #архитектура #сети

Не могу не репостнуть

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

- Как закладывать надежность на старте проектирования

- Где искать надежность при взаимодействии сервисов

- Latency based Congestion Control - не буду это переводить

- Архитектурная ката для участников

Если соберетесь подключиться, то орги скидос подогнали - techlead_crew_7_BsrEcL

Прошлогодний рассказ, как Сбер делает копайлота для юристов. Никакой магии, только эксперименты с RAG и пайплайнами + формирование базы знаний. Характерно, что для формирования базы знаний понадобилась ручная разметка базы знаний силами 30 юристов - обыватель без экспертизы в домене не подойдет.

Вот сам продукт - пока предлагают анализ загруженных документов и диалог с базой знаний, но роадмап интересный. Правда доступ только по запросу.

Хозяйке на заметку:
- Про RAG совсем на бизнесовом
- Совсем кратко про построение боевых LLM-приложений

AI-продукты для разрабов пошли дальше всяких копайлотов. Replit предлагают вроде уже стандартную связку IDE + репа + AI-ассистент. А еще их агент по текстовому описанию пишет код, поднимает БД и разворачивает приложение. Все под ключ для ленивого разраба.

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

Ссыль: https://replit.com

Статья (нужен vpn) о ретраях и защите от дублирования транзакций из недр Airbnb. В том числе разбирают проблемы реализации идемпотентности, и почему это не просто ключик в запрос положить. В том числе, использование распределенных хранилищ.

Заодно вспомним историю Васи и его борьбе с идемпотентностью в Яндекс.Такси, тоже полезно

Интересный, пусть и поверхностный рассказ, как делают реальные приложения на основе LLM.

https://youtu.be/sNwgkLniGqQ?si=bPOB88QLDL3HH2SS

Знакомый поделился прекрасным. Однажды он обнаружил сервис с методом:

GET /api/getClientInfo?clientId=123

Попробуйте угадать, что он делает:
1. Если клиент не существует
2. Если клиент существует

Дада, вы все правильно поняли:
1. Сервис создает клиента
2. Сервис открывает клиенту счет

Чтобы не творить такую дичь, запрыгивайте на тренинг по проектированию REST API. Разберем, как API может довести потребителя до паралича, и научимся делать его простым и удобным.

А вы какие шедевры встречали в практике?

Кажется, что-то интересное намечается

https://mts-digital.ru/events/details?id=742631

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

Проблемы, варианты решения, акторная модель поверх Кафки. Читать вдумчиво, статья не смузишная.

#архитектура

Только потом нужно объяснить, что из этого никак не следует, что “В реальности сроков не существует”.

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

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

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

https://youtu.be/7oIXcJo56rE

Еще про мышление

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

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

Текстовое описание
Важно описать продукт, систему или процесс так, чтобы читатель осилил текст и правильно понял его. Лаконично, содержательно и доступно для разных ролей. Позволяет проработать детали, выявить корнеры, покрутить разные point of view. Максимально больно в мозг.

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

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

Поэтому холивар “Давайте соберемся обсудим” vs “Мы отправили документ, пришлите вопросы к обсуждению” никогда не закончится. И это нормально. А вот доверять решениям, если использовали только один инструмент - не очень.

#мышление

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

Люблю рассказы в духе: “Возьмите фреймворк XXX для задачи NNN, и будет вам счастье”. Дальше обычно начинается холивар: “Мы попробовали, и получилась какая-то хрень”.

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

Берем RICE
Редко кому удается (вы существуете, кстати?) настроить функцию четырех переменных, дающую на выходе приоритеты, которые можно использовать для развития продукта. Все равно будем двигать с точки зрения “здравого смысла”.

Зато в процессе возникнут вопросы:

• Какие сегменты охватывает фича? Сколько там клиентов? Как они платят?

• Какой профит получим? Это оптимистично или пессимистично?

• Как оценивали? Есть данные, результаты исследований, или это чье-то мнение?

• Есть зависимости от других команд и отделов?

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

Или Use Cases
Как самостоятельный способ передачи требований - ужас ужасный.
Обычная реакция после прочтения: “Кулл стори, бро, но объясни нормально, что сделать нужно?”

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

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

#мышление

Осторожно, реклама

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

Кому будет полезно:

◽️Вы готовитесь к секции System Design на собеседовании. Все чаще их используют не только для разрабов, но и для аналитиков.

◽️Вы развиваетесь в сторону проектирования систем и хотите получить дополнительную практику.

◽️Вам просто интересна архитектура.

Самое ценное по версии участников:

◽️Инструменты масштабирования: балансировка, шардирование, кеширование

◽️Работа с хранилищами: выбор под задачу, RDBMS, NoSQL, DWH, индексы

◽️Спикер и подача материала: понятно, последовательно, незанудно, с юмором

◽️Общение со спикером в режиме открытого микрофона: можно обсудить интересующую тему, получить подробные ответы, разобрать кейсы из практики

История одного успеха
Участник предыдущего потока подался на архитектурный хакатон, вошел в тройку победителей, получил и принял оффер на архитектора в большой известный банк. Вину тренинга в описанных событиях не отрицает.
Конечно, заслуга человека, а не наша, но чем я хуже инфоцыган?

📆 Запрыгивайте, ждем 7-8 сентября в 10:00-14:00 (UTC +3)

🔗 Регаться тут