Андрей Ганичев @Ami_G0 запостил перевод статьи Камиля Гжибека про модульный монолит https://habr.com/en/company/dododev/blog/650721/

Читайте, комментируйте, нажимайте стрелочку вверх ⬆️

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

https://devblogs.microsoft.com/dotnet/happy-20th-anniversary-net/

Кто уже прочитал/полистал Hard Parts?

Подъехала запись вебинара Нила ФОрда и Марка Ричердсона Software architecture the hard parts. Они рассказывают о Granularity and coupling in microservices https://www.youtube.com/watch?v=F9r04PuaOcs

​Отрицание как защита в организациях
#защиты #психодинамика #отрицание

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

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

Также можно вспомнить, что Шок-Отрицание это первая стадия горевания по Кублер-Росс. А значит лидеры организаций не смогли после регресса восстановится за эти несколько недель. И организации, которые они возглавляют, застыли в этой защите вместе с ними.

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

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

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

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

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

Что это значит для лидеров и что с этим нужно делать?

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

Для начала нужно помочь себе. Далее советы из разряда привет капитан, но эти вещи и активности должны в каком-то виде присутствовать в нашей жизни:
- Достаточный и продолжительный сон.
- Информационная гигиена. Исключать из своего рациона информацию, которая тревожит и ситуации повлиять на которые вы лично не можете. Исключение каналов, людей и групп людей из своего поля.
- Практики заземления и расслабления. Это и работа с дыханием, и растяжки и пр. - интернет сейчас переполнен этими практиками. Выберите 1-2 и используйте их.
- Круг поддержки. Люди, с которыми спокойно, и с которыми можно заземлится.
- Помощь специалистов (психологи, психотерапевты). Войти в контакт со своими эмоциями, принять свои эмоции, отлепить от себя эмоции других людей.
- Спорт и работа с телом. Не поднимание тяжестей, что вызывает выброс адреналина и кстати дополнительный выброс кортизола. Правильный выбор - умеренный бег, плавание, скандинавская ходьба, массаж, баня и пр.
- Рутины и ритуалы- простые понятные практики, которые позволяют удержаться в реальности.

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

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

Если не читали – можно пробежать по верхам, если уже прочитали, то можно сверить часы.

https://apolomodov.medium.com/обзор-книги-what-is-domain-driven-design-7128373196e8

Читаю сейчас не спеша новую книгу Вернона. Оказывается по следам публикации книги вышел подкаст на se-radio https://www.se-radio.net/2022/01/episode-495-vaughn-vernon-on-strategic-monoliths-and-microservices/

В целом ничего неожиданного, но Вернона всегда интересно послушать)

Вышел новый техрадар thoughtworks.com/radar

Что приглянулось, чтоб подробнее поразбираться:
- транзитивная архитектура https://martinfowler.com/articles/patterns-legacy-displacement/transitional-architecture.html

- КУПИДон https://dannorth.net/2022/02/10/cupid-for-joyful-coding/

- Четыре ключевые метрики https://www.thoughtworks.com/radar/techniques?blipid=1298

- Сальса https://slsa.dev/

- https://www.testcontainers.org/

и многое другое.

Как вам эта версия радара? Что вы отметили для себя на будущее?

Транзитивная архитектура – только один из паттернов поставки для замещения легаси.

Помимо паттернов поставки (delivery)
Авторы выделяют
– паттерны понимания проблематики
– паттерны разбиения проблематики
– и даже паттерны непрерывных оргизменений.

Рекомендую к ознакомлению https://martinfowler.com/articles/patterns-legacy-displacement/

Коллеги из IT's Tinkoff начинают серию стримов по книге Влада Learning Domain-Driven Design

Первый стрим уже прошел https://www.youtube.com/watch?v=W8aZiL298E8&list=PLLrf_044z4JpIlGkIDn6sdBstsTkKMXU6&index=2

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

Не очень слежу, но тем не менее, в марте в гошечке 1.18 завезли генерики)

