emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

Подборка постов, которая заменит вам прочтение пары книжек по конфликтам За 9 лет работы мы проанализировали несколько тысяч конфликтных кейсов. На их основе получился фреймворк для работы с конфликтами, который позволяет легко анализировать любую ситуацию и быстро выбирать оптимальную стратегию коммуникации. Мы душнейшие душнилы с точки зрения системности :) Наша система теории работает повсеместно: в огромных корпорациях и малых бизнесах, технологичных стартапах и госкомпаниях, на кассе в магазине и семейных отношениях. Основа этой системы — «лестница», которая делит решение конфликта на 4 этапа. Давайте расскажем, какие посты помогут вам ее освоить и чувствовать себя уверенне в коммуникации👇🏻 1️⃣ Начните с поста про лестницу решения конфликта. 2️⃣ Чтобы освоить приемы для работы с эмоциями, читайте этот пост. Дали в нем 3 универсальных способа, как снять напряжение в разговоре и отрезвить собеседника. 3️⃣ Чтобы научиться уверенно доносить свои потребности и недовольство без агрессии и манипуляций, прочитайте следующие материалы. В них мы разбираем обозначение личных границ на разных кейсах и примерах: 1. Статья на VC про универсальную формулу обозначения личных границ 2. Как перестать закрывать глаза на нарушение границ 3. Почему не стоит быть «удобным» и как показывать границы на работе 4. Кейс подписчицы про смещение авторитета и критику на работе 4️⃣ Если человек нарушает ваши границы осознанно, пора их защищать. Выбирайте, каким приемом будете противодействовать манипулятору: декодирование, гиперболизация, ломание причинно-следственных связей. 5️⃣ Про финальный этап решения конфликта — сепарацию, наш тренер Михаил Ромашов рассказал в статье на VC. Читайте, чтобы научиться грамотно расставаться с людьми. 💬 Фух, ну вроде все! Изучайте и приходите практиковаться на наши открытые воркшопы 28 и 30 мая. Будем разыгрывать кейсы и обсуждать риски и возможности различных стратегий поведения.

О книге "Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems" by Vlad Khononov. Эта книга об искуссте побеждать. Eric Evans говорил, что "Software design is a constant battle with complexity". И как показывает практика, далеко не все проекты на рынке одерживают победу в этой борьбе со сложностью. Стоимость разработки иногда возрастает экспоненциально, а рентабельность падает с таким же ускорением. Для одержания победы в Самбо не нужно быть сильнее противника - достаточно противопоставить свои сильные группы мышц против его слабых групп мышц в болевом приеме. В одном фильме красиво было сказано: "Искусство воевать заключается в том, чтобы быть сильным в нужное время в нужном месте." Что произойдет, если атлет в фитнесс-зале во время приседания пренебрежет техникой безопасности и будет держать спину неровно? Вес штанги больше не будет равномерно распределяться по всей площади позвонка, пятно контакта уменьшится, удельная нагрузка возрастет, и предел прочности позвонка может оказаться недостаточным, чтобы выдержать вес. То же самое может происходить и с ИТ-проектом. Эта книга о том, как создать красивого атлета, а не больного человека. Какое главное правило инвестора на фондовом рынке? Диверсификация, т.е. распределение рисков таким образом, чтобы каждая категория риска не превосходила допустимый предел финансовой устойчивости. Плавучесть судна обеспечивается водонепроницаемыми перегородками, обеспечивающими превосходство гидростатической подъёмной силы над силой тяжести воды в месте пробоины. Видели когда-нибудь как море режет скалы? Обязательно посмотрите - вдохновляет. Стекающие капельки воды прорезают в камне бороздки и углубляют их до тех пор, пока глыба не обрушится. Капля против скалы! Вода камень точит! Почему ледокол преодолевает толщи льда, а корабль - нет? Ледокол атакует лед в том направлении, в котором способен обеспечить силовое превосходство. Он атакует его сверху, где сила сопротивления льда наименьшая. А корабль - с торца, где силовое превосходство остается за льдом, поскольку в горизонтальной плоскости толща льда простирается на сотни километров. Лед сильнее ледокола. Но ледокол способен создать силовое превосходство в нужное время в нужном месте. Этого достаточно, чтобы шаг за шагом проложить маршрут полностью. Понимание этого принципа позволило человеку покорить Северный Полюс! Высокая концентрация сложности программного кода может превосходить ограничения краткосрочной памяти человека. Победа над сложность достигается минимизацией объема программы, о котором нужно думать в конкретный момент времени, т.е. возможностью рассмотреть фрагмент сложности изолированно, чтобы при этом уровень рассматриваемой сложности не превосходил ограничения краткосрочной памяти человека. Звучит легко. На практике этому часто препятствует то, что мы называем Coupling. Искусство управления Coupling развивается лучшими умами отрасли уже несколько десятилетий. Эта книга является наиболее полным, исчерпывающим руководством, финализирующим все достижения человечества в этой борьбе со сложностью. В борьбе, которую ведет каждый программист каждый день. Эта книга о том, как покорить Северный Полюс в разработке программного обеспечения.

