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

Привет!

Реклама

Как сервисам взаимодействовать между собой надёжно, быстро и понятно?

REST, gRPC, события, контракты, версии — деталей много, а универсальных решений нет.

На онлайн-конференции Podlodka Techlead Crew (7–11 апреля) разберёмся, как выстраивать межсервисное взаимодействие: от проектирования API до публикации событий и сравнения протоколов.

В программе:

🎯 Event Storming + DDD: проектируем EDA правильно — Кирилл Ветчинкин расскажет, как выделять правильные события, избавляться от синхронных вызовов и строить событийно-ориентированные системы без боли

🔄 Обратная совместимость в парадигме specification-first — Сергей Константинов покажет, как поддерживать REST API и работать со спецификациями типа OpenAPI

🎙Интервью: Проектируем API — contract first — Илья Зонов поделится, когда этот подход спасает, а когда мешает. И как версионировать API без боли

⚔️ gRPC vs RESTful: битва протоколов — Алексей Романов сравнит два подхода по 10 критериям

Готовы прокачаться?

Билеты здесь🎟

Привет!

#project_r подходит к концу и я ищу для себя новый проект по разработке веб-приложения, веб-сервиса или бакэнда мобильного приложения на JVM-стеке (Kotlin, Java).

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

Рассматриваю варианты работы по договору с ИП, договору ГПХ и трудовому договору.

Если вам или кому из ваших знакомых нужен хорошо сделанный бакэнд - приходите в личку, пожалуйста:)

Буду благодарен за репост.

Привет!

Прочитал субстак про Radical Object-Orientation (автор его ещё дописывает)

Имхо - Эргономичная архитектура, только в профиль.

- PoMO - очень напоминает то, что у меня ресурс может быть включен только в один другой ресурс
- IOSP - очень напоминает сбалансированную форму системы
- У него тоже дизайн рекурсивен - атомарная операция ио с точки зрения оркестрации сама может оказаться оркестрацией на своём уровне абстракции
- Так же придерживатеся мнения, что абстракция != public interface - "Integrations are abstractions as well."
- Но у автора всё, включая интеграции - есть объект. У меня, по крайней мере синтаксически, объектами (штуками эксклюзивно владеющими собственными состоянием) являются только ресурсы, а операции - это скрипты которые заимствуют состояние ресурсов и тем самым разделяют его между собой. Но. Всё приложение в целом - можно считать объектом.

Из минусов:
- (Относительно) многа букаф и картинок и очень мало кода, а тот что есть - тривиальный и про консольные приложения
- Аналогия с клетками привлекательная, но не очень... Клетки действительно организуют очень крутые, сложные и адаптивные системы. Которые человечество за миллион человеко-часов понять не может - хотим ли мы поддерживать такие системы?
- А ещё я в #project_r@ergonomic_code опять (но теперь под другим углом) начал сталкиваться с тем, что инкапсуляция состояния плохо масштабируется, так как влечёт неограниченный рост поверхности АПИ ключевых/центральных/фундаментальных объектов-ресусров.

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

#posts@ergonomic_code #ergo_approach@ergonomic_code #oop@ergonomic_code

Привет!

Докинул на вики рыбу статьи с ещё одним костылём для SDJ - как быть, если хочется сослаться на некорневую сущность агрегата.

#ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code #ergowiki@ergonomic_code

Привет!

Мне тут на Хабре заминусили коммент про отказ от моков в пользу интеграционного тестирования.
В ответ на это я собрался мокистам ответить подборкой цитат классиков и экспертов по ТДД о моках и оказалось, что у меня её нет.

Теперь есть:)

Берите себе на вооружение, в своей борьбе за простое девелоперское счастье и здоровый ночной сон:)

#posts@ergonomic_code #whynomocks@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Зацените какую либульку для тестов накопал - кажется может быть заменой моих ObjectMother-ов.
Сам ещё не пробовал

