Вышел новый техрадар 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" (из статьи)

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

Пять монументальных статей о размере микросервиса:
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов

#DDD #MSA

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

По итогам нашего часового разговора я накидал такой список того, что я рекомендую почитать и посмотреть
1) Для будущих CTO - Technology Strategy Patterns - https://bit.ly/TechStrgPatterns - тут классно рассказано про подходы к мышлению бизнесменов и паттерны, которые они используют, например, Value Chain, SWOT Analysis, Growth Matrix, Futures Funnel, ... Эти подходы неплохо знать технарям, чтобы коммуницировать с бизнесом насчет техннических решений в терминах и подходах, которые будут им понятны
2) Про деливери - Визуализируте работу - https://apolomodov.medium.com/review-making-work-visible-8ff41a044f9b - базовая книжка про Kanban подход и чем он хорош при оптимизации Delivery
3) Про создание крутых продуктов - Дизайн привычных вещей - https://apolomodov.medium.com/review-design-of-everyday-things-part-1-ab86566431c6 - это книга про human centric design
4) Крутая книга про мышление - The Model Thinkign - https://apolomodov.medium.com/the-model-thinker-review-8ff710d38f96 - крутая книга, что улучшает понимание подходов к моделированию окружающего мира
5) Книга про топологии команд - Team Topologies - https://apolomodov.medium.com/review-team-topologies-part-1-205533a027c0 - здесь про струткуру команд и их эффективное взаимодействие
6) Мой доклад про изменение роли руководителя по мере роста компании и команды - Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - https://apolomodov.medium.com/highload-what-is-cto-406afab7fd5
7) Про изменение процессов (лучше прочитать и посмотреть видео, так как в тексте нет части про delivery managers) - Как мы меняли разработку лучшего* мобильного банка под требования бизнеса - https://apolomodov.medium.com/refactoring-of-mobile-bank-d40858d96f73
8) Моя статья про качество и скорость разработки - Качество vs скорость разработки — как найти баланс? - https://bit.ly/speedVsQuality
9) Книга про лидерство - The Art of Leadership - https://bit.ly/artOfLeadership

#SelfDevelopment #Software #Architecture #Management

В продолжение темы продуктовой разработки. На моем опыте хорошие инженерные практики (в том числе Domain-driven design) намного лучше приживаются если продакт взаимодействует с командой не с позиции "заказчик-исполнители", а активно вовлекает в свою работу и интересуется техническими аспектами реализации.