По результатам прошлогоднего опроса https://devcrowd.ru/go-2023 более 50% Golang-разработчиков неуверены в своих знаниях по архитектуре приложения и 48% - по распределенным системам. 39% изучает алгоритмы (вспомнился анекдот: "а этот готовится к собеседованию - уволить"). Каждый шестой Go-разработчик открывал в том этом году книги Роберта Мартина. Это прогресс. Еще четыре года назад было "Don't do Java in Golang!" "Clean Architecture" и "Clean Code" - в топе, наряду с "Кабанчиком" by M.Kleppmann. Главный мотивирующий фактор - решение интересных задач и сильная команда. Перевешивает даже зарплатные ожидания (на 2%).

Топ-3 задач, на которые ушло больше всего времени у Product Owners: "встречи, налаживание процессов и планирование". При этом 17% столкнулись со сложностью "Взаимодействия с другими командами", т.е. проблемой Брукса. Встречи отнимают невероятно много ресурсов. Большинство продактов тратят на них от 40% своего рабочего времени. А 27% столкнулись со сложностью в "бюрократии и политикой в компаниях". При этом 23% опрошенных еще и занимается рабочими задачами в выходные. Лишь 6% продактов уверены, что не сталкивались с признаками выгорания. Для остальных "Работа в условиях большой нагрузки и выгорания " - главная проблема. Общий вывод. Проблемы с точностью планирования, межкомандной коммуникативной нагрузкой, внутрикомандной когнитивной нагрузкой, сложность погружения в устройство продукта и предметную область, - являются отражением архитектурных проблем, и, прежде всего, функциональной (компонентной) декомпозиции системы. А то, что каждый четвертый имел сложности с такими моментами, как "Бюрократия и политика в компаниях" и "Изменение процессов и продуктовой культуры в компании", отражает уже проблемы управленческие. Обращает на себя внимание то, что среди главных проблем перечислены такие проблемы, как "большая нагрузка" и "планирование". Между этими проблемами есть связь, т.к. нагрузка является результатом планирования. Иными словами, качество решения второй проблемы является источником первой проблемы. А качество решения второй проблемы отражает архитектурное здоровье системы, чем оно ниже, тем хуже прогнозируемость планирования. Источник: https://devcrowd.ru/pm24/ Thanks to @nikitapinchuk В целом опрос коррелирует с моим опросом. Общий вывод таков, что каждый четвертый доволен условиями работы лишь потому, что сам их создал себе. И только каждому двадцатому повезло попасть в благоприятную среду, созданную другими.

"Design and Reality: Essays on Software Design" by Mathias Verraes & Rebecca Wirfs-Brock https://leanpub.com/design-and-reality

Не перестаю удивляться народной мудрости. Галера - очень меткая (хотя и сатирическая) метафора для ИТ-проекта. Гребцам нужно догрести из пункта А в пункт Б. Представим, что конструкция дала течь. Обратите внимание, что по отношению к главному инструменту управления сложностью, абстракции, применяют такой же термин - "протекание". А все, что протекает, может потонуть. В чем может потонуть абстракция? В сложности (нерелевантных деталей), где "плавучесть" абстракции ограничена возможностями краткосрочной памяти человека. Итак, конструкция протекает, наполняется водой (сложностью). Судно погружается, сила сопротивления движению растет. Если не принимать меры по борьбе за живучесть судна, то сила тяжести превзойдет силу плавучести (правильней было бы сказать - выталкивания, гидростатическую подъемную силу). То же самое происходит и с рентабельностью проекта. И как показывает статистика, затопление происходит обычно в геометрической прогрессии. Для борьбы за живучесть судна были придуманы водонепроницаемые переборки, которые позволяют остановить затопление судна (как и Bounded Context). Но на галерах таких переборок может не быть. И вот команда стоит перед выбором - грести или спасать судно? Проблема в том, что с верхней палубы не видно того, что в трюмах воды по уши. И погружение судна в воду не так уж и заметно сверху - никто ведь не замерял осадку. И, кажется, что достаточно просто расчехлить плеть, чтоб заставить гребцов грести быстрее. Чтобы восстановить скорость, нужно освободить судно от накопившейся сложности, а еще лучше - возвести водонепроницаемые переборки. Это означает потерять ход. Но восстановить скорость. Но это неточно. Можно и не восстановить. А вдруг не сумеют? Точно, весло так и не починили. А вдруг и нет никакой течи? А вдруг не из-за течи падение хода? А так хоть какой-то ход есть... Кажется, вон тот гребец в углу стал медленней грести. Или не стал? Замеров-то нет. Стал, вон другие галеры вырвались вперед. Точно. Ага. Нужно таки расчехлить плеть. А может тот гребец прав, и все дело в течи? Нет, течь грести не умеет. Причем здесь течь? Где вёсла, а где эта мифическая течь... Все дело в том, кто гребёт. Точно. А про течь они все придумали. Хотят в трюм заманить. Только положи им палец в рот, ага, щас..

👩‍💻Плейбук для развертывания инструментов разработчика После переустановки Linux решил наконец собрать скрипт для установки тулинга на свежую ОС. Надоело красноглазить😁 Вылилась эта затея в Ansible Playbook с Golang, Python, Docker, K8s, Helm, Git, VS Code с плагинами, ZSH. Установка в одну команду🚄. Выложил на Github, чекайте, если вам интересна тема рабочего тулинга и Ansible😊 https://github.com/abstractart/local-machine-playbook

https://bessey.dev/blog/2024/05/24/why-im-over-graphql/ Просто прекрасная статья о сложностях GraphQL vs REST

продолжение https://miralina.substack.com/p/2