Ого, JetBrains выпустили решарпер для VSCode. А значит пользоваться курсором/виндсерфом станет чуточку удобнее!

https://marketplace.visualstudio.com/items?itemName=jetbrains.resharper-code

На днях рефлексировал свой и индустриальный опыт внедрения DDD (BDD, Pair Programming, допишите свое). Выводы не утешительны: почти всегда, а особенно при давлении сроков, легаси, окружения разработчик выберет то что привычно. Как говорил Макс Дорофеев:

наша обезьянка между важным и срочным выбирает... Простое и понятное!

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

И если это так страшно и затратно, то зачем? Не жили богато, нечего начинать.

Что же делать? Искать единомышленников!

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

Если вы обычный гребец разработчик, то все сложнее, но вот что можно попробовать:

1. Рассказывайте! На кухне, в слаке, на внутренних митапах, на больших конференциях. Подкидывайте твиты, видеоролики. Возможно в компании есть единомышленники, но вы друг про друга даже не знаете.
2. Если у вас принято приглашать на внутренние митапы внешних экспертов, то попробуйте сами договориться с кем-то кто продвигает нужную вам повестку. Люди доверяют внешним экспертам.
3. Если в компании используется нужная вам практика, но не в вашей, а в других командах, можно договориться об интро или даже о полноценном погружении внутри той команды или позвать к себе представителя команды.
4. Договоритесь о небольших экспериментах внутри команды, если тиммейты вас поддержат – можно будет регулярно практиковать на живых задачах, набирать уверенности, экспертности, кейсов для демонстрации профита и прочего.

Поделитесь вашим опытом – что сработало, а что оказалось бесполезным?

Продолжаю придерживаться принципа life long learning — считаю, что техническому лидеру важно не останавливаться в развитии и стараться смотреть шире своей текущей зоны ответственности. Поэтому начал новое обучение: на этот раз в «Школе СТО» от Стратоплана. В среду прошла установочная сессия. Впереди пять месяцев интенсивной учебы.

Процесс "поступления" простой, но не бесполезный. Есть вступительное задание (в том числе разбор кейса), есть интервью с тренером. Основная цель – сформировать ожидания и убедиться, что обучение закрывает эти ожидания (хотя бы большую часть).

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

Задача со звездочкой для меня - подсмотреть как организован процесс обучения. Где-то пылится https://dddcourse.ru/ и ждет своего звездного часа.

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

#обучение

Коллеги из Virtual Domain-Driven Design проводят митап с Владом Хононовым.

Тема встречи — модель Balanced Coupling.

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

Balanced Coupling — подход к оценке связности компонентов по трём измерениям:
- Сила интеграции (Integration Strength) — насколько сильно модули “знают” друг о друге.
- Дистанция (Distance) — как далеко друг от друга расположены компоненты в системе.
- Изменчивость (Volatility) — как часто компоненты подвергаются изменениям.

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

Welcome https://www.meetup.com/virtual-domain-driven-design-meetup/events/308115230

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

Забавно, что раскрывают тему с разных, зачастую противоположных, точек зрения: один говорят, работай, солнце еще высоко и тебе воздастся, другой, что это рабство и надо избегать (или бежать, раз вляпался). Обсуждения тоже достаточно поляризованные, кто-то поддерживает одного из спикеров, кто-то наоборот.

Правда в том, что истина где-то рядом посередине (или как здесь принято говорить everything is a trade-off). С одной стороны убегать при первых же трудностях и несовершенствах — признак слабости и непрофессионализма. С другой — надо беречь себя и время и уметь отказываться от минусовых (на дистанции) проектов.

В одном из обсуждений я узнал про такую концепцию как

Кюль-де-сак (от франц. "тупик"). Это ситуация, когда вы трудитесь, трудитесь, трудитесь, и ничего особенно не меняется. Не становится гораздо лучше, как и не становится намного хуже. Все остается как обычно. Подобные занятия называются бесперспективными. Цитата из книги Сета Година Яма.

Мне очень понравилась эта метафора, хотя бы у меня теперь есть нейминг.

