Привет!

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

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

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

В общем за кулисами работа кипит, стей тюнед:)

Привет!

Играюсь тут в MapStruct+kotlin
сначала застрелился выяснять, что у меня процессинг аннотаций не работет, потому что я скопипасти приме для джавы, а не котлина и написал annotationProcessor, вместо kapt.

Потом когда наконец всё это добро завёл тут же словил нарушение LSP в стандартной либе Котлина и дикий ВТФ с императивным стилем мапструкта

В Котлине emptyList() возвращает объект, который имплементит List, но не имплементит clear().
Ну это типа в целом можно понять, империтивное наследие джавы совместимость с джавой, все дела

но вот то, что мапструк работает через clear+addAll - меня сначала вырубило. я бы тупо перетащил ссылку из исходника в таргет. А потом до меня дошло, что с изменяемыми структурами так нельзя - вдруг ссылка на целевой лист куда-то утекла и уже у того человека будет ВТФ, когда у него "один и тот же объект" не совпадут.

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

пойду ещё покапаюсь, может это можно как-то захачить

#tools@ergonomic_code #kotlin@ergonomic_code

Привет!

Микропост "Как сделать функциональную архитектуру?"

1) Берём чистую архитектуру (считаем, что это очевидно)
2) Перечитываем книгу и убеждаемся, что у нас:
2.1) Entity - это объект, который включает небольшое количество бизенс-правил (а не полей) (An Entity is an object within our computer system that embodies a small set of critical business rules operating on Critical Business Data)
2.2) Use Case - только лишь управляет потоком данных между сущностей (These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to achieve the goals of the use case)
3) Накладываем на сущности ограничение, что они реализуются чистыми функциями и неизменяемым структурами данных
4) Называем сущности функциональным ядром
5) Всё остальное называем императивной оболочкой.
6) Функциональная архитектура готова

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

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

#posts@ergonomic_code #functional_architecture@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Вес взят! Нас теперь 201:) На всякий случай зафиксирую, чтобы не получилось как в прошлый раз:)

Заодно пара ссылок на избитые темы.

Анкл Боб не исопльзует моки
Ещё мужик против IAbstraction
А вот альтернативное мнение на счёт интерфейсов

#posts@ergonomic_code #ergo_approach@ergonomic_code

И ещё мысль в слух: разделение бизнес-логики и ввода-вывода - это тоже следование SRP, которое повышает потенциал переиспользование и того и другого

Привет!

Моему маленькому, но гордому индивидуальному предприятию сегодня исполняется 5 лет!:)

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

Привет!

Я сейчас ковыряюсь с легаси проектом, и мне второй месяц не даёт покоя то, что оригинальные авторы запилили RPC over RabbitMQ.

Накатал микропост с разбором этого подхода.

За одно апдейт по статусу постов - написал первый черновик поста "Эргономичный подход к ООП и ООД", который станет обоснованием к посту с методикой декомпозиции на базе диаграммы эффектов.

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

#project_e@ergonomic_code #case@ergonomic_code

Привет!

Линко-пост

Прикольный "научпопный" доклад для задро... нердов с версией о том, почему ООП стало мейнстримом, а ФП - (пока) нет. Спойлер - случайно и не на всегда:)

