И небольшой микропост по мотивам книги

#functional_architecture@ergonomic_code

Привет!

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

#posts@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Во-первых, с радостью обращаю ваше внимание, что наc стало 150:)

Во-вторых, написал микропост о том, как фичи и идиомы Kotlin способствует локализации рассуждений о коде

В-третьих, апдейт статуса макропоста о диаграмме эффектов: я его перелопатил чуть более чем полностью. Для диаграммы ввёл две нотации - краткую и полную и сделал её совместимой с моделью С4. А сам пост разбил на два - спецификация и пример построения.
Процесс вроде начал сходиться, есть шанс, что сойдётся на следующей недели

#kotlin@ergonomic_code

Привет!

Ну скажите же, эта структура намного понятнее, чем свалки из controllers, services и т.д.

Возвращаюсь спустя полгода к проекту, сделанному по ЭП и нарадоваться не могу.

#case@ergonomic_code #why_ergo_approach@ergonomic_code #ergo_approach@ergonomic_code

Привет!

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

#tools@ergonomic_code #ergo_persistance@ergonomic_code #ergo_approach@ergonomic_code

Привет!

С радостью представляю вам спецификацию диаграммы эффектов v0.0.2:)

#effects_diagram@ergonomic_code #posts@ergonomic_code

Привет!

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

О том как использовать диаграмму эффектов для рациональной объектно-ориентированной декомпозиции я напишу третьим постом в текущей серии о диаграмме эффектов.

#posts@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

Пост с примером построения диаграммы эффектов реального проекта перешёл в стадию полировки, думаю есть шанс опубликовать его на следующей недели.

А чтобы вы пока не скучали я накатал микропост, о том что "Program to an interface, not an implementation" - это не про ключевое слово.

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

Привет!

Разбираю сейчас легаси проект на .Net и подвернулась хорошая иллюстрация из реальной жизни предпредыдущего поста про абстракции.

Я вообще пока не понимаю был ли смысл оборачивать Context в UnitOfWork, но вводить IUnitOfWork вообще никакого смысла не было - из него утекают типы реализации.

Я бы ещё хоть как-то понял интерфейс, если бы у них были тесты на моках. Но даже их нет.

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

А потом, похоже, вырисовывается ещё пара нетривиальных спинофов - про сцепленность и объектные/объектно-ориентированные дизайн и программирование.

#project_e@ergonomic_code #design@ergonomic_code

Привет!

Наконец-то мир начал отходить от массового помешательства

https://habr.com/ru/company/jugru/blog/670816/

#talks@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

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

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

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

#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