Важно понимать следующее.

1. Изнутри кюль-де-сака сложно понять насколько глубока пропасть. Здесь можно взять на вооружение трейдинговые стратегии: установить для себя “тайм-стоп” или “стоп-лосс” — заранее определить, сколько времени/усилий ты готов вложить в проект, прежде чем он начнёт приносить отдачу. Иногда лучший ход — это выйти из позиции, зафиксировать моральный убыток и направить энергию в актив с лучшей потенциальной доходностью.
2. Кюль-де-сак субъективен. Что одному нераспутываемый спагетти-легаси-худший-код-все-тлен, для другого пройденный этап и возможность полирнуть свои навыки внедрения инженерных практик, использования паттерна Strangler Fig и проведения сессий Ивент Шторминга. Выбирай епанчу по плечу!
3. Иногда кюль-де-сак видно на входе. И это отличный способ сделать левел-ап. У меня есть опыт, когда я понимал, что шансы невелики, но очень хотел получить тот опыт. Цели не достиг, но ни о чем не жалею и сейчас поступил бы так же.
4. Не забывайте, что в нашей индустрии непрерывное развитие критически важно. Бывает так, что вроде ничего вокруг не меняется, все тухло, но понимаешь, что сам растешь (об коллег, новый стек, новые подходы, новую проблематику). И это не самый плохой вариант. Желательно в таком случае иметь большую насмотренность, чтобы не перенять все стремные практики как оптимальные и единственно возможные.

Сейчас практически все компании внедрили практику System Design Interview. Наверное большинство так или иначе сталкивались с такими собесами. Если коротко: дают задачу, надо спроектировать примерно как будет выглядеть система для решения задачи.

В сети много мануалов, видео, мок-интервью и прочих материалов. Обычно советы сводятся к следующему:
1. Не бросайтесь сразу что-то делать, осмотритесь, разметьте территорию.
2. Проясните неясные моменты или сами явно проговорите какие-то допущения-предположения. Какая нагрузка, что можете, а что не можете использовать, какие ожидания по консистенси и тп. Что-то неясное можно припарковать (тоже явно сказав об этом).
3. Опишите какие блоки вы видите.

Лучше все это делать с шаренным экраном и фиксировать в miro/unidraw — так и вы не забудете, что о чем-то договорились, и интервьювер лучше поймет куда и как вы идете.

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

1. Event Storming — куда без него. На одном из интервью я провел миништорминг сессию: прям накидал перед собой события которые есть в системе, отметил системы, людей, наметил границы. Собственно этой сессией я закрыл перечисленные выше пункты. не обязательно упарываться, можно начать просто с событий, это уже даст некоторую базу.
2. Домены. Если вы видите, что задача включает в себя generic и supporting домены, то можно сразу сказать, что вы не планируете это проектировать в рамках интервью, вы возьмете готовый продукт или известную реализация и просто заиспользуете. Например вы не будете писать свою аутентификацию. Повторюсь еще раз — важно все проговаривать вслух, возможно вы не заметили какое-то особенное требование и то что вы считали генерик доменом, на самом деле кор. Нормальный интервьювер вам подсветит, что ваше допущение не ок.
3. Все усилия на core. После того как мы отсекли генерик домены, остался кор — его и будем проектировать. Возможно вы заметите два кор домена, контексты и прочее, что вас подтолкнет к созданию распределенной системы (ака микросервисы).

Где и когда использовать:
Если в компании практикуют DDD (или хотя бы в описании вакансии были эти буковки), то такой подход может вам набрать дополнительные плюсики. Будет понятно, что вы написали про Domain-Driven design в резюме не просто так, а регулярно используете в реальной жизни.

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

А какой у вас опыт использования DDD на собеседованиях? Спрашиваете ли вы сами как интервьюеры? Как относитесь к кандидатам с DDD бекграундом?

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

Как я уже писал, я прохожу обучение в Стратоплане, недавно прошел первый модуль, (на носу второй). Первый модуль был посвящен аудиту и компетенциям СТО. В целом по аудиту много нового не узнал, а вот необходимыми компетенциями СТО был приятно удивлен.

