И тизер следующей части, где кода и картинок больше, чем текста:)

Привет!

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

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

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

#posts@ergonomic_code #clean_architecture@ergonomic_code

Привет!

Если вы как и я в последние лет 6 несколько раз пытались дедуплцировать версии зависимостей в мультипроектном Gradle-билде на Kotlin DSL и всякий раз терпели крах: кажется, наконец-то появился вменяемый способ это сделать - в 7-ом Грэдле оказывается появилась фича каталога версий

#tools@@ergonomic_code #gradle@ergonomic_code

Привет!

Меня тут после 3ёх лет работы исключительно на Kotlin (+ Spring Data JDBC) занесло писать на Java 8 (+ JPA).

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

В общем, если вы сейчас на Java (даже свежей - там всё равно нет null-safety и нормальных утилит манипуляции данными) - рекомендую попробовать Kotlin - DevX у Котлина на порядок выше.

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

А чтобы интереснее было пробовать - можно мне в Trainer Advisor поконтрибьютить:)

#whykotlin@ergonomic_code

Привет!

"Золотые слова, Юрий Венедиктович!"

Доклад: https://www.youtube.com/watch?v=9Q7GANXn02k

#talks@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

Опубликовал второй кусочек описания тестирования Trainer Advisor - сетап system under test.

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Начал читать Code That Fits in Your Head, пока прочитал только 50 страниц, но книга уже нравится.

В частности там есть очень крутой заход на важность локальности рассуждений/исключения скрытых эффектов через Систему 1 Канемана из Думай медленно… Решай быстро, который получил нобелевскую премию за исследования описанные в этой книге.

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

И так как Система 2 требует значительных энергозатрат, мы не можем постоянно работать на ней и большую часть времени работаем "спинным мозгом" - Системой 1.

А Система 1 "строит истории" только на основе того, что она видит прямо сейчас.
Соответственно, если взять видимый кусочек кода, которым я иллюстрировал проблемы побочных эффектов:

fun main() {
    val els: ArrayList<Int> = arrayListOf(2, 2)
    val sum = sum(els)
    println("Сумма ${els[0]} + ${els[1]} = $sum")
}

То глядя на него Система 1 быстро придумает историю, что sum вернёт значение, не поменяв els и выводом программы будет "Сумма 2 + 2 = 4". А это не так.

В общем минимизируйте количество изменяемого состояния в ваших программах, чтобы истории ваших Систем 1 чаще были правдоподобными:)

#whyfp@ergonomic_code #books@ergonomic_code

Привет!

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

#posts@ergonomic_code

Привет!

Я тут проснулся с мыслю - а вам не кажется, что Микросервисная, Гексагональня и Кричащая архитектуры - это всё про разное? И один проект может соответствовать всем трём сразу?

Привет!

Решил попробовать завести группу, посвящённую применению основных идей ЭП (модульные монолиты, неизменяемую модель данных, функциональную архитектуру, интеграционные тесты, outside in TDD, data-oriented programming) на практике.

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

Присоединяйтесь, будет полезно:)

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

И опубликовал очередной кусочек описания тестирования Trainer Advisor - формирование фикстурных объектов и их вставка в БД.

Там из 34К знаков 14К - код, почти половина:).

P.s. сбросьте кэш браузера, чтобы подтянуть css с выделеним строк в некоторых из сниппетов

#trainer_advisor@ergonomic_code #ergo_testing@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

Привет!

Дочитал Code That Fits in Your Head.
И хотя там есть нюансики (использование фейков БД, складирование всего кода в одной директории 🤯🤦‍♂️), автор топит за outside in tdd и функциональную архитектуру - рекомендую. Особенно молодым разработчиком.

Плюс практически одновременно досмотрел доклад Влашина Moving IO to the edges of your app: Functional Core, Imperative Shell - в целом, наверное, ничего прорывного в докладе нет, но если вы (как и я) ещё не уверены, что знаете на 100% как её применять - можно посмотреть. Там примеры на C# и никаких монад.

#books@ergonomic_code #talks@ergonomic_code #functional_architecture@ergonomic_code

Привет!

Посмотрел Build Abstractions Not Illusions.

Любопытная мысль оттуда:
> лёгкий тест на то, является ли абстракцией то, что вы сделали:
Абстракция должна вводить новую терминологию.

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

