Привет!

На денёк задержался, но это потому что у меня были очень интересные приседнания с тестами в эргономичном стиле - может после отпуска расскажу:)

И так, та-да-да, микропост с результатами анализа Jira Проекта Э.

Пост оказался микро только с точки зрения полировки, а по объёму - вполне себе приличный пост, поэтому сразу ТЛДР:

1) Мы действительно стали работать в два раза быстрее и допускать в два раза меньше багов
2) Я получил дополнительное подтверждение вцелом очевидным вещам:
2.1) Первый год разработки на микросервисах дороже разработки на монолите. Минимум на 30%;
2.2) Автоматизация тестирования снижает количество багов и трудозатрат на их устранение. Минимум в два раза;
2.3) Мотивация команды имеет огромное влияние на трудозатарты. От 30% дополнительных трудозатрат в случае низкой мотивации.

#posts@ergonomic_code #case@ergonomic_code #why_ergo_approach@ergonomic_code #project_e@ergonomic_code

Хотите анекдот?

Делал я тут недавно заказ всякой мелочёвки в отпуск (кстати, я уезжаю в отпуск, так что в канале будет пара недель тишины). Набрал 3-4 итема суммарно на 1500 рублей. Оплачиваю через СБП - они снимают 500, и говорят, что заказ не оплачен. Ну я не будь дурак, повторяю фокус ровно с тем же результатом. Вспоминаю Эйнштейна, оплачиваю картой - всё ок.

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

Пришло время забрать заказ - смотрю, а у меня их три 🤦‍♂️, один полностью оплачен, два частично. Забирать лишнее я не буду, так что у меня ещё рублей 600 за отказ поди отожмут.

Разбираться щяс некогда, буду пытаться выцыганить свои 1600 назад после отпуска и сильно сомневаюсь в успехе этого мероприятия.

Уверен, что у пацанов там микросервисы, саги, согласованность в конечном итоге и вот это вот всё. За что лично я заплачу своих кровно заработанных полторы тыщи. Так и живём.

Если после отпуска не забуду про эту песню - расскажу чем дело кончилось.

Привет!

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

Привет!

Сегодня у меня будет три топика.

Фидбэк по опросу

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

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

Новый микропрост

На выходных я пропрокрастинировал пост с ретро Проекта Э микропостом (опять же по степени полировки, а не объёму) с описанием решения потенциального "сложного случая" при декомпозиции диаграммы эффектов новой интеграции в Проекте Э.
Ну или аннотация привлекательная для более широкой аудитории - написал микропост с алгоритмом принятия решения о том, в какой класс или микросервис поместить операцию, которая в равной степени зависит от двух классов/микросервисов.

Пост с ретро Проекта Э

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

Текущее состояние поста следующее:
1. В посте есть 3500 слов примерно на 20-25 минут чтения
2. Осталось расписать - техсложности, факапы в проде, деплой, итоговые цифры
3. После чего будет скорее всего долгий и мучительный процесс полировки, который среди прочего будет включать:
3.1 Более глубокое раскрытие "популярных" тем
3.2 Добавление в каждый раздел подраздела "Полезняшки" - что вы себе сможете утащить из моего опыта.

#posts@ergonomic_code #project_3@ergonomic_code #case #effects_diagram@ergonomic_code

Привет!

У меня для вас снова поучительная история про тесты.

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

А тут поменяли и ой.

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

Ну думаю и ладно, чему там не работать, закоммитал, запушил, вмёржил вмастер.

Подтягиваю, мастер в ветку где это надо - а она не собирается О_О Тест не проходит. Потому что данные поменялись. А я продовый код не вернул перед коммитом 🤦‍♂️

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

#case@ergonomic_code #ergo_testing@ergonomic_code #tdd@ergonomic_code

Привет!

У меня за топиками декомпозиции ретро Проекта Э не получается раскрыть тему тестирования. И вот какой-то добрый человек сделал это за меня. С реализацией я не во всём согласен (в частности на Gherkin я со скепсисом смотрю), но концептуально - фокус на компонентных тестах и тестирование сценариев - полностью согласен.

#posts@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Играюсь со сборкой сервиса в нативное приложение, чёт мемасик вспомнился.

Как закончу - напишу микропост о своих приключениях

Привет!

Сегодня у меня день релизов!:)