Сразу оговорюсь, что для разных компаний, разных этапов, разных конфигураций могут требоваться разные компетенции. Но если брать СТО средней компании, то ребята топят за сильную техническую составляющую. ТО есть важно нее просто знать какие-то вещи, но и уметь их готовить. И среди прочего в список необходимого попал Domain-driven design.

Так что ждем светлого будущего, когда СТО будут всячески провоцировать внедрение и использование DDD в компаниях.

Как ваш СТО относится к DDD и прочему technical excellence? Топит за такое или наоборот считает баловством?

#обучение

Очередной модуль Стратоплана идеально лег по таймингу на инфоповод от Аэрофлота: обсуждали ИБ. Без особой глубины и в целом с этой областью я знаком (даже как-то вел инфобез в региональном вузе 🥸). Синтезируя стратоплановские знания и мои хотел бы выделить заблуждения и важные моменты:

Частые заблуждения (например их можно встретить в постах людей, никак несвязанных с ИБ)

1. Взлом — значит безопасники недоработали/неквалифицированные!

Конечно же это не так в общем случае. Безопасность это всегда трейдофф: бюджет, удобство, регуляторка и прочее.

2. Можно построить 100% защиту! 

Нет, нельзя. Всегда остаются учтенные и неучтенные риски.

3. У нас в компании меняют пароль 300к раз в секунду, а у них три года не меняли: вот он руткоз!

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


Что важно знать разработчику/менеджеру про ИБ:

1. Это отдельная область в которой много интересного, но и надо многое знать. Нормально, если лично вам интереснее другое.

2. Почитайте owasp, хотя бы топ 10 https://owasp.org/www-project-top-ten/) Если занимаетесь использованием ЛЛМ — вам отдельный топ https://owasp.org/www-project-top-10-for-large-language-model-applications/

3. Про книги: читал только одну https://www.ozon.ru/product/zashchishchennyy-kod-1387492. Ей больше 20 лет, но базовые вещи хорошо раскрыты. Еще буквально только что попалась на глаза рекомендация этой книги https://www.manning.com/books/software-security-for-developers. Если у вас есть рекомендации — велком в комменты.

4. Развивайте комьюнити. Безопасность — это не сторонняя активность, а скорее майндсет. Это должно быть вплетено в процесс разработки от проработки фичи до конечной реализации и эксплуатации.

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

