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

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

@ergonomic_code

Канал о разработке поддерживаемых бакэндов - про классическую школу TDD, прагматичное функциональное программирование и архитектуру и немного DDD.

Группа: https://t.me/+hrqD87p0Oa

Канал в Max: https://max.ru/id544512614458_biz

https://azhidkov.pro
Subscribers
837
Photos
94
Videos
3
Links
436

Showing posts older than #436 · Back to latest

Older Posts 20 shown
Post #435 700
А ещё в Сибирь наконец-то пришло лето:)
  • 🔥 11
Post #434 726
Привет!

Сегодня решил поделиться полезняшкой - git worktree.

Эта команда позволяет добавить рабочую директорию для существующего гит репоза (ещё одну директорию с исходниками без собственной директории .git).

Это позволяет даже для больших проектов иметь пачку "репозов" и быстро переключаться между задачами. У меня как правило для каждого проекта есть пачка рабочих директорий:
1) main - для текущей задачи
2) hot-fix - для хот фиксов
3) по директории на каждого разработчика - для ревью
4) плюс частенько завожу ещё отдельные директории для различных экспериментов с кодовой базой.

#tools@ergonomic_code #git@ergonomic_code
  • 👍 8
Post #433 632
Привет!

Посмотрел интервью с Кокбёрном (мужиком, который придумал Гексагональную архитектуру).

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

И ещё в этом же видосе он порекомендовал сайт о ГА - https://jmgarridopaz.github.io/

#talks@ergonomic_code #guideline@ergonomic_code
YouTube Hexagonal Architecture (Ports and Adapters) with Alistair Cockburn // Live #98 In this live we are going to talk with Alistair Cockburn, an American computer scientist, one of the initiators of the agile movement and the creator of Hexagonal Architecture (also known as Ports and Adapters) Acompanhe nossas redes sociais: ➡️Instagram:…
  • ❤ 3
  • 👍 2
Post #432 773
Post #430 735
Привет!

А вы знали, что оказывается есть стандарт на тела ошибочных JSON-ответов - Problem Details for HTTP APIs и для него в 6-ой Spring завезли поддержку?

#http_api@ergonomic_code #spring@ergonomic_code #error_handling@ergonomic_code
IETF Datatracker RFC 9457: Problem Details for HTTP APIs This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807.
  • 🔥 11
  • 👌 3
Post #429 709
Привет!

Я ещё почти два года назад назад начал думать в сторону того, что пути эндпоинтов 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
Telegram Эргономичный код Привет! Я тут вынашиваю страшный план - отказаться от REST-стиля в "бэке одного фронта". Как я собираюсь это делать: 1) Ядро продолжать так же делать из подсистем-объектов 2) Вокруг ядра сделать слой app, где по конторллеру на каждую страницу/экран/вью…
  • 🔥 4
  • ❤ 3
  • 👍 2
Post #426 834
Эргономичный код Нужна ли миру очередная архитектура?
Удивлён, что вариант "Да" лидирует.

На всякий случай: опрос не про "публиковать ли пост", а про "вводить ли новый термин"

У меня де-факто получается какая-то смесь слоёной и функциональной архитектуры с элементами DDD и диаграммой эффектов
  • ❤ 2
  • 💯 1
Post #425 776
И ещё мысль в тему - такое ощущение, что термин парадигма в научно-философском смысле лучше подходит для обозначения слоёной/чистой/функциональной и т.п. штук.

Определение с вики:
Определённый набор концепций или шаблонов мышления, включая теории, методы исследования, постулаты и стандарты, в соответствии с которыми осуществляются последующие построения, обобщения и эксперименты в области.
  • ❤ 1
Post #424 739
  • ❤ 1
Post #423 745
Привет!

Моя дилемма последней недели.

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

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

Во многом, потому что ФА ни где не описана. Для неё даже на вики странички нет.

#ergo_approach@ergonomic_code #ergo_arch@ergonomic_code
  • ❤ 1