Привет!

Я тут в рамках выбора новой либы для работы с БД решил посмотреть на график контрибьюторов за предыдущий квартал на GitHub-е для основных проектов и там есть несколько любопытных находок:)

1. С диким отрывом лидирует Hibernate - 743 коммита от 4 активных контрибьюторов за октябрь-декабрь 2024 года. Любопытно, что в 21-ом году начал активно коммитать Гэвин Кинг
2. Далее идёт Jimmer - 229 коммита от 3ёх активных контрибьюторов. И там даже есть пара коммитов по строке с фиксом опечаток от Владимира Ситникова:)
3. Почётное 3-е место достаётся jooq-у, где невероятно плодовитый Лукас Эдер в одно лицо нагенерял 196 коммитов
4. MyBatis - 169 коммитов от двух контрибьюторов
5. На пятом месте с большим отрывом от лидеров идёт Exposed c 73 коммитами от 3ёх контрибьюторов
6. Формально, со 135 коммитами пятым должен идти komapper, однако из них 73 - от renovate[bot], поэтому считаем что в этом проекте 57 коммитов от одного контрибьютора
7. По большому счёту делят 7ое место Ebean (42/1), Spring Data Relational (39/2) и JDBI (39/2)
8. На восьмом месте оказались то ли достигшие совершенства, то ли мёртвые QueryDSL и ktorm с 0 коммитов

Я не предлагаю делать каких-то далеко идущих выводов (я даже допускаю, что QueryDSL на самом деле достиг совершенства) - просто немного статпорно вам в утреннюю ленту:)

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

Привет!

У нас сегодня праздник: ровно - я подгадал - 5 лет назад, в 11:03 22 февраля 2020 года я нарисовал эту картинку и начал работу над Эргономичным подходом.

За эти годы Эргономичный подход многое потерял (в основном функциональный вайб и юношеский максимализм) и многое нашёл (в основном конкретные инструменты и боевые шрамы) и я хочу отметить этот день небольшой ретроспективой Эргономичного подхода.

Привет!

Ток что впервые за 4 года пришлось запилить руками dirty checking в SDJ...

Хотел написать я.
Но уже буквально коммитаясь я в последний момент одуплил, что я поломал основную идею ДДД, SDJ и эргономичного персистанса - у меня одна сущность оказалось частью двух агрегатов.

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

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

5-ый кризис ЭП пролетел буквально за часик:)

Хотел написать я.
А потом упёрся в то, что есть ещё одна сущность, которую я сделал частью нескольких агрегатов одного типа...

А если учесть, что эта сущность в перспективе будет контрибьютить в инварианты этого типа агрегатов - Проект Р, кажись, не у ЭП, а у ДДД трубу зашатал...

#project_r@ergonomic_code #ddd@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code

Остальные три четверти:
1. Всякая обвязка типа введения/заключения
2. аналогичная штука для архитектуры кодовой базы тестов (тут в целом тоже львиная доля готова, плюс туда надо вписать ещё одну находку из Проекта Р - пресеты фикстур тестов, для сетапа сложных графов)
3. Вымышленная история реализации Trainer Advisor с иллюстрацией теоретических идей и процесса.

Вот такие дела:)

Привет!

Периодически гипотезы, лежащие в основе ЭП, рушатся о жестокую реальность промышленной разработки, что приводит к кризисам ЭП, которых уже было три штуки: раз по мотивам проекта Barcoder (решение), два (решение) и три (решение - нафик ООД, ДДД и private внутри одного репоза😀) - по мотивам #project_e.

И вот по мотивам #project_r за последние 5 дней у меня случился и благополучно разрешился очередной кризис ЭП:)

В связи с чем у меня пачка новостей.

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