6. Если у вас есть баунти программа и внешний аудит — делитесь результатами (если, конечно, с предыдущим пунктом нет проблем. На одном из прошлых мест наш верховный инфобезопасник (Саше привет 👋) делал пятничный дайджест задетекченных атак, находок сканнеров и баунти — разработчики очень включались.

7. Обучение, обмен опытом — мастхев. Достаточно динамичная область, постоянно выходит новый тулинг (как для атаки, так и для защиты), новые атаки, новые уязвимости. Кому-то надо держать руку на пульсе и опылять остальных.

#обучение

Двойная концентрация Кириллов в эфире! https://www.youtube.com/watch?v=03FnrgYLkV8

@mokevnin и @kirill_vet обсудили DDD, Event Storming и все вокруг

Когда-нибудь у меня будет пара часов посмотреть внимательно выступление и походить по ссылкам и референсам. А пока просто прикопаю это здесь https://www.youtube.com/watch?v=wo84LFzx5nI

Отличное погружение в DORA project от @IgorKurochkin и @apolomodov https://www.youtube.com/watch?v=paynIB-5pow

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

Кто совсем не в курсе: проект DORA - исследовательский проект (перешедший под крыло Google Cloud некоторое время назад). Основной артефакт - ежегодный отчет Accelerate State of DevOps Report в котором на основе опросов выявляются различные тренды и инсайты.

Этот репорт появляется на основе модели DORA Core, где собраны проверенные временем практики, метрики и результаты (outcomes - не знаю хороший аналог на русском). Модель - это скорее ориентир: она помогает командам расставлять приоритеты и двигаться в сторону постоянных улучшений, опираясь на исследования.

А вы используете какие-то модели внутри: dora, devex еще какие-либо?

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

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

С праздником, друзья!

https://www.ohyaml.wtf/ любите ли вы ямл так как люблю его я?

Этот квиз поможет лучше понять, что не так с Норвегией и почему в мире YAML ложь легко становится истиной 😅

Прошел очередной модуль обучения в Стратоплане. Это была трехдневка финансов — наверное, самая далекая от обычной для меня деятельности. Если с людьми-процессами-технологиями начинаешь работать чуть ли не с позиции individual contributor, то с финансами у меня реальный опыт весьма ограничен. Тем было интереснее!

Что осознал нового:

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

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

3. Модели это круто, но очень сложно. У нас был игровой кейс и мы с командой хотели на коленке сделать модель для учета затрат и выручки не самой сложной фирмы — не вышло (хоть и за очень ограниченное время).

4. Стартуете новое направление или стартап — накидайте простую модель, учтите жирные налоги и затраты (фот, проценты инвестору-кредитору). Можно понять сильно раньше бесперспективность идеи или перекрутить подход к монетизации.

#обучение

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

Чем же так Оракл впечатлил инвесторов? Основных драйвера вижу два:
1. Рост облачной выручки (на 28% YoY).
2. Подписанные контракты на почти полтриллиона денег. Тоже облачные, насколько я понимаю.

Облака всем нужны и корпоратам тоже, тем более Oracle помимо чистого облака Oracle Cloud Infrastructure предлагает MultiСloud DB: ораклиные стойки колоцированны в gcp/azure/aws, но весь биллинг (и остальные сервисы) остается за основным провайдером.

Но основной прирост как я понимаю произошел за счет AI хайпа. Oracle предлагает много интересного как в своей флагманской СУБД (встроенные векторные индексы и прочее), так и в IaaS (суперкластер GPU). Как следствие многие крупные ребята (openai, grok, и прочие m***) рассматривают использование OCI для своих несомненно жирных AI related нагрузок.

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

Одна из веток — идея, что разработка это не только код, а социо-техническая система. Недостаточно уметь правильно рисовать контексты, проектировать модель, пилить агрегаты — всё полетит только если команды aligned.

Не знаю как вышло, но под зонтиком DDD оказался подход Team Topologies, который набирает всё больше популярности. Основная (для меня) мысль подхода: системы становятся огромными, сложность (и техническая, и бизнесовая) постоянно растёт, но головы инженеров не резиновые. Поэтому команды и процессы надо строить так, чтобы не порождать лишнюю когнитивную нагрузку.

И сегодня это тема получила новое развитие: вышло второе издание книги Team Topologies. Авторы на стриме рассказали про подход в целом и о том, что изменилось в новом издании: https://www.youtube.com/watch?v=iTSn8o6Iq7A

А вы читали книгу? Что-то пробовали в своих командах-отделах-компаниях?

че-т мы давно реальные DDD-кейсы не разбирали.
никому ничего не нужно смоделировать?
набросил бы кто на вентилятор...

Смотрите .net days от JetBrains? Очень много интересных (по названию как минимум) докладов. Вчера было про чистую архитектуру, а прямо сейчас идет доклад про версионирование при использовании event driven подхода

https://www.youtube.com/live/Aq1xHunHNuA

Делитесь, если что-то вас зацепило!

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

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

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

Контракты. Важная часть работы СТО, было интересно послушать, но так как я особо не касался этой области в работе - не хватило инсайдов. Как то все было обще (типа рассрочка платежа это хорошо, если мы платим, если рынок поставщика, то он и диктует условия и тп). И еще не хватило какой-то ситиошной специфики, кажется она есть.

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

И последний день был про общение с СЕО и другими большими ребятами. По сути нет особого рецепта, главное знать, что каждой аудитории нужен свой формат. Три года назад на книжном клубе у Саши Поломодова мы как раз обсуждали главу Communicating the strategy из книги Technology Strategy Patterns -- многое перекликается (ссылка в первом комментарии).

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

Интересно, что Слава Панкратов (СЕО Старатоплана) недавно устроил опрос в Линкедине, видимо модулируя как раз сравнение "школы" против одного курса:

Быстрый опрос: на какой курс вы реально быстрее себя уговорите?

1 навык, 1 мес, 700 евро -- 78%

10 навыков, 5 мес, 2500 евро -- 19%

Но точно могу сказать, что Стратоплан дает хороший управленческий минимум, а с другими подобными русскоязычными школами я не знаком вовсе. Так что решение "идти-не идти" очень зависит от обучающегося. Если вы вначале управленческого пути, то вполне себе вариант, про их тимлидский курс, например, слышал много хороших отзывов. Ну и отдельные курсы (я был на Финансах, Найме, Стратегии) очень полезные и хорошие.

#обучение

Сегодня была интересная дискуссия про soft delete (ака мягкое удаление, но мне не нравится как это звучит на русском).

Что такое soft delete и как обычно его реализуют? Если мы говорим про sql базы данных, то обычно добавляют колонку is_deleted (и в довесок всякие deleted_at, deleted_by) и вместо DELETE FROM table_name where id =@id используют UPDATE table_name SET is_deleted=true where id = @id. Кроме этого во всех запросах (как минимум на чтение) добавляют предикат is_deleted=false.

Какая польза?
1. Мы не теряем данные и можем получать более полную картинку для аудита, аналитики и прочего.
2. Если кто-то (пользователь, крон) некоректно удалил что-либо, то мы можем восстановить данные без сложных манипуляций с бекапом (которого еще может и не оказаться).
3. Есть выигрыш по перфомансу на массовых операциях удалени.

Минусы тоже есть:
1. Код сложнее, надо не забывать везде отфильтровывать.
2. Перфоманс может страдать, если записей в таблице много и процент is_deleted достаточно большой, то надо будет что-то придумывать дополнительное (самое простое индекс по полю is_deleted).
3. Может пострадать доверие пользователя -- я не рекомендую (в общем случае) использовать soft delete на реально чувствительных для пользователя данных без дополнительных механизмов гарантии невосстановления.

Иногда приходит требование реализовать пользовательскую логику удаления/восстановления в корзину. И часто есть соблазн переиспользовать механизм soft delete для этих целей:
1. Удаление в корзину через set is_deleted=true
2. Восстановление через set is_deleted=false
3. Получение списка сущностей в корзине -- выборка с предикатом is_deleted=true
4. Удаление из корзины через hard delete.

Вроде все норм, разработчик ушел делать.

Но если посмотреть на это через призму DDD? Если обобщать, то у нас есть технические (инфраструктурные) решения и решения продиктованные бизнес-логикой.

1. Технические решения должны быть простыми (насколько это возможно), ничего не знать про бизнес-логику, не подвергаться регулярным изменениям, быть общими для всех сущностей.
2. Имплементация бизнес-логики наоборот должна максимально много знать про то что происходит и следовать этому знанию в том числе в нейминге: удалено, в корзине, скрыто, дезактивировано -- все это выглядит похоже, но несет различную смысловую нагрузку.
3. Бизнес-логика обычно чаще меняется и имеет тенденцию к усложнению: со временем нужно будет дать права на просмотр корзины и восстановление, необходимо будет учесть время или еще какие-то признаки.
4. Многие сущности будут требовать и технического решения и бизнесового: например даже после удаления из корзины, мы хотим иметь доступ к сущности для аудита.

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

Бонусный модуль «Идентичность руководителя» в школе СТО Стратоплана оказался неожиданно крутым.
Несмотря на странное название, это не про коучинг или философию, а про внутреннюю опору, когда вокруг всё меняется: проекты, роли, команды.

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

И, пожалуй, главный инсайт: я — разбитое сердце Джека больше, чем мои роли.
Роли могут меняться, но остаётся тот, кто их (осознанно? не всегда!) выбирает и соединяет в одно целое.