Эргономичный код

Привет!

Я тут недавно прочитал Overengineering in Onion/Hexagonal Architectures (перевод).

В целом с посылом поста я согласен (кроме мёржа REST-аннотаций в сервисы, хотя сам об этом думал), но там ничего суперкрутого - этот мой пост не про тот пост:)
А про собственную... Глу... человечность, назовём это так:)

В посте по ссылке есть тезис:

To put it another way, it is a design goal of the Application Service to host orchestration logic to allow lower-level components to become less coupled to one another.

—

Другими словами, Application Services предназначены для размещения логики оркестрации, что позволяет компонентам более низкого уровня быть менее связанными друг с другом.

Но я в 22-ом году (на 18-ом году коммерческой практики и примерно 5-ом году знания про Чистую архитектуру, ДДД, оркестрацию и сервисы приложений) всё равно изобрёл объектно-ориентированную декомпозицию. И пошёл делать по ней #project_e. И получил ровно, то, чего позволяют избегать сервисы приложений - высокую связанность между модулями-объектами.

Сколько ещё у меня таких "изобретений" из-за того что "смотрю в книгу, вижу фигу"? Вопрос риторический, конечно. Время покажет, всё что покажет - расскажу как на духу. Сегодня начал писать пост с ретро #project_r

PS>
И в топик "простых" CRUD приложений из комментов ко вчерашнему посту: в Overengineering in Onion/Hexagonal Architectures про них тоже тоже есть:

Like any tool, concentric architectures are not suitable for any software project. If the domain complexity of your problem is fairly low (CRUD-like), or if the challenge of your application is NOT in the complexity of its business rules, then the Onion/Hexagonal/Ports-Adapters/Clean Architecture might not be the best choice, and you might be better off with vertical slicing, anemic model, CQRS, or another type of architecture.

—

Как и любой другой инструмент, концентрическая архитектура подходит не для всех проектов. Если сложность предметной области вашей задачи довольно низкая (CRUDо-подобная) или если сложность вашего приложения заключается не в сложности его бизнес-правил, то архитектура Onion/Hexagonal/Ports-Adapters/Clean может оказаться не лучшим выбором, и вам, возможно, лучше использовать вертикальную архитектуру, анемичную модель, CQRS или другой тип архитектуры.

#posts@ergonomic_code #ergo_arch@ergonomic_code #ergo_approach@ergonomic_code

Кое-как с третьей попытки вымучил раздел "Зачем?" главы "Эргономичный подход".
Купили бы книгу с такой постановкой проблемы?:)

———

2.1. Зачем?

Так вышло, что все 20 лет своей карьеры я занимался разработкой "простых" CRUD-приложений.

Они всю свою жизнь (в некоторых случаях - десятилетнюю) хранили данные в реляционной СУБД одного вендора (один раз требовалась поддержка двух вендоров - PostgreSQL и Oracle). Они всю свою жизнь принимали запросы по HTTP и возвращали ответы в формате JSON.

Церемонии Чистой Архитектуры в таких приложениях только мешали.

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

Идея применения DDD в таких приложения умирала на этапе "продажи" бизнесу и команде.

Но назвать эти приложения простыми у меня язык не поворачивается.

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

А "простые" CREATE/UPDATE/DELETE операции затрагивали десятки таблиц, делали пару-тройку походов во внешние сервисы по HTTP, публиковали по сообщению в пару разных брокеров очередей и отправляли емейл "на сладкое".

Сложность этих систем заключалась не в бизнес-правилах и инвариантах, на которых фокусируются Чистая Архитектура и DDD, а в модели данных и взаимодействиях с внешними системами.

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

Картинка №2

и такие графы вызовов методов:

Картинка №1

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

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

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

#ergo_book@ergonomic_code

Кстати, я с предыдущим постом про Чистую архитектуру на 50+ рейтинга попал в программу поддержки авторов и теперь мне при рейтинге поста от 30 накидывают по 3 т.р., а от 50 - по 5 т.р. - так что можете поддержать меня и канал простым кликом:) И вам не сложно, и мне приятно:)

Привет!

Запулил статью про sql на хабр и читатели как всегда порадовали - спустя 9 минут после публикации 20 минутной статьи, какой-то скорочитатель заминусил за низкий технический уровень🤦‍♂️😂

Привет!

Жутиков вам в утреннюю ленту.

В текущем мастере Хибера 1.3М строк Java-кода:

atomic-armchair : ~/tmp > git clone https://github.com/hibernate/hibernate-orm.git                                                             
Cloning into 'hibernate-orm'...
remote: Enumerating objects: 763047, done.
remote: Counting objects: 100% (333/333), done.
remote: Compressing objects: 100% (162/162), done.
remote: Total 763047 (delta 243), reused 171 (delta 171), pack-reused 762714 (from 2)
Receiving objects: 100% (763047/763047), 281.04 MiB | 2.20 MiB/s, done.
Resolving deltas: 100% (471253/471253), done.
atomic-armchair : ~/tmp > cloc hibernate-orm/
   17126 text files.
   17002 unique files.                                          
     204 files ignored.

github.com/AlDanial/cloc v 2.04  T=25.71 s (661.3 files/s, 77566.1 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Java                         15603         266991         243111        1348435
AsciiDoc                       128          10432            660          32337
XML                            816           4135           4441          25428
XSD                             21           3912           1455          22496
SVG                             29             11             28           6548
Gradle                          41            788            436           3426
CSS                              7            176            184           3164
SQL                            218            401            346           2981
ANTLR Grammar                    8            414            698           1760
Bourne Shell                    13            222            427           1599
Text                            46            322              0           1354
Properties                      34            179            257            952
DTD                              2            143            185            805
YAML                             6             37             77            588
Groovy                           5             75             63            367
Markdown                         6            114              6            302
HTML                             2             24              4            256
Maven                            7             33             24            225
DOS Batch                        2             42              4            138
Dockerfile                       5             20            145             75
JavaScript                       1              6              0             52
Kotlin                           2              6              4             25
-------------------------------------------------------------------------------
SUM:                         17002         288483         252555        1453313
-------------------------------------------------------------------------------

#whynotjpa@ergonomic_code #tools@ergonomic_code

Привет!

Не прошло и квартала, как я опубликовал Учимся читать SQL SELECT!

Если вы уже давно тут (в бакэнд разработке) сидите - вряд ли в посте будут для вас большие откровения.
А вот если только присели и побаиваетесь SQL-я - пост должен помочь. По-крайней мере у меня опыт объяснения работы SELECT-а таким способом для студентов - строго положительный.

#posts@ergonomic_code

Привет!

Статья про чтение SQL-я уже на финишной прямой. Думаю в среду-четверг опубликую.
А пока - меня похвалил гопатыч. Хоть он и СЛАУ-переросток, а всё равно приятно:)

PS> каждая буква этой статьи написана лично мной.
Ток в коде есть немного тривиального автодополнения

Привет!

Вы уже запомнили как расшифровывается IODA-архитектура?:)

Вот вам ещё акроним, чтобы блеснуть на собесе эрудицией - self-contained systems (SCS) architecture.

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

#talks@ergonomic_code

Привет!

Полезняшка.

Вы наверняка слышали, что коммиты в гите должны быть маленькими и сфокусированными.

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

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

В общем я по этому поводу не парился и коммитался как получится.

А в прошлом году я узнал про The Mikado Method больших рефакторингов.
Суть идеи в том, что вы первым делом делаете целевое изменение, смотрите что ломается, откатываете исходное изменение, делаете следующее изменение, которое чинит поломку, смотрите что опять сломалось, откатываете второе изменение, делаете третье изменение и т.д.
Я попробовал эту штуку, но для меня это вышло как-то гемморойно.

Однако этот метод подтолкнул меня к версии создания сфокусированных коммитов, с приемлимым для меня кол-вом оверхеда и геммороя.
Выглядит он так:
1. пилите фичу до победного ваще не парясь про размер
2. шелвите всё что есть.
3. глазами просматриваете изменения в шелве выглядывая там сфокусированные коммиты и их примерный порядок
4. аншелвите изменения первого вспомогательного коммита, прогоняете тесты, коммитаете
5. повторяете п. 4 пока не закоммитаете все предварительные изменения
6. аншелвите изменения целиком (решая конфликты идеевской волшебной палочкой), ещё раз просматриваете, что там нет ничего лишнего и коммитаете финальный коммит
6.1 если нашли что-то лишнее - повторить с п. 2

Эта процедура в зависимости от тяжести случая занимает от 15 минут до пары часов, но даёт таки сфокусированные коммиты.

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

#tips@ergonomic_code #git@ergonomic_code

Привет!

Тогда я решил посмотреть на Котлин. И больше не оглядывался [на Java]
— Род Джонсонс, создатель Spring Framework, Kotlin Conf 2025

#why_kotlin@ergonomic_code #talks@ergonomic_code

Привет!

Что-то последняя большая новость никак не дозреет, поэтому пока расскажу о двух созревших.

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