Post #422 691
Привет!

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

Меня в первую очередь интересуют материалы такой же степени детализации/проработки как и Domain Modeling Made Functional, но более "прагматично" - без монад/с примерами на языке не имеющим синтаксической поддержки для них.

Но небольшие посты/презентации тоже скидывайте

#books@ergonomic_code
Pragprog Domain Modeling Made Functional Use domain-driven design to effectively model your business domain, and implement that model with F#.
  • 👍 3
  • ❤ 1
Post #421 688
Привет!

Опубликовал пост с последним кусочком описания сетапа фикстуры Trainer Advisor - сетап тестовых дублей.

В этом посте для полноты картины я добавил бонус-трек с описанием сетапа тестовых дублей для тестирования работы с внешними веб-сервисами, кроликом, кафкой и MQTT-брокером.

И под это дело добавил соответствующий бонус-трек в пост с описанием запуска инфраструктуры.

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code #whynomocks@ergonomic_code
  • ❤ 5
  • 👍 2
Post #420 785
Привет!

Пара баек про JPA. Для молодых разработчиков, в первую очередь.

Мне тут недавно студент сдавал в качестве курсового проекта стартап с живым клиентом в проде. И между делом рассказал душещипательную историю в духе "У нас основное приложение на JPA, но в первый же день в проде оно нам покасячило данные, поэтому админку мы начали делать на jooq, чтобы лучше контролировать работу с БД".

А вчера говорил наоборот с пишущим код СТО c опытом работы с JPA лет 10 минимум и между делом я написал "в какой-то момент мне показалось, что я с JPA освоился и закончу активную разработку на этой недели".

На что получил ответ:

> Ахахаха
это классика
я после задач с JPA никогда не говорю теперь что с ним освоился/разобрался
я его б*ь не знаю, там вечные сюрпризы и темные пятна вылазят

В общем прежде чем брать в проект JPA советую сначала попробовать затолкать в голову собственно саму 662-страничную Jakarta Persistence API Specification :) Перед тем как ещё страниц ~100 рефернсной доки на Spring Data JPA читать. И я уж молчу про 228 страниц спеки на JDBC. Жаль, спека на SQL непубличная - говорят в свежих версиях там 1000 страниц. Кто-нибудь, остановите меня уже:)

#whynotjpa@ergonomic_code #jpa@ergonomic_code
  • 😁 5
  • 🔥 3
  • 🤯 3
  • ❤ 1
  • 👨‍💻 1
Post #419 656
Привет!

Выхожу на финишную прямую очередного кусочка про тестирование ТА (сетап тестовых дублей) и чёрт меня дёрнул посчитать, сколько постов я уже написал.

Оказывается, предыдущий пост был юблиейным - 60-ый:)

У меня есть 27 "больших" постов (на самом деле тут не все посты большие, некоторые в формате микропоста, до тех пор пока я я не вытащил их на отдельную страницу)

Где ещё 26 микропостов (некоторые из которых на 40 минут чтения)

И у меня есть ещё пачка постов в Телеграфе:
1. Стратегия тестирования, которая сработает для большниства проектов
2. RPC over RabbitMQ
3. Чем ОО-подход отличается от ПП-подхода?
4. Kotlin и локальность рассуждений
5. Ленивые вычисления для реализации функциональной архитектуры
6. Тесты, которым можно доверять
7. Kotlin Result DSL

И это не считая спеки диаграммы эффектов. И пары десятков неопубликованных черновиков.

В общем, кажется, по кол-ву слов книгу я уже написал:) Может уже можно сделать сборник постов и опубликовать как книгу - как анкл Боб с Чистой архитектурой сделал?:)

#posts@ergonomic_code #ergo_approach@ergonomic_code
Алексей Жидков Посты - Алексей Жидков Разработка и реинжиниринг ПО
  • 🔥 8
  • ❤ 2
  • 🥰 2
Post #418 715
Привет!

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

