Привет!

Существенно дополнил и отполировал пост про интрефейсы и абстракции и пульнул его на хабр - можно ещё раз перечитать:)
И как обычно, буду благодарен за лайки, репосты и комменты:)

#posts@ergonomic_code #design@ergonomic_code #ergo_approach@ergonomic_code

Привет!

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

У них там тоже граф, но однородный - и операции и ресурсы представленны одинаково, плюс ещё есть понятие артефакта (выводимые данные). А вот связи между ними характеризуются 16-ю аспектами.

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

#papers@ergonomic_code #design@ergonomic_code

Привет!

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

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

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

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

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

#talks@ergonomic_code #design@ergonomic_code

Привет!

Проживаю очередной кризис нигилизма:
1) ООП - нахер, эта фигня никогда не работала для информационных систем
2) ООД - нахер, эта фигня не масштабируется ([1], [2])
3) DDD - нахер, таш самая дичь, что и микросервисы - нужно и возможно только в 1% проектов, а в остальных - только удоржает разработку и тешит самолюбие разработчиков
4) Сокрытие информации - нахер, в рамках одного проекта над которым работает одна команда (а то и один человек) - это попахивает шизофринией
5) Open-Closed Principle и Dependency Inversion Principle и Чистая архитектура - нахер (пока реализация одна), эта хрень только усложняет кодовую базу и удорожает разработку
6) Low Coupling/High Cohesion - нахер, это какая-то непонятная дичь. На самом деле - тут тоже "пока что-то" или ещё какое-то условие, но вот что за условие - я ещё не понял.
7) Information Expert - нахер, эта фигня не масштабируется

А что не нахер?
1) DRY - это то, что позволяет снизить стоимость (гемморой для разработчика) внесения изменений
2) KISS - это то, что позволяет снизить стоимость (гемморой для разработчика) внесения изменений
3) Отсутствие циклов в зависимостях - это первое средство борьбы с Big Ball of Mud (упращения кодовой базы)
4) Неизменяемя модель данных - второе средство борьбы с Big Ball of Mud (упращения кодовой базы)
5) Структурный дизайн/функциональная архитектура - третье средство борьбы с Big Ball of Mud (упращения кодовой базы)
6) Единство уровня абстракции/SRP - четвёртое средство борьбы с Big Ball of Mud (упращения кодовой базы)
7) Очевидность связей (сцепленности?)/локальность рассуждений о коде - пятое средство борьбы с Big Ball of Mud (упращения кодовой базы)
8) Классическая школа ТДД - единственное (известное мне) надёжное средство борьбы с регрессиями -> возможность свободно улучашть качество кодовой базы
9) Базовая модель информационных систем в виде операций, ресурсов и эффектов - это то, чем информационные системы являются по своей сути

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

P.s.

1) добротный и двольно свежий пост с обзором и сравнением основных архитектур
2) И в дополнение - более подробный разбор вертикальной архитектуры

#ergo_approach@ergonomic_code #oop@ergonomic_code #ddd@ergonomic_code #design@ergonomic_code

Привет!

В продолжение вчерашнего топика очень крутой доклад от Кента Бека про coupling и cohesion.

В докалде Бек утверждает, что в оригинальной книге сцепленность оценивается относительно некоторого изменения (хотя я сам такого не помню и в книге найти не смог).

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

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

—

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

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

—

Ну и наконец книга - Tidy First?: A Personal Exercise in Empirical Software Design - добавлю в свой список на прочтение

#talks@ergonomic_code #design@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code

И вот ещё хороший доклад про Coupling.

Там же, внезапно, мужик говорит про тот самый Connascence и объёдиняет его с классическим Coupling в ещё более современный Integration Strength. Ток эту штуку тексту нагуглить не получается.

И так же говорит про "расстояние" в коде.

#talks@ergonomic_code #design@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code

Привет!

Посмотрел Build Abstractions Not Illusions.