Отказ от ФА
Номинально самая большая новость - я решил отказаться от ФА (которая когда-то была одним из трёх столпов ЭП).
Но по сути ничего не меняется - ЭП всё так же предполагает использование неизменяемых структур данных и максимально возможное разделение логики и ио.
Это просто признание реальности, что в ЭП, который начинался как сильно функциональный, я методично отказываюсь от отличительных черт ФА/ФП:
1. уже очень давно я отказался от монад и ROP-а в пользу защитных условий
2. затем я затащил операции в императивную оболочку
3. во многом по мотивам Проекта Р я вернул в милость выброс исключений вместо возвращения Result
4. по мотивам Проекта Р, я утащил сбалансированную форму системы с архитектурного уровня системы, на локальный уровень отдельных методов

Отказ от SDJ как дефолтной технологии работы с БД
А вот по сути самое больше изменение - я решил отказаться от SDJ в качестве дефолта для работы с БД.
Это всё ёще допустимый в рамках ЭП т.к. его всё ещё легче "продать" заказчикам и коллегам, но по умолчанию я теперь предлагаю использовать какой-то легковесный DSL - jooq или Exposed, ещё не решил что именно.

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

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

1. проекция структуры данных (модель данных) - тут про агрегаты и связи между ними
2. проекция состояния (объектная модель) - тут про объекты в рантайме (порты, операции, ресурсы) и связи между ними
3. проекция структуры поведения (процедурная модель) - тут про методы и связи между ними

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

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

И возвращаясь к книге - эта статья по сути - четверть книги. Заполнить там пробелы, добавить примеры и теоретическая часть по ЭА готова. Вспоминая про бейзкамповский Hill Chart, у меня сейчас такое ощущение, что я достиг холма реализации ЭА и дальше только дело техники. Лишь бы очередной проект не зафейлил очередную гипотезу 😄

#the_book@ergonomic_code #functional_architecture@ergonomic_code #ergo_arch@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code

Привет!

Добавил на вики пару заглушек паттернов тестирования:
1. Тестирование генерации xlsx-документов с помощью Apache POI
2. Используйте фейковый кодировщик паролей

#ergo_testing@ergonomic_code #ergowiki@ergonomic_code

Привет!

С подачи в комментариях к посту про DIP прочитал Stratified Design over Layered Design - на мой вкус прикольный, любопытный и полезный пост об абстракции.

Который оказался кроличьей норой.

Там дальше есть ссылка на IODA Architecture от того же мужика- штуку, которая сильно перекликается с моей Эргономичной архитектурой.

А если это погуглить её, то можно найти ещё один более свежий пост, где в конце всё тот же чувак предлагает ещё и Sleepy Hollow Architecture

А если ещё посмотреть на его блог - там ещё куча любопытный заголовков постов, в том числе что-то про Radical Object-Orientation, о чём у него есть отдельный сабстак.

А если погуглить самого чувака, то можно накопать и Clean Code Developer.

В общем советую почитать как минимум посты из этого поста и в целом покапаться в творчестве Ralf Westphals - у него явно есть чему поучиться.

#posts@ergonomic_code

Привет!

Прочитал Shape Up.

Книга о том, как устроен процесс разработки в Basecamp - контора, которая наиболее известна созданием Ruby on Rails.

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

Во-вторых, там есть несколько прикольных идей, про которые просто прикольно знать:)

Общий процесс у них такой:
1. есть два трэка - шейпинг и билдинг
2. на треке шейпинга они прорабатывают концепт проекта, на среднем уровне детализации - без детального проектирования, но так чтобы снять основные неизвестные и ограничить скоуп, чтобы создать ощущение, что проект впишется в цикл билдинга
3. шейпинг не ограничен по времени, потому что он как раз таки исследует "кроличьи норы" проекта
4. Цикл билдинга строго 6 недель. Если за 6 недель проект не выпустили в прод - по дефолту он отменяется совсем.
5. Между циклами билдинга есть 2 недели охлаждения, когда все выдыхают, подчищают хвосты, делают что сами считают важным и живут без дедлайна

