Никогда такого не было и вот опять!

Интересный пост от Владимира Хорикова о DDD-трилемме. Не совсем согласен с выводом о том, что нужно предпочитать чистоту (мне больше по душе инкапсуляция), имхо всё-таки некоторые внешние операции допустимы, правда их совсем немного. Но такая трилемма действительно имеет место быть.
https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/

Хорошая подборка бесплатных и условно-бесплатных сервисов для разработчиков. CI/CD, мониторинг, управление логами, бесплатные опции крупных облачных провайдеров и другое.

https://free-for.dev

Если вы только собираетесь создавать новый проект на java\kotlin\scala, то я для вас нашел отличный репозиторий. Из него можно позаимствовать gradle\maven конфигурацию, с подключенными и настроенными тулзами типа линтеров, jococo и всех прочих.

Если же не собираетесь стартовать — просто почитайте его readme файл, уверен что вы найдете не одну best практику, которую стоит использовать.

https://github.com/binkley/modern-java-practices

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

https://stringconcat.com/ru/coding-interview-ru/

Вышел свежий техрадар. Рекомендую походить по расхлопам, почитать мотивационную часть и референсы. Также обратите внимание на тренд той или иной техники или платформы.

На что я обратил внимание
- пара ссылок на книгу Team Topologies (в когнитивной нагрузке и платформенных командах);
- облачные песочницы, даешь дев-стенды разработчикам!
- захолдили SAFe и GitOps.
- захолдили пулл-реквесты как инструмент peer review (недавно делал пост со схожими мыслями).

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

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

-почему мы используем кафку?
-не знаю, вроде нормально ведь.

Чтобы не попадать в такие ситуации придуманы architectural decision records. Это фиксация принятых архитектурных решений с обоснованием почему. Если хотите начать использовать, то вам в помощь прекрасный шаблон ведения таких записей.

https://github.com/adr/madr

Да, это хорошая идея вести запись прямо в репозитории

Одно дело, когда политик спрашивает «Как ваши дела?», и совсем другое, когда ваша мама спрашивает «Как ваши дела». Они имеют ввиду совершенно разные вещи.

Таким образом, 2 семантически одинаковые фразы имеют совершенно разное значение в зависимости от контекста. И вот тут то мы пришли к определению Bounded Context из DDD.

Как определить, что мы наткнулись на 2 контекста? Ответ прост: когда одна фраза (или сущность) не может быть понята однозначно без знания контекста.

Нашли такую фразу? Поздравляю! Вы нашли bounded context. И два значения одного и того же термина.

💀 Тем, кто устал

Айти — постоянная гонка, от которой можно и приуныть в конце-концов. Сегодня поговорим о том, как выжить, когда уже сил не осталось.

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

Приходите читать!

https://stringconcat.com/ru/get-sane/

Не всюду разработчику хорошо. Бывает, с виду всё нормально, но на деле проект оказывается полон особенностей. День за днём они грызут душу и тело, люди выгорают и отправляются на мороз, общаться с психоаналитиком.

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

https://bloody-enterprise.stringconcat.com/#/

Только-только вышла в свет вторая версия Микросервисов от Сэма Ньюмана. Судя по доступному сэмплу он уж больше рассказывает о технических подробностях реализации, таких как распределенная трассировка, агрегатор логов. Но самое интересное - это книга не агитирует "за" микросервисы, но и не агитирует "против". Обещается очень здравый подход с описанием альтернатив микросервисам. Книга сейчас доступна только в версии для Kindle. На английском само собой https://www.amazon.com/Building-Microservices-Sam-Newman-ebook-dp-B09B5L4NVT/dp/B09B5L4NVT/ref=mt_other?_encoding=UTF8&me=&qid=1628333621

Послезавтра проводим митап уходящего лета. И программа получается несколько монолитной) Первый докладчик – Олег Федосеев (@olegfedoseev) из Циан расскажет про вторую жизнь монолита:

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

Очень актуальная тема на наш взгляд. Ссылка на митап https://www.youtube.com/watch?v=5Adgq-4KJoo, вопросы можно задать тут - https://app.sli.do/event/3xzwxrro

Проводим очередной вебинар по Clean Architecture. Если кто ещё не видел — подключайтесь!