Во-первых, я накатал обещанный микропрост про упражнения со Spring Boot Native.

А во-вторых и в главных - опубликовал первый том ретро реинжиниринга Проекта Э!

Ну и заодно немного обновил лендинг ЭП и добавил туда кейс Проекта Э

#case@ergonomic_code #project_e@ergonomic_code #posts@ergonomic_code

Привет!

Джуг наконец-то опубликовал запись моего доклада о декомпозиции на базе эффектов с JPoint!:)

А ещё они мне подарили бесплатный оффлайн билет на Джокер:) Не знаю, сколько ещё продлится этот аукцион невиданной щедрости, но приятно.

В общем ещё раз рекомендую Джуг в качестве организатора конференций - теперь я ещё в чуть большем восторге:)

#talks@ergonomic_code #ergo_approach@ergonomic_code #effects_diagram@ergonomic_code #project_camp@ergonomic_code #case@ergonomic_code

Привет!

Если вы как и я сильно ждали, но всё равно пропустили, вот вам "новость" - вышла Ява 21. Так как я пишу на Котлине меня в ней интересует только Project Loom - я уже знаю место в Проекте Э, которое с его помощью можно будет чуть упростить. Но ещё больше я жду Spring Boot 3.2, с поддержкой лума, который уже в стадии RC-1.

По традиции, на 21 Яву я перееду в ближайшее время и расскажу как всё прошло.

#tools@ergonomic_code #java@ergonomic_code

Привет!

Прочитал любопытную статью «Чистый» код, ужасная производительность.
Там мужик (автор оригинала) меряет урон от применения принципов чистого кода в деградации айфонов.
И в комментах его справедливо обвиняют в профдеформации.

Однако в случае полиморфизма вместо свича дело не только в производительности. Полиморфизм и лучшую поддерживаемость как минимум не гарантирует. А по моему мнению при разработке бэков информационных систем он чаще снижает поддерживаемость и за пропаганду полиморфизма я тоже анкл Боба пинал.

Но самое любопытное, что в Чистом коде анкл Боб был более осторожен. Хотя в разделе "Switch Statements" он призывает "хоронить switch в низкоуровневых фабриках", далее в разделе "Data/Object Anti-Symmetry" он уже не так категоричен:

> Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

Вопрос на миллион: как понять, что нам важнее - добавлять новые функции или добавлять новые подтипы? Наверняка я не знаю. Но моё субъективное ощущение, что в разработке бэков информационных систем чаще нужны новые функции, чем подтипы.

Поэтому я сейчас придерживаюсь эвристики, что для объектов, которые скорее представляют сервисы, я использую полиморфизм, а для объектов, которые скорее представляют данные - алгебраические типы данных (sealed классы и интерфейсы в Котлине и свежей Джаве).

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

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

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

Вообще, это всё хорошо известная и изученная Expression problem, для которой не существует (пока что) хорошего решения.

А и спасибо мужику за доп аргумент в пользу АДТ - скорее всего они ещё и работают быстрее. Хотя в случае JVM я бы за это не поручился без бенчей.

#posts@ergonomic_code #clean_architecture@ergonomic_code

Привет!

Для меня работа с БД - это самая большая боль Эргономичного подхода.
Возможно, после публикации второго тома ретро (ориентировачно в четверг) - я напишу пост о том, почему мне не подходит хибер и почему подходит Spring Data JDBC.

Но SDJ хоть и подходит концептуально, в повседневной жизни бывает довольно болючь (о чём я тоже когда-нибудь напишу).

Поэтому я, стараясь не привлекать внимание санитаров, подумываю о собственном ОРМе (у меня уже даже есть небольшой прототип АПИ, работающий поверх Мап).

И в ОРМе самой большой проблемой видится загрузка развесистых агрегатов - агрегатов с несколькими вложенными коллекциями. И если оставаться в широко поддерживаемом подмножестве SQL, то у этой задачи (как казалось) нет эффективного решения - либо куча отдельных запросов, либо декартово произведение. Либо какой-то умный планировщик, который комбинирует эти подходы, и на котором если не докторскую, то кандидатскую точно можно защитить.

В качестве потенциально решения этой проблемы на "продвинутом SQL" мне виделся SQL MULTISET или его эмуляция на json-е.

