Есть отличная книга https://jacquiread.com/books/communication-patterns/

Джеки Рид пишет (и рассказывает на конфах) как правильно и нашем мире разработки и не только доносить свою мысль до целевой аудитории.

Сложно выделить какие-то отдельные поинты, это скорее сборник паттернов, рецептов и советов.

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

Не чекал полностью, ео вот и видео к презе https://www.youtube.com/watch?v=JUqrNWKPMYA

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

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

В Португалии и части Испании глобальное отключение электричества. Света не было примерно 9 часов. Не было инета, мобильная связь работала местами и с перебоями. Кассы в Ашане пока работали, но не долго.

А как ваши системы пережили бы такое?

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

Недавно дискутировал с коллегой про виды двойников (aka test doubles). Я отстаивал право на существования фейков, он топил за то что есть моки, а остальное и не надо вовсе. Этому спору лет 20 на самом деле, и там сломано столько копий, что уж и не сосчитать. И конечно, я не собираюсь сейчас объяснять какой подход лучше. Всем и так очевидно, что тот где тестируется состояние с использованием фейков, Object Mother и прочего.

Но мне стало интересно, что говорят наши Лучшие Лидеры Мнений (то есть LLM).

Подготовил максимально нейтральный промпт:

Provide an example unit test for methods that involve interfaces in .NET 8, using any public libraries.

и прогнал его через несколько моделей (sonnet, gemini, grok, gpt, deepseek...):

Все модели в своих примерах использовали xunit и moq (самая популярная библиотека в дотнет мире для мокирования). Думаю, что подход с моками сейчас в лидерах и дальше он будет набирать все большую долю, так как новички и кодогенерация будут использовать моки все чаще и чаще. Ведь если либа-утилита используется в ответе без явного упоминания – это хороший знак! Ее начинают использовать, новый код опять подтверждает приверженность этой либе и еще чаще попадает в ответы.

Кажется, что технопиар должен быть сейчас направлен на то, чтоб либа попала в кодогенерацию, этакое новое SEO. Может даже появятся профессия вроде Prompt Evangelist или LLMRel – человек, который убеждает модели выбирать правильную либу.

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

https://habr.com/ru/articles/908782/

Плюсики на хабр, вопросы и комментарии – сюда, @InnokentyB с нами

Можно по-разному относиться к вайб-кодингу и кодинг ассистентам, но так или иначе подход к разработке уже поменялся и будет меняться дальше. И надо знать не только сильные стороны, но и уязвимые места. В блоге у Фаулера вышла новая статья с обзором некоторых возможностей потенциальных проблем. https://martinfowler.com/articles/exploring-gen-ai/software-supply-chain-attack-surface.html

Ого, 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 ложь легко становится истиной 😅