Тут хочу напомнить, что ко мне можно попасть на менторинг за еду работу над TA (или так: в TA можно устроиться на работу за еду опыт). С вас реализация фич в ТА - с меня аккуратное ревью и обучение разработке в целом. И этим вы можете помочь не только себе и мне, но и всему сообществу, дав мне больше времени для работы над ЭП.

Там по началу надо будет починить пару мелких багов/фич (например этот и эту) чтобы познакомиться с проектом и процессами, а потом в бэклоге у меня пачка на мой взгляд интересных и познавательных задач: интеграция с Goggle Calendar (где надо будет ещё и с OAuth поупражняться), реализация веб-пушей (тут сначала надо будет фронт допилить, но это может я сам успею сделать), реализация отправки сообщений клиентам в телегу (через бизнес-акки или бота).

Но сразу хочу предупредить, что ревью будет дотошное и каждый МР скорее всего будет проходить 2-3+ итерации ревью.
И что делать надо будет не только бэк, но и фронт. Как минимум вёрстку на Twitter Bootstrap (с чем неплохо чат-боты справляются) и, иногда UI-логику на AlpineJS типа такой: 1, 2, 3, 4.
В целом сейчас разбивка строк кода по типам следующая: Kotlin - 81%, html - 14%, css - 3%, js - 2%
Но фронт я ревьювлю уже не так дотошно. Думаю, если вы нагенеряете код гопатычем и он будет работать - я не замечу:)

Новость №2
Я официально стартую второй подход к написанию книги. На этот раз с неофициальной пока что поддержкой проектного менеджера ИД Питер.
Пока что осилил накидать только обновлённый план. Относитесь к нему как к архитектуре проекта на 2-3 человеко-года, сделанной джуном - результат в общих чертах будет напоминать исходную архитектуру, но детали, скорее всего, будут существенно отличаться.

И быстрого прогресса по книге не ожидайте - она будет бороться за мой ограниченный временной бюджет ещё и с ТА, блогом (где у меня план таки дописать пост про SQL в ближайшие пару недель, а потом таки написать ретро #project_r) и двумя детьми.

Кроме того, я под книгу планирую написать отдельную версию ТА, чтобы:
1. коммиты были привязаны к главам
2. API сделать в виде более распространённого JSON over HTTP, а не Тру REST API
3. в целом убрать исторические наслоения и быстрые хаки в коде, чтобы код был образцово-показательным, а не реальным в части компромиссов.

В общем, интуитивно, с учётом всех вводных мне кажется, что писать книгу я буду ещё года 2-3.

Так что стей тюнед, будет интересно:)

А ну и с третьей новостью - там тоже будет интересно (я мастер интриги 😂) - надеюсь в начале июня она таки дозреет:)

#trainer_advisor@ergonomic_code #ergo_book@ergonomic_code

Привет!

Полезняшка. А для кого-то может и целых три за раз:)

Если вы не знали - с одним гит-репозом можно использовать несколько рабочих деревьев. Которые будут разделять между собой директорию .git.
Это экономит место на диске (и время синхронизации в облако, если пользуетесь) и позволяет фетчить origin только один раз.

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

А ещё если не знали - для Gradle есть плагин, который позволяет закинуть в проект git.properties-файл с инфой о сборке (дата, ветка, тэг, автор и т.д.), который можно добыть в рантайме через Actuator.

Но есть была проблема - плагин не умеет в worktrees и по дефолту взрывает всю сборку при запуске из директории со вторичной копией.
Я года 4 хачил это комментированием плагина во вторчных директориях. И раза три это случайно коммитал и откатывал.

И вот наконец написал 8 строк, которые костыляют эту проблему аккуратнее

// build.gradle.kts

gitProperties {
    val dotGit = File(".git")
    if (dotGit.isFile) {
        val actualGitDir = dotGit.readText().substringAfter("gitdir: ").substringBefore("/worktrees")
        this.dotGitDirectory.set(File(actualGitDir))
    }
}

Важное уточнение - это именно костыль и в git.properties при этом попадут данные из основной рабочей директории, а не той, где была запущена сборка

#tools@ergonomic_code #tips@ergonomic_code #git@ergonomic_code

Ну и за одно полезняшка - рыба статьи на вики о том как поддержать мультитенантность на базе схем в Spring Data JDBC. Основана на опыте её реализации в #project_r

#spring_data_jdbc@ergonomic_code #ergowiki@ergonomic_code #project_r@ergonomic_code

Привет!

