Но пост выше - это я просто актуальным поделился.

А вообще - сегодня день релиза поста "ФП виновно в снижении стоимости программ. Вот мои доказательства, господа присяжные заседатели" :)

#posts@ergonomic_code #why_fp@ergonomic_code

Привет!

Я несколько лет назад придумал тезис: у бизнеса и разработчиков одна цель - быстро выпускать фичи без багов.

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

- Я (пока что скорее голословно) утверждаю, что ЭП позволяет быстро выпускать фичи с минимумом багов

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

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

Осталось сделать самую "малость" - провести двойные слепые рандомизированные исследования об эффективности работы по ЭП и... неЭП

#posts@ergonomic_code

Привет!

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

Лично меня больше всего порадовала мысль Андроид разработчика, что бэк - это не деталь реализации, а домен:)

Правда следуя этой логике, можно прийти и к тому, что БД - это не деталь реализации, а домен:)
Что, на самом-то деле, похоже на правду - я уже не раз выкидывал "ядро" системы в виде кода, оставляя "деталь реализации" в виде данных в текущей схеме и строил новое ядро поверх этой детали.

#posts@ergonomic_code #clean_architecture@ergonomic_code

Привет!

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

#posts@ergonomic_code

Привет!

Забрёл сегодня в блог анкл Боба, там наткнулся на древний пост, а там:

OO is not about state.
Objects are not data structures. Objects may use data structures; but the manner in which those data structures are used or contained is hidden. This is why data fields are private. From the outside looking in you cannot see any state. All you can see are functions. Therefore Objects are about functions not about state.
When objects are used as data structures it is a design smell; and it always has been. When tools like Hibernate call themselves object-relational mappers, they are incorrect. ORMs don’t map relational data to objects; they map relational data to data structures. Those data structures are not objects.
Objects are bags of functions, not bags of data.

#posts@ergonomic_code #oop@ergonomic_code

Привет!

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

Оказывается, предыдущий пост был юблиейным - 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

Что ещё почитать на тему тестирования
Принципы юнит тестирования - самая крутая книга на эту тему
TDD Revisited - Ian Cooper - NDC Porto 2023 - суть здорового тестирования за час пятнадцать
Пачка постов у меня про тестирование Trainer Advisor
Подборки постов у меня в канале - #tdd #nomocks

#ergo_testing@ergonomic_code #books@ergonomic_code #talks@ergonomic_code #posts@ergonomic_code

Привет!

Опубликовал пост по мотивам доклада на Joker.

#structured_design@ergonomic_code #ergo_approach@ergonomic_code #talks@ergonomic_code #posts@ergonomic_code

Привет!

Мысли в слух.

Наткнулся на очередную свеженькую статью по чистой архитектуре.
В двух словах: чистая архитектура - это не про пакеты - не заводите пакеты domain, application, infrastructure, web, заводите пакеты по фичам.
В целом ничего супероригинального, но любопытный аргумент в пользу пакетирования по фичам там есть — по мере жизни приложения, у него появляются новые фичи, а новые слои — практически никогда.

И так как покой мне только снится, это меня натолкнуло на мысль о потенциальной эргономичной структуре программ в4. в3 выглядит так, напомню.
Сейчас она у меня в целом работает и серьёзных нареканий нет, но мне не нравится фактическое дублирование содержания пакетов app и core, в случае если app декомпозируется по фичам.

И вот глядя на этот пост, я подумал, что гипотетически, в в4 я мог бы вернуться к декомпозиции по домену/фичам на первом уровне, но для решения проблемы лишних зависимостей добавил бы компоненты без состояния.

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

Карта канала (Так же в Max)

Добро пожаловать на канал "Эргономичный код" — канал о разработке поддерживаемых кодовых баз в общем и моём подходе к этой задаче — Эргономичном подходе.

Что такое Эргономичный подход?
По большому счёту это небольшой набор принципов, взятых в основном из классической школы TDD, функциональной архитектуры и DDD, и большой набор рецептов — моделей, методик и шаблонов —, которые позволяют команде быстро создавать кодовые базы, соответствующие этим принципам и, как следствие, лёгкие в поддержке.
Подробности на сайте Эргономичного подхода