Прикольные идеи:
Breadboarding - способ описания концепта проекта. Состоит из элементов - мест (places - страницы, модалки и т.д.), возможностей (affordance - кнопки, ссылки, динамические тексты) и связей (connection lines - в какое место ведёт возможность).

Я раньше на вход к проектированию бэка требовал макеты UI. Мне в ответ говорили "Ты дебил? Нафига тебе макеты для проектирования бэка?". На что я отвечал "А у вас требования такие, что по ним хрен разберёшь что конкретно надо сделать". В следующий раз надо будет попробовать такую штуку

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

Они себе в бейзкампе (я так понимаю что-то аля джиры) запили эти самые хил чарты и отслеживают статус проекта по ним.

Любопытный факт - у них на компанию с "миллионами пользователей и дюженой человек в производственной команде" только 1 QA-инженер, который занимается граничными случаями. Базовый уровень качества обеспечивает производственная команда, в том числе тестами.

#books@ergonomic_code

Привет!

Опубликовал Вам не нужна Чистая архитектура. Скорее всего 🎉

#posts@ergonomic_code #solid@ergonomic_code #clean_architecture@ergonomic_code #functional_architecture @ergonomic_code

Привет!

Мысли в слух по теме прошлого поста.

Кажется, строительство сооружений и классическое "инженерное дело" — это не верный ориентир для разработки софта.
Как не крути, но в этих областях ТЗ фиксированное — мост и через 10 лет будет выполнять туже функцию и глобально не изменится. А условный айфон - вообще не изменится, если останется жив. А айфон 10 — это уже будет десятый проект с фиксированным ТЗ.

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

Ещё более-менее похожая штука - "строительство" городов - города тоже живут долго и сильно меняются.

Других видов деятельности, по "выращиванию" одной сущности в течении длительного срока в меняющихся условиях я пока не придумал.

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

Привет!

Прочитал The Problem with Software: Why Smart Engineers Write Bad Code - не однозначная книга.

С одной стороны - я не понимаю для кого она и зачем.

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

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

С другой стороны книга написана хорошо и я с интересом её читал.

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

Мой текущий пост (который уже на стадии финальной полировки) очень хорошо иллюстрирует посыл этой книги - в нём есть такие строки:

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

[...]

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

То бишь сначала анкл Боб бездоказательно заявляет, что в системах будут появляться новые устройства, а потом я так же бездоказательно заявляю, что не будут. Твоё слово против моего, встретимся в суде. Так и живут "инженеры" от современного ИТ...:)

#books@ergonomic_code

Привет!

Наконец-то опубликовали официальную запись моего доклада "Структурный дизайн. Древний секрет простого и быстрого кода" с Joker '24 ! 🎉🎉🎉

#talks@ergonomic_code #ergo_approach@ergonomic_code #functional_architecture@ergonomic_code #structured_design@ergonomic_code

Привет!

Или я что-то не понимаю, или в Чистой архитектуре есть дыра.

Во-первых, у нас есть правило зависимостей: Зависимости исходного кода должны указывать только внутрь, на политики более высокого уровня.

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

А в третьих, есть адаптеры интерфейсов, про которые анкл Боб пишет: "Никакой код, находящийся внутри этого круга, вообще ничего не должен знать о базе данных. Если база данных является базой данных SQL, то весь SQL должен быть ограничен этим уровнем и, в частности, теми частями этого уровня, которые имеют отношение к базе данных."

То есть, получается, что слой адаптеров должен знать про БД, которая находится уровнем выше и нарушать правило зависимостей?

Что как бы намекает "что модули верхнего уровня могут зависеть от модулей нижнего уровня, потому что это то, как работает софт" 🤔

#clean_architecture@ergonomic_code

Но большую часть прошедшей недели "отпуска" я посвятил этому посту:)

Пользуясь отпуском - не буду называть сроки, когда опубликую:)