Мысль четвёртая

А ну и мысль четвёртая - если вы пишите бэки - вам надо ФП/ФА, а не ООП/DCI :)

Точнее DOP/ФА как здесь, а не чистый ФП как здесь

#dop@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code

И в догонку накопал жёский наборос

It is high time to ‘kill’ Clean Architecture, the Hex, the Onion and the VSA and come up with something better

One of the most common ‘architectures’ among aspiring software designers is either the Clean Spaghetti Architecture or the Hexagonal Bubble Architecture. I don’t blame them for using these antipatterns. At least they are trying something new. They are going out of their comfort zone, ready to make mistakes. Here is a visual representation of both these architectures

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

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

PS> сам пост ещё не прочитал

#clean_architecture@ergonomic_code

Этот неловкий момент, когда не хватает ширины UltraWide экрана.

#изжизниспикера

Привет!

Тизер из доклада - я кажись нашёл железобетонный аргумент и пример в пользу ФА.

Это графы вызовов методов одной и той же реальной функции реального коммерческого проекта.

Слева - сделано "как обычно".

Справа - по ФА/ЭП.

Правый граф в проде (давно уже).

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

И правый граф работает в 300 раз быстрее (я замерял).

Оба графа сделаны на Java 8 + Spring Boot.
Левый граф сделан на Hibernate, правый - Spring JDBC Template, с небольшими вкраплениями Hibernate

Если и после этого люди ещё будут сомневаться нужно ли им ФП/ФА - я умываю руки.

#functional_architecture@ergonomic_code #whyfa@ergonomic_code #whynotjpa@ergonomic_code

Привет!

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

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

#tdd@ergo_approach #case@ergo_approach

Привет!

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

Привет!

Я пару лет назад пинал декомпозицию по фичам, за то, что

Когда же вы сядете и попытаетесь декомпозировать систему по фичам, у вас тут же возникнет множество вопросов:

"А фича - это вообще что такое?", "Как мне из требований получить набор фич?", "Судя по примерам, фича - это таблица. Мне что, заводить по пакету на каждую таблицу?", "А что делать с таблицами связками?", "Что делать с функциями, которые затрагивают две и более таблицы - в какой пакет их помещать?", "А что делать с функциями, которые работают не с таблицами, а с REST API?", "А с S3?", "А куда мне положить DSL создания Excel файлов для нескольких фич? В utils?"

И тут я кажись познал дзен. Фичи надо искать не в требованиях, домене или таблицах/сущностях.
Их надо искать в порядке и этапах реализации требований и т.д.

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

Однако в целом я всё ещё не сторонник тотальной вертикальной декомпозиции в духе вертикальной архитектуры, декомпозиции по фичам или моей же декомпозиции по объектам (раз, два).
Потому что по моему опыту они ведут к слишком высокой сцепленности (явной или не явной) между слайсами/фичами/объектами.

Но вот использовать декомпозицию по фичам как вторичную - после разделения на слои приложения и домена (what-the-system-does и what-the-system-is в терминах Lean Architecture) - кажется вполне себе вариант.

#design@ergo_approach

Привет!

В комментах задали вопрос:

А есть какое-то описание принципов обработки ошибок в ЭП? Типа где обычные исключения, бизнес исключения, где возврат значения (Result?) и почему и т.п.

И ответ получился размером с небольшой пост, так что решил запулить его в канал.

Прямо сейчас стратегия обработки ошибок не то, что не описана, но даже не детализирована.

Но общее видение такое:

Я исхожу из того, что существует 4 типа ошибок:

1. Ошибки оборудования
2. Ошибки программиста бэка
3. Ошибки программиста фронта/поломки обратной совместимости
4. Ошибки, которых не должно быть.

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

Ошибки программиста бэка
Логические ошибки - NullPointer, IllegalArgument, IndexArrayOutOfBounds и т.д. Их чинят разрботчики бэка и для починки требуется редеплой бэка.

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

Ошибки которых не должно быть (ака доменные ошибки)
Это когда софт работает "нормально", но пользователь с его помощью пытается сделать то, чего нельзя. Их чинит юзер, без какого-либо редеплоя.

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

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

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

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

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