Мысль №1
В докладе мужик привёл пару определений:
> Падение юнит-теста подразумевает сбой ровно в одном юните (методе, классе, модуле, пакете)
> Падение девелоперского теста подразумевает ошибку в последнем изменении кода

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

И это прям хорошо легло на мой свежий опыт:
1. В Trainer Advisor у меня примерно 3-4 теста на HTTP-эндпоинт. И ~95% - работают либо через хттп, либо через конторллер
2. А недавно я написал один хттп эндпоинт, с 22 тестами из которых <50% работают через http.

В чём разница? В TA львиная доля эндпоинтов - примитивный КРУД - перегнать ДТО в сущность, сохранить сущность; вычитать ДТО из БД, вернуть - я это пишу спинным мозгом и там граничных случаев ноль целых хрен десятых.

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

В этом и разница.

—

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

—

Мысль №3
Возможно молодые подписчики ещё не сталкивались с http://wiki.c2.com/. Это самая первая вики в мире из 1995 года. От чувака, который придумал гексагональную архитектуру. И в которой в старые добрые времена тусила вся старая гвардия - начиная с самого Кокберна и продолжая анкл Бобом, Фаулером, Беком, Коплейном. Можно выделить вечерок и пошататься по ней впитывая мудрость древних.

—

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

—

Мысль №5
Мужик топит, за то, что код с вводом-выводом надо тестировать как-то по другому, потому что он медленный и хрупкий. И, видимо, раз я решил проблемы скорости и хрупкости такого кода, то мне можно и для него писать нормальные тесты. Можно же?

—

Мысль №6
У мужика в докладе ни строчки кода нет. А у меня есть ~150 "developer tests", которые "tests behaviour, not functions" и для которых процентов на 30 готово описание идей и техник как, такие тесты писать

#talks@ergonomic_code #ergo_testing@ergonomic_code #tdd@ergonomic_code #whynomocks@ergonomic_code
YouTube TDD Revisited - Ian Cooper - NDC Porto 2023 This talk was recorded at NDC Porto in Porto, Portugal. #ndcporto #ndcconferences #testing #tdd #softwaredeveloper Attend the next NDC conference near you: https://ndcconferences.com https://ndcporto.com/ Subscribe to our YouTube channel and learn…
  • 👍 5
  • ❤ 1
Post #417 732
Привет!

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

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

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

#talks@ergonomic_code #design@ergonomic_code
YouTube Build Abstractions Not Illusions • Gregor Hohpe • YOW! 2023 This presentation was recorded at YOW! Australia 2023. #GOTOcon #YOW https://yowcon.com Gregor Hohpe - AWS Senior Principal Evangelist RESOURCES https://twitter.com/ghohpe https://www.linkedin.com/in/ghohpe http://eaipatterns.com https://architectelevator.com…
  • ❤‍🔥 3
  • ❤ 1
Post #416 839
Привет!

Дочитал Code That Fits in Your Head.
И хотя там есть нюансики (использование фейков БД, складирование всего кода в одной директории 🤯🤦‍♂️), автор топит за outside in tdd и функциональную архитектуру - рекомендую. Особенно молодым разработчиком.

Плюс практически одновременно досмотрел доклад Влашина Moving IO to the edges of your app: Functional Core, Imperative Shell - в целом, наверное, ничего прорывного в докладе нет, но если вы (как и я) ещё не уверены, что знаете на 100% как её применять - можно посмотреть. Там примеры на C# и никаких монад.

#books@ergonomic_code #talks@ergonomic_code #functional_architecture@ergonomic_code
YouTube Moving IO to the edges of your app: Functional Core, Imperative Shell - Scott Wlaschin This talk was recorded at NDC London in London, England. #ndclondon #ndcconferences #developer #softwaredeveloper Attend the next NDC conference near you: https://ndcconferences.com https://ndclondon.com/ Subscribe to our YouTube channel and learn…
  • ❤ 5
  • 👍 5
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →