Привет!

Надоело мне мурыжить пост о построении диаграммы реального проекта, поэтому я волевым усилием его быстренько добил и с радостью представляю вашему вниманию:)

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

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

#effects_diagram@ergonomic_code #case@ergonomic_code #project_geoservices@ergonomic_code #posts@ergonomic_code

Привет!

Пульнул на хабр пост о построении диаграммы эффектов
Как всегда буду благодарен за лайки, карму, комменты и репосты:)

Привет!

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

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

Тем не менее, советую ознакомиться с первоисточником:)

#papers@ergonomic_code #structured_design@ergonomic_code

Привет!

К вопросу о чтении переведённых книг.

Занесла меня тут нелёгкая снова в "Чистую архитектуру". В оригинале там есть такой текст:
The issues we have discussed so far lead to an inescapable conclusion: The component structure cannot be designed from the top down. It is not one of the first things about the system that is designed, but rather evolves as the system grows andchanges.

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

И даже яндекс-переводчик переводит примерно так же.

А потом ещё более нелёгкая занесла мена почитать этот же кусочек в русской версии. Там написано следующее:
Проблемы, что мы обсудили к данному моменту, ведут к однозначному заключению: структура компонентов не может проектироваться сверху вниз. К этому выводу приходят не сразу, как только начинают проектировать систему, но это неизбежно случается с ростом и изменением системы.

К этому выводу приходят не сразу, как только начинают проектировать
Что? Откуда это вообще??? Во втором предложении вообще нет слов "вывод" и "приходить". Куда делось слово evolves? И кто приходит к этому выводу?
Тут фатально искажена суть - я русскую версию читаю как то, что разработчики приходят к выводу о том, что "структура компонентов не может проектироваться сверху вниз" не сразу, как только начинают проектировать систему, а по мере роста и изменения системы.

Судя по этому отрывку, переводчик плохо знает грамматику английского языка. Либо вообще, книгу перевели в Prompt-е из 90 (потому что современные переводчики лучше справляются с этой работй), а потом редактор-гуманитарий её причесал как смог.

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

Привет!

У меня тут мега инсайт. Я лет 8 назад разочаровался в ООП и с тех пор говорил, что это облажавшая хрень, которая, на самом деле не захватила мир и миром всё ещё правит ПП.

При этом я верю в ООД. Когда-нибудь я напишу пост, в чём для меня разница, но если вкратце, для меня ООП - это классы, а ООД - подсистемы

Поэтому я время от времени читаю книги по ООП/ООД и сейчас читаю Designing object-oriented software.

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

Applying UML and Patterns - автоматизация кассы

Object Oriented Software Construction - система резирвации авиа билетов с фокусом на UI, undo в интерактивной систему

Object-Oriented Software Engineering: A Use Case Driven Approach - система управления складом с фокусом на UI, телеком

Object Design: Roles, Responsibilities, and Collaborations - система общения парализованных людей, по средствам моргания глазами

Object-Oriented Analysis and Design with Applications - спутниковая навигация, система управления трафиком, криптоанализ, наблюдение за погодой, система управления отпусками (вот кажись единственный похожий пример)

Working with objects: The OOram Software Engineering Method - "business information system" но на беглый взгляд, фокус всё равно на UI, система реального времени, фреймворк

The Object-Oriented Thought Process - игра в 21

Head First Object-Oriented Analysis and Design - информационная система магазина гитар, но на списках:(

Львиная доля примеров - сильно отличаются от того, с чем работаю я. Там либо высокоинтерактивная система, либо активная работа с оборудованием, либо UI.

Так что, наверное, для ООП есть место в мире, просто не моём:)

А для разработки информационных систем я советую:
1) следовать ООД при декомпозиции системы на подсистемы - каждая подсистема должна инкапсулировать в себе какую-то часть состояния всей системы, и предоставлять публичное АПИ для его изменения
2) следовать функциональной архитектуре в реализации отдельных подсистем - разбивать код на чистое ядро с бизнес-правилами, и императивную оболочку с вводом- выводом
3) максимум кода тащить в чистое ядро и делать это ядро понастоящему чистым - с неизменяемыми структурами данных и функциями без эффектов
4) а императивную оболочку делать максимально тонкой, прямолинейной и простой

#oop@ergonomic_code #books@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Накатал потока-сознания-пост о том, что я имею ввиду под ОО-подходом.

#terminology@ergonomic_code #oop@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Я тут кажись придумал простое и понятное (по крайней мере мне 😂) определение функциональной связанности метода:)

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

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

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

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

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

Но как тогда реализовать эту функциональность?
Через шину событий. Метод одобрения сохраняет сущность и публикует событие "сущность одобрена".
А дальше в отдельном методе это событие обрабатывается и посылается пуш.

В чем разница между публикацией события и отпрвкой пуша?
Она, на самом деле довольно тонкая.
Но публикация события, на самом деле не разрывно связана с сохранением сущности. Мы можем не реализовывать это в коде, но при всяком сохранении сущности этим методом происходит событие "сущность одобрена".
И если нам важно, чтобы система об этом событии узнавала, то сбой в его публикации является достаточной причиной для сбоя всего метода одобрения в целом.

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

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

#terminology@ergonomic_code #cohesion@ergonomic_code #ergo_approach@ergonomic_code #design

Привет!

Вот ещё мужик придумал эргономичный подход, только не знает об этом:)

Пост полон мудрости, настоятельно рекомендую:)

#posts@ergonomic_code #ergo_approach@ergonomic_code

Привет

Сегодня у нас рубрика "Мои факапы".

Есть у меня один проект, где флоу создания одной из сущностей такой:
1) непривилегированный пользователь создаёт сущность
2) привилегированный пользователь её одобряет или отклоняет

ну и плюс привилегированный пользователь может её редактировать в любой момент.

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

В итоге сейчас у нас есть метод PATCH /entity/{id}
который принимает сущность с 15 нуллабельными полями. используется двумя способами - либо присылаются все 15, либо 1 - approved

И есть метод POST /entity
С теми же 15 полями. но не нуллабельными.

И хз что с этим добром теперь делать.

Щяс я уже думаю, что надо было не выпендриваться, обновление делать через PUT, а аппрув через PATCH /entity/{id}/approved или POST /entity/{id}/(approve|reject)

А от PATCH-а сущностей держаться подальше до тех пор, пока требования к стенке не припрут - в языках со статической типизацией это боль

И заодно наткнулся на прикольную штуку JSON-P - когда мне придётся в следующий раз делать патч, я так пойду, а не через типизированную нуллабельную ДТОшку

#case@ergonomic_code #project_camp@ergonomic_code #http_api@ergonomic_code #rest_api@ergonomic_code #tools@ergonomic_code

Привет!

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

#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

Привет!

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

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