В Эргономичном подходе есть что-то уникальное?
Да. Идея представления системы как модели её эффектов в виде диаграммы эффектов и методика проектирования на базе этой модели.

"Слова дёшевы, покажи мне код!"
Trainer Advisor — некоммерческий, но реальный (~20K строк Котлин кода, 21 таблица, 2 настоящих пользователя, горки костылей, "компромиссных решений" и исторических наслоений) проект с открытым исходным кодом, разрабатываемый по Эргономичному подходу. В этот проект можно поконтрибьютить и на своём опыте прочувствовать работу с эргономичной кодовой базой.

Project Mariotte — минимальный демонстрационный пример кодовой базы, написанной по Эргономичному подходу, на примере операции бронирования номера в отеле

Есть что посмотреть или послушать?
Да, все мои публичные выступления собраны на одной странице

А почитать, кроме канала?
Да, в блоге

В блоге и канале есть подборки:
- Кейсы (в блоге, в канале #case@ergonomic_code)
- Примеры кода (в блоге)
- Эргономичный подход (в блоге, в канале #ergo_approach@ergonomic_code)
- Эргономичное тестирование (в блоге, в канале #ergo_testing@ergonomic_code)
- Функциональная архитектура (в блоге, в канале #functional_architecture@ergonomic_code)
- Эргономиный персистанс (в блоге, в канале #ergo_persistance@ergonomic_code)
- Что ещё почитать (в блоге, в канале #books@ergonomic_code, #posts@ergonomic_code, #papers@ergonomic_code)
- Что ещё посмотреть (в блоге, в канале #talks@ergonomic_code)

Какие ваши доказательства?
Исследование "Характеристики поддерживаемых кодовых баз backend-приложений"

А у меня вопрос!
Приходите в группу - там целому сообществу (более 100 крутых инженеров) можно задать любой вопрос по тематике канала - Эргономичный подход, классическая школа ТДД, ФА, ФП, в целом дизайн модели и системный дизайн

Как мне научить ИИ агента писать код по Эргономичному подходу?
Попробуйте раннюю версию моего фреймворка для ИИ-агентов.

Привет!

С наступившим новым годом!

Принципы программирования от разработчика HTMX - Prefer if statements to polymorpism

Особенно понравилось:

It states that a high-level module can depend on a low-level module, because that’s how software works.

Сразу видно - человек давно в индустрии:)

#posts@ergonomic_code #design@ergonomic_code #htmx@ergonomic_code

Привет!

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

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

Привет!

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

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

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

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

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

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

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

#posts@ergonomic_code

Привет!

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

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

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

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

Привет!

Прочитал субстак про 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

Привет!

Соскучились? Это затишье перед бурей - у меня зреет сразу три большие новости:)
Но новости будут в мае, а пока пара ссылок.

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

А сегодня наткнулся на то, что у Фаулера были примерно те же проблемы 20 лет назад.
В статье 2007 Design Stamina Hypothesis, он рисует "псевдографик", на котором задизайненная система довольно быстро (в течении недель) начинает обгонять по объёму фич, незадезайненную. Тем самым обосновывая дизайн системы (например по ЭП).

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

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

#posts@ergonomic_code

Привет!

Не прошло и квартала, как я опубликовал Учимся читать SQL SELECT!

Если вы уже давно тут (в бакэнд разработке) сидите - вряд ли в посте будут для вас большие откровения.
А вот если только присели и побаиваетесь SQL-я - пост должен помочь. По-крайней мере у меня опыт объяснения работы SELECT-а таким способом для студентов - строго положительный.

#posts@ergonomic_code

Привет!

Я тут недавно прочитал Overengineering in Onion/Hexagonal Architectures (перевод).

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

В посте по ссылке есть тезис:

To put it another way, it is a design goal of the Application Service to host orchestration logic to allow lower-level components to become less coupled to one another.

—

Другими словами, Application Services предназначены для размещения логики оркестрации, что позволяет компонентам более низкого уровня быть менее связанными друг с другом.

Но я в 22-ом году (на 18-ом году коммерческой практики и примерно 5-ом году знания про Чистую архитектуру, ДДД, оркестрацию и сервисы приложений) всё равно изобрёл объектно-ориентированную декомпозицию. И пошёл делать по ней #project_e. И получил ровно, то, чего позволяют избегать сервисы приложений - высокую связанность между модулями-объектами.

Сколько ещё у меня таких "изобретений" из-за того что "смотрю в книгу, вижу фигу"? Вопрос риторический, конечно. Время покажет, всё что покажет - расскажу как на духу. Сегодня начал писать пост с ретро #project_r

PS>
И в топик "простых" CRUD приложений из комментов ко вчерашнему посту: в Overengineering in Onion/Hexagonal Architectures про них тоже тоже есть:

Like any tool, concentric architectures are not suitable for any software project. If the domain complexity of your problem is fairly low (CRUD-like), or if the challenge of your application is NOT in the complexity of its business rules, then the Onion/Hexagonal/Ports-Adapters/Clean Architecture might not be the best choice, and you might be better off with vertical slicing, anemic model, CQRS, or another type of architecture.

—

Как и любой другой инструмент, концентрическая архитектура подходит не для всех проектов. Если сложность предметной области вашей задачи довольно низкая (CRUDо-подобная) или если сложность вашего приложения заключается не в сложности его бизнес-правил, то архитектура Onion/Hexagonal/Ports-Adapters/Clean может оказаться не лучшим выбором, и вам, возможно, лучше использовать вертикальную архитектуру, анемичную модель, CQRS или другой тип архитектуры.

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

Привет!

С подачи @niktimf (Никита, спасибо) прочитал

https://habr.com/ru/articles/919168/
https://habr.com/ru/articles/919368/

Мне понравилось - сам расставил все лайки на Хабре и подписался на канал автора и вам рекомендую как минимум ознакомиться:)

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

В первом посте есть тезис:

Ну и завершим духоту следующим замечанием: [из результатов исследования] видно, что IT-Performance организации хоть и имеет связь с успехами организации, но явно слабую. С одной стороны, это весьма логично: было очень бы странно, если бы можно было облажаться с идеей, бизнес-планом, маркетингом, продажами, менеджментом, но иметь успешный бизнес чисто за счет крутых технарей. С другой стороны, это замечательно объясняет тот факт, что большинство компаний делает с точки зрения техники откровенный шлак и при этом имеют вполне себе прибыльные бизнесы.

В посте автор, судя по всему, говорит об архитектуре больших-огромных (500К+ строк?, десятки разработчиков) систем, а я могу это подтвердить для небольших-средних приложений (10-500к строк, 1-5 разработчиков).

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

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

И это противоречит тому, что и я сам пытался приземлить ЭП на деньги и ценность для бизнеса, и не раз встречал других разработчиков, которые оценивали/критиковали идеи/подходы вопросом "А что это даст бизнесу". И ответ, видимо - ничего. Как и все альтернативные технически упражнения.

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

Когда вы в последний раз приходили на проект и думали: какая удачная получилась архитектура, кто тот гений с зарплатой вдвое больше, чем у меня, что придумал этот алмаз? Я вот такого не припомню

— цитата из того же поста

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

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

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

Эргономичный подход не является волшебной таблеткой, перед применением необходимо проконсультироваться с техлидом :)

#posts@ergonomic_code #philosophy@ergonomic_code

Привет!

Наткнулся на пост о фреймвоке размышлений об ошибках Марка Симана.

И он до неприличия похож на мой, независимо разработанный, подход:
1. Симан так же категоризирует ошибки по атрибутам ожидаемая/неожиданная и восстановимая/невосстановимая
2. Симан так же предлагает восстановимые ошибки возвращать (чем-то в духе nullable типа/Result/Eather etc), а невосстановимые ошибки выбрасывать исключениями.

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

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

#posts@ergonomic_code #ergo_approach@ergonomic_code