#talks@ergonomic_code #design@ergonomic_code

Привет!

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

Мысль №1
В докладе мужик привёл пару определений:
> Падение юнит-теста подразумевает сбой ровно в одном юните (методе, классе, модуле, пакете)
> Падение девелоперского теста подразумевает ошибку в последнем изменении кода

И мысль ещё из Бековской TDD by Example - кол-во кода, которое вы пишите между запусками тестов зависит от вашей уверенности в умении писать такой код.
И аналогия с вождением машины - чем увереннее вы себя чувствуете, тем быстрее вы едете.

И это прям хорошо легло на мой свежий опыт:
1. В Trainer Advisor у меня примерно 3-4 теста на HTTP-эндпоинт. И ~95% - работают либо через хттп, либо через конторллер
2. А недавно я написал один хттп эндпоинт, с 22 тестами из которых <50% работают через http.

В чём разница? В TA львиная доля эндпоинтов - примитивный КРУД - перегнать ДТО в сущность, сохранить сущность; вычитать ДТО из БД, вернуть - я это пишу спинным мозгом и там граничных случаев ноль целых хрен десятых.

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

В этом и разница.

—

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

—

Мысль №3
Возможно молодые подписчики ещё не сталкивались с http://wiki.c2.com/. Это самая первая вики в мире из 1995 года. От чувака, который придумал гексагональную архитектуру. И в которой в старые добрые времена тусила вся старая гвардия - начиная с самого Кокберна и продолжая анкл Бобом, Фаулером, Беком, Коплейном. Можно выделить вечерок и пошататься по ней впитывая мудрость древних.

—

Мысль №4
Чёт то ли я туплю, то ли у мужика не стыковка - он сначала пинает тесты с моками, за то что они мешают рефакторингу. А в конце доклада предлагает писать тесты на код интеграций с моками. Чтобы их потом не рефакторить?

—

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

—

Мысль №6
У мужика в докладе ни строчки кода нет. А у меня есть ~150 "developer tests", которые "tests behaviour, not functions" и для которых процентов на 30 готово описание идей и техник как, такие тесты писать

#talks@ergonomic_code #ergo_testing@ergonomic_code #tdd@ergonomic_code #whynomocks@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

Привет!

Пара баек про JPA. Для молодых разработчиков, в первую очередь.

Мне тут недавно студент сдавал в качестве курсового проекта стартап с живым клиентом в проде. И между делом рассказал душещипательную историю в духе "У нас основное приложение на JPA, но в первый же день в проде оно нам покасячило данные, поэтому админку мы начали делать на jooq, чтобы лучше контролировать работу с БД".

А вчера говорил наоборот с пишущим код СТО c опытом работы с JPA лет 10 минимум и между делом я написал "в какой-то момент мне показалось, что я с JPA освоился и закончу активную разработку на этой недели".

На что получил ответ:

> Ахахаха
это классика
я после задач с JPA никогда не говорю теперь что с ним освоился/разобрался
я его б*ь не знаю, там вечные сюрпризы и темные пятна вылазят

В общем прежде чем брать в проект JPA советую сначала попробовать затолкать в голову собственно саму 662-страничную Jakarta Persistence API Specification :) Перед тем как ещё страниц ~100 рефернсной доки на Spring Data JPA читать. И я уж молчу про 228 страниц спеки на JDBC. Жаль, спека на SQL непубличная - говорят в свежих версиях там 1000 страниц. Кто-нибудь, остановите меня уже:)

#whynotjpa@ergonomic_code #jpa@ergonomic_code

Привет!

Опубликовал пост с последним кусочком описания сетапа фикстуры Trainer Advisor - сетап тестовых дублей.

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

И под это дело добавил соответствующий бонус-трек в пост с описанием запуска инфраструктуры.

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code #whynomocks@ergonomic_code

Привет!

Поскидывайте в комменты, пожалуйста, литературу по функциональной архитектуре.

Меня в первую очередь интересуют материалы такой же степени детализации/проработки как и Domain Modeling Made Functional, но более "прагматично" - без монад/с примерами на языке не имеющим синтаксической поддержки для них.

Но небольшие посты/презентации тоже скидывайте

#books@ergonomic_code