Я помню как они появились в c# 2.0 (а до этого я только у читал про них у Майерса). И это был кайф!

https://go.dev/doc/tutorial/generics

вот и следующая часть подоспела

Faster is slower

Иван Закревский напомнил мне про отличную статью, в которой объясняется важность системного подхода к своим решениям и почему быстрота в моменте оборачивается замедлением на дистанции. https://less.works/less/principles/systems-thinking

P.S. Есть русский перевод https://less.works/ru/less/principles/systems-thinking

https://www.meetup.com/Technical-Excellence/events/285738419/

Коллеги проводят митап про эволюционное проектирование.
Термин пришел из архитектуры и ландшафтного дизайна, позже появился и в проектировании ПО. В частности упоминается в LeSS (https://less.works/less/technical-excellence/architecture-design) и SAFe (https://www.scaledagileframework.com/agile-architecture/). Ну и нельзя не вспомнить книгу Building Evolutionary Architectures (https://www.thoughtworks.com/insights/books/building-evolutionary-architectures).

Работая с тактическими паттернами DDD, в очередной раз убеждаешься какой же этот ваш DDD "душный" в хорошем смысле слова. Вот буквально на днях пилили небольшой объект-значение, отражающий количество (при этом количество может быть дробным значением). И в процессе запилки возникли вопросы вида
- Какие могут быть максимальные и минимальные значения?
- Какая должна точность дробной части?
- Как округляется значение при выполнении арифметических операций?
- Какие вообще арифметические операции допустимы, с какими аргументами и в каких диапазонах?
- Как вести себя при переполнении?

И это довольно простой класс, ничего особенного. В обычном случае пишут что-то вроде fun calculate(float: count) и забивают, мы же уделяем столько внимания казалось бы такой незначительной чиселке. И в итоге может показаться, что все это не нужно. Да и вообще тратим больше времени - нужно подумать, написать тесты, etc. Но это не совсем так, ведь мы получаем:
- Снижение когнитивной нагрузки. Мы работаем над небольшим независимым кусочком кода и за счет этого яснее видим граничные случаи.
- Сами тесты получаются проще и шустрее, их дешевле поддерживать. Местами очень хорошо заходит property-тестирование
- Самый главный пункт - мы защищаемся от нелепых багов вида "нам передали отрицательное число в качестве количества, а мы его пропустили, потому что забыли провалидировать. Теперь надо полбазы перетряхнуть на проде, чтобы устранить последствия".
- За счет инкапсуляции упрощается сам код, ведь нам не нужно таскать и копипастить разного рода проверки.

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

как много леденцов в вашем коде? 🍭

Moscow Python Podcast продолжают копать тему Domain-Driven Design. В этот раз они позвали Колю Фоминых (@tigrrrus) из Медси Digital.

Приятного просмотра https://www.youtube.com/watch?v=nxiMm3tyDL4

Часто в индустрии слышу противопоставление заказная разработка vs in-house или outsource vs продуктовая разработка.
Причем иной раз работаешь в продукте, а отношение как к заказной. Или наоборот, ребята на аутсорсе, но настолько вовлечены – очень приятно работать.
Эта статья чуть лучше разделила для меня эти два мира и подсветила разницу.

Что я вынес из статьи:
1. Если в продуктовой компании вам кажется, что вы продаете (покупаете) время – что-то идет не так.
2. Если вам вашим разработчикам важно успеть сделать все запланированные таски (output) – возможно им будет менее интересен реальный результат (outcome).
3. Мы очень часто сталкиваемся (начиная со школьных оценок) с тем, что у нас фейковые, не приносящие ценности цели. Фича, написанная в стол. Отчет, который никто не читает.

И напоследок, пара цитат на эту тему

“The righter we do the wrong thing, the wronger we become” (Russell Ackoff)
"Successful outcomes over efficient delivery" (из статьи)

Понимайте своего потребителя и делайте правильные вещи