Любопытная мысль оттуда:
> лёгкий тест на то, является ли абстракцией то, что вы сделали:
Абстракция должна вводить новую терминологию.

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

#talks@ergonomic_code #design@ergonomic_code

Привет!

Я ещё почти два года назад назад начал думать в сторону того, что пути эндпоинтов REST/JSON-over-HTTP API надо нарезать исходя из UX-клиентов, а не сущностей/ресурсов.

То есть, допустим, у нас есть пользователи и три эндпоинта:
1. Залогиниться
2. Посмотреть собвтенные данные
3. Посмотреть данные любого юзера для админов

И раньше я делал сам и наблюдал буквально во всех проектах, которые видел, эти эндпоинты замапили бы на:
1. POST /users/login
2. GET /users/profile
3. GET /users/profiles/{id}

А сейчас я бы это зампаил так:
1. POST /public/login
2. GET /user/profile
3. GET /admin/profiles/{id}

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

И, например, в TA я это так и сделал - если не считать вспомогательных пакетов infra и platform, в пакте app два подпакета:

1. public - "приложение"-точка входа, для регистрации и логина (по историческим причинам мапится на "/"...)
2. therapist - "приложение"-АРМ терапевта (мапится на "/therapist/")

Ещё есть "приложение"-сисадмина - Spring Boot Actuator (мапится на "/ops/**")

Такая схема, среди прочего ещё и существенно упрощает конфигурацию авторизации

Но это всё была прелюдия.

Я тут наткнулся на оригинальный пост про гексагональную архитектуру (ака порты и адаптеры), а там:

What exactly a port is and isn’t is largely a matter of taste. At the one extreme, every use case could be given its own port, producing hundreds of ports for many applications. Alternatively, one could imagine merging all primary ports and all secondary ports so there are only two ports, a left side and a right side.

Neither extreme appears optimal.

The weather system described in the Known Uses has four natural ports: the weather feed, the administrator, the notified subscribers, the subscriber database. A coffee machine controller has four natural ports: the user, the database containing the recipes and prices, the dispensers, and the coin box. A hospital medication system might have three: one for the nurse, one for the prescription database, and one for the computer-controller medication dispensers.

It doesn’t appear that there is any particular damage in choosing the “wrong” number of ports, so that remains a matter of intuition. My selection tends to favor a small number, two, three or four ports, as described above and in the Known Uses.

Что именно является портом, а что нет, во многом является делом вкуса. С одной стороны, каждому юз-кейсу можно было бы присвоить свой собственный порт, создав сотни портов для множества приложений. В качестве альтернативы, можно было бы объединить все основные и все дополнительные порты, чтобы было только два порта, левый и правый.

Ни один из крайних вариантов не кажется оптимальным.

Система прогнозирования погоды, описанная в "Известных вариантах использования", имеет четыре естественных порта: канал прогноза погоды, администратор, уведомленные подписчики, база данных подписчиков. Контроллер кофемашины имеет четыре естественных порта: пользователь, база данных, содержащая рецепты и цены, дозаторы и ящик для монет. Больничная система выдачи лекарств может состоять из трех компонентов: один для медсестры, один для базы данных рецептов и один для диспенсеров лекарств с компьютерным управлением.

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

И я в этом тексте вижу те же самые приложения (в "левых"/основных портах у Кокбёрна), что и у себя.

В общем советую подумать в сторону того, сколько UX-ов есть у ваших (монолитных) бакендов и отражено ли это в вашей архитектуре

#design@ergonomic_code #rest_api@ergonomic_code #hexagonal_architecture@ergonomic_code #trainer_advisor@ergonomic_code

Привет!

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

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

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

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

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

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

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

#design@ergo_approach

Привет!

С наступившим новым годом!

Принципы программирования от разработчика HTMX - Prefer if statements to polymorpism

Особенно понравилось:

It states that a high-level module can depend on a low-level module, because that’s how software works.

Сразу видно - человек давно в индустрии:)

#posts@ergonomic_code #design@ergonomic_code #htmx@ergonomic_code