У меня была уникальная возможность послушать этот доклад на русском😎 Очень интересный подход и свежий взгляд на каплинг)

Друзья, с наступающим (может у кого-то уже всё случилось). Желаю всем в Новом году здоровья, удачи и интересных задач.

Денис Ежов (тимлид и разработчик из Спортмастера) написал (уже третью) статью про свой опыт использования DDD. https://habr.com/en/company/sportmaster_lab/blog/711298/

Принимать решения – это сложно, надо многое учесть и не забыть детали. А еще бы лучше визуализировать процесс принятия решения, чтоб был драфт, который можно обсуждать с коллегами и который можно прикопать как артефакт. Для этих целей придумали кучу канвасов, фреймворков и прочих моделей. А добрые люди собрали это все в одном месте https://untools.co

Отличная подборка статей для погружения в event-driven архитектуру. По-моим ощущениям EDA (или EDM event-driven microservices) уже стала одним из основных подходов в разработке современных сложных систем. Рекомендую погрузиться в эту тему, если вы еще не успели. https://aws.amazon.com/blogs/architecture/lets-architect-designing-event-driven-architectures/

Отличная подборка книг 📚

Robert Laszczak поделился данными о продажах своего кнового курса Go Event-Driven. Такая история успеха безумно мотивирует, но когда осознаешь сколько труда под капотом, ловишь себя на мысли “может ну его”)

Друзья, наверняка, кто-нибудь уже вовсю экспериментируют с chat gpt. Поделитесь интересными находками с точки зрения помощи разработчику)

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

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

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

Enjoy! https://www.youtube.com/watch?v=1ZyR_tgGTp8

Новый радар вышел. Посмотрим что интересного https://www.thoughtworks.com/radar

Для затравки три блипа
1. https://www.thoughtworks.com/radar/tools/eventcatalog каталог событий. Интересная задумка, надо покопать.
2. https://www.thoughtworks.com/radar/techniques/run-cost-as-architecture-fitness-function Все так или иначе начинают думать про стоимость работы кода.
3. https://www.thoughtworks.com/radar/techniques/zero-trust-security-for-ci-cd весь апрель никому не верь, а ci\cd - не верь никогда)

https://habr.com/en/companies/flant/articles/732152/

Отличный дайджест для #k8s от коллег из Фланта

Всегда интересно почитать про DDD за пределами моего информационного пузыря 🤓

Domain Driven Design

Domain Driven Design (DDD) – на первый взгляд, что-то такое сложное. Да и на второй тоже сложное. Не очень понятно, с чего начинать.

Начать можно со статьи Domain-driven design: рецепт для прагматика.

Автор на примерах проходится по основным концептам DDD:
– ubiquitous language – всё обсуждение происходит в терминах единого языка
– domain model – некий набор сущностей и сценариев, связанных с предметной областью
– bounded context – некие рамочки, в которых существует доменная модель и единый язык

Основная идея DDD – борьба со сложностью бизнес-процессов, их автоматизации и реализации в коде. Domain – предметная область и от неё нужно отталкиваться при проектировании и разработке.
Бороться со сложностью – звучит многообещающе, но "прежде чем начать бороться со сложностью с помощью Domain-Driven Design, нужно научиться бороться со сложностью самого Domain-Driven Design".

Не факт, что будете применять, но знать что это за зверь – стоит. К тому же, можно перенять некоторые полезные практики, например, ubiquitous languge – единый язык общения. На эту тему написан занимательный комментарий, что пример, приведённый в статье из мира продаж всем понятен, тривиален и нет смысла для него составлять ubiquitous languge. На что ему приводят такие термины из мира продаж: ретроскидка, скидка по фактуре, ценовое соглашение, отличное от базового и др. Кажется, не всем понятно. Это я к тому, что использование ubiquitous languge в любой области облегчит взаимодействие.

Можете посоветовать что-то толковое на тему DDD?

#skills

Кстати про нейминг, пропустил отличную статью от коллег из Додо https://habr.com/en/companies/dododev/articles/714512/

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

Продолжаем тему нейминга. Неплохой и местами капитанский доклад https://youtu.be/KHgftXIlGsY

Вы обсчитываете свои изменения по скарфу? Тогда мы идем к вам!)

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

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

Петя, из-за тебя релиз вышел на три дня позже срока и всем пришлось работать до ночи. Заказчик был очень недоволен. Разве сложно написать три строчки кода, чтобы покрыть изменения после фикса бага?

Петин мозг в данном случае воспримет эту ситуацию как прямую угрозу жизни. Он, конечно, постарается сделать все, чтобы ее исправить, но осадочек, что называется, останется. И в тот момент, когда вы будете ему рассказывать про tdd, подсознательно его больше будет волновать тот факт, что если он опять накосячит с тестами, то его вышвырнут на улицу, а попробовать что-то новое без косяков невозможно, поэтому да ну его.

Как это исправить? Для этого умные люди придумали SCARF-модель, которая построена на удовлетворении 5 критически важных для мозга социальных потребностях: статус, определенность, автономность, принадлежность и справедливость.

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

Опустим закадровое желание побить Петю и посмотрим, что дает такая формулировка:
🔹+2 к статусу ("без тебя не смогли", "нам важна твоя работа")
🔹+1 к определенности (ты, конечно, налажал, но мы тебя не выгоняем)
🔹0 про автономность (увы)
🔹+1 к принадлежности ("команда")
🔹+1 к справедливости (ты что-то сделал, оно привело к таким-то последствиям, вот что тебе нужно сделать, чтобы исправить ситуацию).
Итого: 5 баллов.

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