Только мужик говорит быстро и слушать сложно:(

Поэтому вот ещё ссылка из доклада на тему ОО/П.

Ну а для совсем ленивых, мой главный инсайт из этой статьи:
> Alan Kay was interested in personal computing. His work on FLEX, the Dynabook, and Smalltalk all revolve around that. In his vision, the PC would be a something totally under the user’s control, everything from core system logic to the graphic rendering tweakable and explorable at runtime. Message passing and late binding solve a lot of problems here. If a kid installs a new game, should they have to recompile the entire OS to use the new program? No: make it so that you can send any arbitrary message to any object and rely on runtime protocol-handling to fix it.1 If a person clobbers the sound logic, should the whole OS crash? Of course not, so allow objects to decide how to handle messages themselves. This is a place where objects shine.

Ole-Johan Dahl and Kristen Nygaard were trying to solve a completely different problem. They were interested in simulation. One of the case studies in the Simula manual is modeling the spread of infection across a fixed population. The system is completely closed: you have a fixed set of code, you run your simulation, you get your output. For them, message passing isn’t useful. But things like being able to define simulations in terms of other simulations, specialize entities, and model time as a first-class object are incredibly useful. This is also a place where objects shine!

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

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

#talks@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code

Привет!

Продолжаю в фоне размышлять о том является ли RPC over RabbitMQ антипаттерном, нагенерял ещё пару мыслей, делюсь.

Нетиповое решение
Я сейчас читаю Building Microservices (кстати, очень крутая книга - в первой же главе пишет что МС это боль и надо начинать с монолита) и там типовым решением для синхронного стиля пишут HTTP/RPC (картинка)

Стримминг
В рамках работы над этим чудо проектом в один момент показалось, что мне нужен стриминг большого объёма данных из одного МС в другой. В итоге обошлось но если бы не обошлось, то на HTTP я бы это без вопросов сделал, а с очередью бы ой вышел

Разделение АПИ
Ещё подумал, что плюсом такого решения является явное разделение АПИ на публичное и приватное. Но на HTTP это тоже можно провернуть (сам не пробовал)

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

#case@ergonomic_code

Привет!

Выкинул "первый черновик" (который был на самом деле первой доведённой до конца попыткой) поста с обоснованием декомпозиции на базе диаграммы эффектов.

Написал очередную версию и, кажется (хоть бы, хоть бы) в этот раз наконец успех.

Заодно находка-любопытка. Вы читали Чистый код анкл Боба? В частности раздел "Антисимметрия данных/объектов"?

Там любопытное написано:
> Процедурный код (код, использующий структуры данных) позволяет легко добавлять новые функции без изменения существующих структур данных. Объектно-ориентированный код, напротив, упрощает добавление новых классов без изменения существующих функций.

В любой сложной системе возникают ситуации, когда вместо новых функций в систему требуется включить новые типы данных. Для таких ситуаций объекты и объектно-ориентированное программирование особенно уместны. Впрочем, бывает и обратное — вместо новых типов данных требуется добавить новые функции. Тогда лучше подходит процедурный код и структуры данных.

Вам не кажется, что в информационных системах чаще требуется добавлять новые функции, чем (варианты) типов данных?

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

#oop@ergonomic_code #dop@ergonomic_code

Привет!

А вот и Фаулер советует стартовать с монолита

Из статьи достаточно прочитать две фразы:
1) Almost all the successful microservice stories have started with a monolith that got too big and was broken up
2) Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

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

#posts@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

Прочитал Building Microservices: Designing Fine-Grained Systems - редкая книга, с содержанием которой я согласен без всяких но, рекомендую:)

#books@ergonomic_code

Привет!

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

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

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

Привет!

Свинья везде найдёт грязь, а я - в любой книжке по ООП агитацию за ФП.

В рамках подготовки поста об ОО декомпозиции полез кое-чего глянуть в Object-Oriented Software Construction. И пока искал, наткнулся на раздел "23.1 SIDE EFFECTS IN FUNCTIONS". Там достаточно хорошо описано что такое побочный эффект, чем он опасен и как отделять чистые функции от функций с эффектом (это тот самый CQS, если вы понимаете о чём я).

И вообще в этой книге много мудрости, например OCP анкл Боб взял оттуда (хотя и подменил суть, по большому счёту).

Единственное что, Мейер там сильно заблуждается на счёт значимости и практики применения механизма наследования, но это всеобщее помутнение сознания тех лет (конца 80-ых) и вполне простительно.

В общем рекомендую почитать на досуге.

#books@ergonomic_code #whyfp@ergonomic_code #oop@ergonomic_code

Привет!

Опубликовал пост о подходах к декомпозиции

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

Привет!

Наткунлся на обновлённую версию доклада Simple Made Ease с русскими субтитрами.
Доклад очень крутой, советую посмотреть, тем кто ещё не смотрел

#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code

Привет!

Зацените чё накапал я ненавижу и работать с АПИ в виде сваггера (оно почти всегда не работает полностью) и уш тем более писать его - пихать в код гору аннотаций для доков к сваггеру, где соотношение сигнал шут 1 к 2 - то ещё удовольствие.

И сам я предпочитаю писать доки на Spring Rest Docs - и собственно текст доков можно нормально писать, и примеры гарантированно рабочие. Но многие привыкли таки к сваггеру и хотят его. А с этим тулом, кажется, можно разом обоих зайцев убить.

#docs@ergonomic_code #spring@ergonomic_code #http_api@ergonomic_code #rest_api@ergonomic_code

Привет!

Довольно часто встречаю у студентов и молодых разработчиков ошибку добавления ИД в таблицу связку: user_roles(id, user_id, role_id).
Раньше я в таких случаях из чисто на основе интуиции говорил "лучше убрать и заменить на составной ключ, потому что ИД нафик не нужен и чуть лишней памяти жрёт".

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

#posts@ergonomic_code #relational_model@ergonomic_code