Соскучились? Это затишье перед бурей - у меня зреет сразу три большие новости:)
Но новости будут в мае, а пока пара ссылок.

Я в последнее время много думаю о том, как мне железобетонно обосновать пользу применения ЭП и пока не придумал.

А сегодня наткнулся на то, что у Фаулера были примерно те же проблемы 20 лет назад.
В статье 2007 Design Stamina Hypothesis, он рисует "псевдографик", на котором задизайненная система довольно быстро (в течении недель) начинает обгонять по объёму фич, незадезайненную. Тем самым обосновывая дизайн системы (например по ЭП).

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

А проверить её невозможно, потому что по его (и моему) мнению из 2003 года эффективность разработки надо оценивать как <увеличение выручки бизнеса> - <стоимость разработки>. Но как привязать увеличение выручки к реализованной фичи - хз.

#posts@ergonomic_code

Привет!

Продолжаю ретроспективить #project_r@ergonomic_code.

Подбил Джиру, собрал немного статистики:
1. всего задач по проекту: 223 - сюда входят и задачи на разработку, и баги, и мусорные задачи и метазадачи
2. задач на разработку по бэку проекта Р: 65
3. багов в бэке проекта Р: 12
4. регрессий в бэке проекта Р: 4
5. всего задач на разработку по бэку основного сервиса: 23
6. всего багов в беке основного сервиса: 28
7. всего регрессий в беке основного сервиса: 3
8. моих задач на разработку по бэку основного проекта: 6
9. моих багов в бэке основного проекта: 5
10. моих регрессий в бэке основного проекта: 2

Это упражнение я проделал для того чтобы проверить тезис "Применение ЭП снижает количество ошибок" и я получил очередное свидетельство этому:
1. отношение задач к ошибкам в сервисе по ЭП: 16/65 = 0.25
2. отношение задач к ошибкам в сервисе не по ЭП: 31/23 = 1.35
3. отношение моих задач к ошибкам в сервисе не по ЭП: 7/6 = 1.17

Тут по цифрам вообще выходит, что багов в 4-5 раз меньше, но, имхо, стоит сделать скидку на мою предвзятость в анализе и не учтённые факторы и сделать более консервативный вывод, что ЭП снижает количество ошибок в 2-3 раза.

Вопрос в том, стоит ли оно того - как показал опрос, большинство разработчиков не видит проблем в ошибках.

По хорошему, чтобы ответить на него, надо как-то привязаться к срокам и деньгам, но в этом проекте сделать этого не получится:
1. наверное, стоит начать с того, что по срокам мы тотально зафейлились🥲 Но по моему мнению, любой другой подход дал бы тот же результат
2. у меня есть данные только по своим трудозатратам, а в проекте участвовали ещё два разработчика
3. нет референса, к которому можно было бы привязаться.

#retro@ergonomic_code #project_r@ergonomic_code #case@ergonomic_code

Привет!

Начинаю потихоньку собирать отзывы по #project_r.

Начал с простого - спросил у второго разработчика, которая раньше на Котлин не писала: "Какие у тебя впечатления от Котлина? Не появилось непреодолимого желания переехать на него?:)"

Ответ:

только положительные 😀
очень много рутиных вещей из джавы уже есть в готовых функциях, читаемость намного лучше, легче конструкции логические всякие городить)
А про переехать 🤔
Если бы меня отправили работать в микросервис на котлине, я бы точно фу не сказала, спокойно бы писала, как и на джаве)

Выделение моё.

В общем если пишите на Java и сомневаетесь нужен ли вам Kotlin - попробуйте:)

#retro@ergonomic_code #project_r@ergonomic_code #kotlin@ergonomic_code

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

#ergo_testing@ergonomic_code

Привет!

Heartbeat-пост.

Я жив. И канал жив. И Эргономичный подход жив.

Затишье в последнее время связано в основном с тем, что я в Trainer Adviser пилю интеграцию с ical-календарями.
Там не то чтобы прям рокетсайнс, но уже и не совсем тривиальный круд - будет больше примеров нетривиального кода по ЭП.

Но это я днём руками работают. А ночью думаю. Что взять на замену функциональной архитектуре. И у меня тут появилась идея CQTS Principle - Command-Query-Transformation Principle.
Берём старый добрый CQS скрещиваем его со сбалансированной формой системы и получаем профит. Это пока мысль в слух - не знаю стоит ли дальше этот термин педалировать или ну его.

#trainer_advisor@ergonomic_code #ergo_approach@ergonomic_code #functional_architecture@ergonomic_code #structured_design@ergonomic_code