https://youtu.be/lQMWGWA9FYs

Robert Laszczak из Three Dots Labs написал на английском про тёмные века софтверной разработки: https://threedots.tech/post/software-dark-ages/

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

Автор наглядно объясняет, как такая ситуация возникает:

1. Не поняли, что нужно → получили унылое и дохлое.
2. Повторяем 1 пункт, пока не надоест.

Еще Роберт пишет, что делать и почему этого ещё не сделали и, конечно же, проповедует благое DDD.

А Женя из @dddevotion вдруг взял и перевёл статью специально для тех, кому лень читать по-английски. За что ему большое спасибо!

Нил Форд, автор fundamental of software architecture, опубликовал новую книгу “The hard parts of software architecture”. В ней он говорит в сущности о трех вещах:
— каждое ваше архитектурное решение это компромисс
— о том, насколько большими должны быть сервисы
— о коммуникации между сервисами

Послушать о книге можно в подкасте Thoughtworks:
https://www.thoughtworks.com/en-sg/insights/podcasts/technology-podcasts/the-hard-parts-of-software-architecture

Книга доступна только в электронном виде, ну и, конечно, только на английском:
https://www.amazon.com/Software-Architecture-Parts-Neal-Ford-ebook-dp-B09H2H5QKC/dp/B09H2H5QKC/ref=mt_other?_encoding=UTF8&me=&qid=1634275068

На самом деле очень сложно найти хорошую книгу по архитектуре. И “Fundamentals of Software Architecture” я прочитал на одном дыхании, а кое-что даже ни один раз. Полагаю, новая книга станет бестселлером!

Новый выпуск technology radar уже готов к выходу. Thoughtworks презентует его online 20 октября в 17:00 по Москве. Регистрация обязательна https://www.thoughtworks.com/en-sg/radar/technology-radar-webinar

Свежая пресса, господа!
Только что вышел Technology Radar.

Меня лично в этом выпуске зацепил фокус на том, как команды перестраиваются на удаленную работу.
Trial: Remote mob programming. Говорите что pair programming - слишком затратное дело? Thoughtworks пробует подход, когда вся команда собравшись удалённо работает над сложной задачей

Trial: Single team remote wall. Привыкли к том у что все стены в вашем офисе изрисованы схемами и увешаны стикерами? Ничего не мешает сделать виртуальную стену!

Adopt: Zero trust architecture. Когда я начинаю проект всегда встает вопрос как организовать security внутри кластера. Должны ли мы доверять вызовам, только потому что они ходят внутри защищенного периметра или все таки нет?. Zero trust architecture говорит что доверять мы не должны никому, И защищенный периметр - не лучший вариант

Adopt: 4 key metrics. На самом деле я удивлен, что они только сейчас вошли в adopt. Если вы еще не смотрели на них, то очень советую. Они про то, как померить эффективность доставки software, или при более широкой трактовке как померить эффективность работы команды

И многое другое….

https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2021/10/tr_technology_radar_vol_25_en.pdf

Графики к посту о статистике

Статистика и вероятностные методы в разработке

В сентябре на Хабре вышел перевод статьи Сони Сайдеровой о вероятностных прогнозах. Хабро-эксперты по всему на свете обошли её стороной и не закидали какахами, а зря: тема интересная и перспективная.

Статистику применяют для прогнозирования и оценки проектов, а ещё с её помощью можно отслеживать проблемы. Например, предсказывать сбои на проекте до начала пожара и вовремя замечать признаки выгорания у разработчиков. Максимально упрощенно работает так:

Что-то меняем → Смотрим на показатели → Делаем выводы

Например, внедряем CI или меняем архитектуру, а потом смотрим, как меняются трудозатраты на задачу для каждого участника процесса.

Один из авторов канала внедрял статистическое отслеживание динамики процессов разработки. Графики постом выше — было и стало по одному разработчику (исходные данные утеряны, остались только скрины с разным масштабом).
Ось X — количество жоподней на одну задачу.
Ось Y — количество задач, которые заняли соответствующее кол-во жоподней.

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

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

Если вам интересно про прогнозирование и оценки, как-нибудь напишем развернутый пост. Оставляйте комментарии, делитесь мыслями.