И вот исходя из этой классификации у меня общая стратегия следующая:
1. Ошибки оборудования и разработчика бэка - по максимуму игнорим. Они вылетают исключениями из библиотечного кода и прямой наводкой летят в глобальный обработчик ошибок, который покажет юзеру "У нас проблемы, работаем, попробуйте позже"
2. Ошибки разработчика фронта - в идеале аналогично, но только лучше веб-фреймворк настроить так, чтобы он сам с ними разбирался.
3. А вот "доменные" ошибки - в идеале должны возвращаться в виде Result-а и контроллер/фронт должны показать юзеру понятную ошибку и дать инструкции по её устранению

Однако есть нюанс - Spring не дружит c Result. И если вернуть ошибку в виде Result, а не исключения - он транзакцию не откатит. Это можно захачить кастомной аннотацией, но не хочется.

Поэтому текущие правила работы с ошибками у меня такие:
1. Ошибки оборудования я стараюсь по максимуму игнорить.
2. Ошибки разрботки бэка (помимо тех, что рантайм мечет) я мечу стандартными error, check, require и т.д. и они улетают наружу 500-ками
3. Бизнес-логика возвращает ошибки Result-ом (в TA такого ещё нет)
4. Оркестрация выбрасывает ошибки (в том числе Result от бизнес-логики) исключениями
5. Контроллеры ловят исключения в Result и разбирают его в функциональном стиле

Привет!

Список рекомендованных анкл Бобом книг
Я прочитал всё кроме Fundamental Algorithms и Analysis Patterns - есть ли в мире больший задрот, чем я?🤣🤓

#books@ergonomic_code

Привет!

Недавно зарелизали Postgres 17.
Для меня актуально - как всегда всякие оптимизации и больше поддержки json-а

Привет!

Пока готовил доклад наткнулся на прикольную штуку: Cognitive Complexity - метрику оценки сложности кода, которая явно ближе к правде, чем Cyclomatic complexity.
Она, на мой взгляд, тоже не идеальна, так как не учитывает наличие и количество изменяемого состояния (а это важно) и позволяет "замести" сложность под вызовы функций, но даже в текущем виде полезна и подсвечивает места, с которыми точно надо что-то сделать.

И для Идеи даже есть плагинчик, который прям в редакторе рисует сложность методов. Только для Котлина он не учитывает ветвление потока управления даже в базовых map, filter, forEach и т.д., поэтому может сильно приврать в сторону простоты. Но если в коде откровенное кровавое месиво - он это подсветит.

#tools@ergonomic_code #craftsmanship@ergonomic_code

Привет!

У меня сегодня был прогон доклада с экспертом - Максом Моревым - и на обсуждении вспомнили почему в Красной книге (второй библии ДДД) примеры на Java:

First of all, and sad to say, I think there has been a general abandonment of good design and development practices in the Java community. These days it may be difficult to find a clean, explicit domain model in most Java-based projects.

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

И наш с Максом опыт говорит о том же.

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

#books@ergonomic_code

Привет!

Эх. А вот взять бы Clojure, ClojureScript, Datomic, htmx и hiccup - и тогда ВООБЩЕ ВЕСЬ проект можно сделать на ОДНОМ ЯЗЫКЕ. Фактически в одном процессе. Как будто десктопное приложение пишешь...

#clojure@ergonomic_code

Привет!

Готовность два часа - все готово к эфиру

Даже провод дотянул

Привет!

Так, ну большая веха пройдена, расскажу про свои ближайшие планы.

И главный ближайший план - отдохнуть. До марта.
У меня с июля идёт жёсткий спринт, где я жонглирую домом с младенцем и старшим ребёнком, который за 3 месяца сходил в сад 7 дней, выступлением и проектом Р, где дикая жопа тянется с июня.

Но перед тем как начать уже отдыхать я планирую:
1. На следующей недели съездить на оффлайн часть конфы и сделать там лайтенинг толк с кратким пересказом изначального доклада про Spring Data JDBC
2. Допричёсывать и скинуть ссылки на демо проекты для доклада про SDJ
3. Выбрать и опубликовать тестовые прогоны всех трёх докладов: оригинальной полной версии доклада про SDJ, финального доклада про структурный дизайн и лайтенинг толка про SDJ
4. Протегать все свои посты и сделать "домшнюю страницу" со ссылками на тематические подборки
5. У меня есть предвfрительная договорённость зайти в гости к @javaswag - надеюсь там ещё лицом поторгую

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

Вот такие дела, стейтюнед, мы найдём способ делать системы так, чтобы работать было по кайфу:)