А сегодня наткнулся на статью с амбициозным названием "This is the Beginning of the End of the N+1 Problem" от основного разработчика SDJ, где он описывает решение на оконных функциях. И самое чудесное, что это решение в минимальном виде уже работает в мейлстоуне SDJ 3.2.0.

Возможно, мне всё-таки не придётся писать ОРМ и SDJ станет тем инструментом работы с БД, который не только подходит мне идеологически, но и зубную боль не вызывает.

P.S.
Но не спешите переезжать на SDJ ради решения проблемы Н+1. Если вы сейчас на хибере, то у вас совершенно точно изменяемая модель данных и, скорее всего, не функциональная архитектура. И если вы не смените подход к проектированию на неизменяемую модель данных и функциональную архитектуру, то получите все те ужасы, баги и боли, которых говорит Андрей в Меняем Spring Data JPA на Spring Data JDBC!. И очень мало получите взамен.

#posts@ergonomic_code #spring_data_jdbc@ergonomic_code #ergo_approach@ergonomic_code

Привет!

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

#posts@ergonomic_code #project_e@ergonomic_code

Привет!

Посмотрел свежий доклад Рича Хикки о том как "делать дизайн". Как всегда очень крутой.

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

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

Потому что в 3-4 последних заметках были косяки, которые привели к к переделкам реализации в процессе первичной разработки или спустя время от нескольких часов до месяца 🤦‍♂️🤯.

Плюс у меня есть идея попробовать полностью прогнать подход Хикки для решения одной из проблем ЭП - если сделаю и получится, обязательно поделюсь артефактами, которые получились в процессе.

#talks@ergonomic_code #design@ergonomic_code

Привет!

Та-да-да-да...

Анкл Боб (тот чувак, который придумал SOLID и чистую архитектуру и чистый код) написал Functional Design: Principles, Patterns, and Practices.
Кто бы мог подумать?
Тот, кто знал, что он больше 10 лет пишет на Clojure :)

Выяснил я это, потому что видел анонс книги, сейчас, перед томом с анатомией Проекта Э, решил сделать спинофф и написать большой пост "Почему ФП?" и в рамках этого поста пошёл её искать.
А спинофф решил написать потому что Проект Э сделан в функциональном стиле и этот вопрос наверняка у кого-то возникнет.

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

#books@ergonomic_code

Привет!

Прочитал Software Architecture: The Hard Parts, более подходящим названием которой было бы "Yet another монолит в микросервисы - практическое пособие для мазохистов по выбору инструментов самоистязания".

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

В остальном - очень качественный, полноценный и "comprehensive" материал, с обзором вариантов архитектур и адекватным обзором плюсов и минусов.
Так что рекомендую.

Особенно понравилось/зацепило глаз:
1. идея разделения на статическую и динамическую сцепленность. Думаю я себе это утащу в будущий пост про неё.
2. Идея пакетирования домен.поддомен.компонент и требование, чтобы компоненты были только в листах. У меня сейчас всё компоненты, при том допускаются вложенные компоненты и это не всегда работает. Не уверен, что утащу эту идею к себе, но точно подумаю в эту сторону
3. Они там так же как и я предлагаю технику выбора имени компонента, для определения его "разумности". И в целом в части декомпозиции, возможных вариантов решения сложных случаев и советов по выбору среди них - у нас совпадение процентов 80, но в книге материал больше проработан. Думаю, чем-то из книги смогу дополнить свой подход.
4. Понравилась идея семантической сцепленности - сцепленности в самой предметной области. Правда, эта штука ещё более расплывчатая, чем сцепленность в техническом решении.
4.1. Туда же хорошая идея, что техническое решение может только ухудшить (и часто так делает), семантическую сцепленность
4.2. Туда же идея, что при дизайне архитектор может "push back"-ать требования, если они содержать избыточную семантическую сцепленность, в лёгкой форме это у меня было в дизайне интеграции с ЕМИАС, где по изначальным требованиям казалось, что заказчик хочет семантической сцепленности регистрации пользователя в системе и привязке его к ЕМИАС

#books@ergonomic_code #project_e@ergonomic_code

Привет!

Подглядел в https://t.me/byndyufeed

https://ralphammer.com/make-me-think/

Пока сам не прочитал, но гифки завораживают.
Узнаёте себя при работе с современными фреймворками на левой гифке? Я да.