Привет!

"Хочешь насмешить бога - расскажи ему о своих планах" (с) Народ.

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

А ещё то, что на этой же недели у меня заболеет ребёнок 🤯

Поэтому план уже точно поедет как минимум на неделю.

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

#immutable_domain_model@ergonomic_code #ergo_approach@ergonomic_code #ergo_persistance@ergonomic_code

Привет!

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

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

Тем не менее, я осилил микропост с общим описанием проекта.

Всё остальное медленно, но верно тоже распишу.

#trainer_advisor@ergonomic_code

Привет!

В IDEA 2023.3 стал доступен всем AI Assistant с бесплатным триалом.

#tools@ergonomic_code

Привет!

Проживаю очередной кризис нигилизма:
1) ООП - нахер, эта фигня никогда не работала для информационных систем
2) ООД - нахер, эта фигня не масштабируется ([1], [2])
3) DDD - нахер, таш самая дичь, что и микросервисы - нужно и возможно только в 1% проектов, а в остальных - только удоржает разработку и тешит самолюбие разработчиков
4) Сокрытие информации - нахер, в рамках одного проекта над которым работает одна команда (а то и один человек) - это попахивает шизофринией
5) Open-Closed Principle и Dependency Inversion Principle и Чистая архитектура - нахер (пока реализация одна), эта хрень только усложняет кодовую базу и удорожает разработку
6) Low Coupling/High Cohesion - нахер, это какая-то непонятная дичь. На самом деле - тут тоже "пока что-то" или ещё какое-то условие, но вот что за условие - я ещё не понял.
7) Information Expert - нахер, эта фигня не масштабируется

А что не нахер?
1) DRY - это то, что позволяет снизить стоимость (гемморой для разработчика) внесения изменений
2) KISS - это то, что позволяет снизить стоимость (гемморой для разработчика) внесения изменений
3) Отсутствие циклов в зависимостях - это первое средство борьбы с Big Ball of Mud (упращения кодовой базы)
4) Неизменяемя модель данных - второе средство борьбы с Big Ball of Mud (упращения кодовой базы)
5) Структурный дизайн/функциональная архитектура - третье средство борьбы с Big Ball of Mud (упращения кодовой базы)
6) Единство уровня абстракции/SRP - четвёртое средство борьбы с Big Ball of Mud (упращения кодовой базы)
7) Очевидность связей (сцепленности?)/локальность рассуждений о коде - пятое средство борьбы с Big Ball of Mud (упращения кодовой базы)
8) Классическая школа ТДД - единственное (известное мне) надёжное средство борьбы с регрессиями -> возможность свободно улучашть качество кодовой базы
9) Базовая модель информационных систем в виде операций, ресурсов и эффектов - это то, чем информационные системы являются по своей сути

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

P.s.

1) добротный и двольно свежий пост с обзором и сравнением основных архитектур
2) И в дополнение - более подробный разбор вертикальной архитектуры

#ergo_approach@ergonomic_code #oop@ergonomic_code #ddd@ergonomic_code #design@ergonomic_code

Я тут подумал, что сцепленность, возможно зря в первый список поместил.

Я поленился написать обзор на Fundamentals of Software Architecture: An Engineering Approach, которую недавно прочитал и которая, на самом деле, мне понравилась намного больше, чем Software Architecture: The Hard Parts, а меж тем там авторы пишут про Connascence - аналог Coupling для ОО-систем.

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

В общем рекомендую вам и Fundamentals of Software Architecture: An Engineering Approach прочитать и Connascence погуглить.

Ну и сам я рано или поздно её разберу подробно и напишу о ней пост.

#books@ergonomic_code #oop@ergonomic_code #couplingergonomic_code

Привет!

В продолжение вчерашнего топика очень крутой доклад от Кента Бека про coupling и cohesion.

В докалде Бек утверждает, что в оригинальной книге сцепленность оценивается относительно некоторого изменения (хотя я сам такого не помню и в книге найти не смог).

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

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

—

Ещё одна мысль из доклада - "расстояние" между сцепленными элементами имеет значение. И это одна из основных причин, почему я перешёл от Эргономичной структуры в1 к в2. И в чём разочаровался по мотивам Проекта Э.

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

—

Ну и наконец книга - Tidy First?: A Personal Exercise in Empirical Software Design - добавлю в свой список на прочтение

#talks@ergonomic_code #design@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code

И вот ещё хороший доклад про Coupling.

Там же, внезапно, мужик говорит про тот самый Connascence и объёдиняет его с классическим Coupling в ещё более современный Integration Strength. Ток эту штуку тексту нагуглить не получается.

И так же говорит про "расстояние" в коде.

#talks@ergonomic_code #design@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code

Привет!

Вспомнили свою профессию?:)
Если нет - возможно вам поможет гайдлайн разработки Проекта Э практически без купюр:)

Я его подготовил к публикации ещё в прошлом году, но собственно опубликовать дошли руки только сейчас.

#ergo_approach@ergonomic_code #project_e@ergonomic_code

Привет!

А теперь наконец-то осилил встравить скриншот в другой прошлогодний микропост - Проектирование модели данных клинического мышления в Trainer Advisor.

И заодно анонс следующего (микро)поста - анализ эффективности работы команды Проекта Э во втором и третьем квартале от рождества христова от даты завершения реинжиниринга.

Это будет продолжение сравнения эффективности работы команд Проекта Э до и после реинжинирига - так же подобью задачи в джире и посмотрю медианные трудозатраты и количество багов на задачу. А потом сделаю экстраполяцию по трём точкам 🤣

#trainer_advisor@ergonomic_code

Привет!

Я не умер. И канал не умер. И я не забил ни на канал, ни на ЭП:)

Последнее время я активно допиливал Trainer Advisor. И теперь TA содержит всю базовую функциональность.

В цифрах это:
1) 14 таблиц
2) 12 страниц UI
3) 57 эндпоинтов
4) 4378 строк продового Kotlin-кода
5) 136 интеграционных + 2 мок-теста + 2 юнит теста + 1 архитектурный тест = 141 тестов, проходящих за 17 секунд
6) 1e2e Селениум тест

Это всё написано более-менее по текущим канонам ЭП и публично доступно для изучения и ознакомления.

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

—

Прямо сейчас в коде ТА хорошо проиллюстрированы две части ЭП:
1) Неизменяемая модель данных
2) Подход к тестированию

Так же с помощью 370 строк кода мне удалось решить две самые большие боли Spring Data JDBC:
1) Динамические критерии выборки
2) Подгрузку ссылочных данных для вывода на фронт (без дублирования структуры доменных объектов)

И сейчас решение этих задач у меня выглядит так:

// Выборка по динамическим параметрам:
findAll(pageRequest) {
        Client::therapistId isEqual therapistId
        Client::firstName isILikeIfNotNull clientSearchDto.firstName
        Client::lastName isILikeIfNotNull clientSearchDto.lastName
        Client::phoneNumber isILikeIfNotNull clientSearchDto.phoneNumber
}
// Выборка с подгрузкой ссылок
object Appointment.Fetch {
    val summaryRefs = listOf(Appointment::clientRef, Appointment::typeRef)
    val editableRefs = summaryRefs + Appointment::therapeuticTaskRef
}
val appointment = appointmentsRepo.findById(appointmentId, Appointment.Fetch.editableRefs)

Естественно, их можно комбинировать, но пока в проекте такой потребности нет.

Но эта работа так же помогла мне проявить пару противоречий и нерешённых проблем в ЭП:
1) С ФА есть проблема в том, что в большинстве моих проектов бизнес-логики (чистого ядра) набирается от силы процентов 10, а всё остальное - линейный круд. И кажется что это противоречит тому что ФА является одним из столпов ЭП
2) Реальный мир не всегда хорошо ложится на плоскую картину use case/workflow даже 3ей версии эргономичной структуры программ.

Что с этим делать - пока не знаю

—

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

#trainer_advisor@ergonomic_code #ergo_approach@ergonomic_code #ergo_persistance@ergonomic_code

Привет!

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

Гетц (ведущий дизайнер Java) пишет лонгриды про DOP в Java
Кложуристы пишут книги про DOP с примерами на JavaScript
Какой-то чувак на какой-то конфе рассказывает про DOP на Kotlin

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

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

1) Дизйн данных: неизменяемые реляционные данные - изменяемые списки неизменяемых деревьев объектов со ссылками между ними по ИДам (читай - репозитории агрегатов)
2) Дизайн операций: модернизированный структурный дизайн - рекурсивное разделение кода на координатора, ввод/вывод (процедуры) и трансформации (чистые функции) - и всё это с высоким cohesion
3) Группировка кода: дальнейшее развитие эргономичноый струкутры программ в3 слои приложения (операций, поведения) и домена (данных, состояния, внешних систем).
- Приложение делится по ролям, внутри ролей по экранам UI или Юз кейсам
- Домен делится на поддомены на основе аналитики (или UI, или на глаз), поддомены делятся компоненты по обновлённому алгоритму декомопзиции на базе эффетов
4) Автоматизация тестирования: практически без изменений - минимум моков (только для тестирования ошибок и подмены дорогих внешних систем), взаимодействие через публичное АПИ, тестирование системы на соответствие требованиям.

#ergo_approach@ergonomic_code #dop@ergonomic_code

Привет!

Я уже давно не читаю переводов технических книг.

Думал, что переводы бизнес-книг можно читать, и "Как создать продукт, который купят. Метод Lean Customer Development" начал читать на русском.

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

А оригинал:
> Between recruiting participants, preparing questions, taking notes, and summarizing, that equates to about two weeks of work. That may sound like a lot of effort, but if you learn that you can cut a single feature, you’ve already justified the investment in customer development

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

Хоть перечитывай оригинал с начала.

Не читайте переводов книг, если авторы не русскоговорящие (например, принципы юнит-тестирования) - совершенно непонятно что у них общего с оригиналом.
Единственное известное мне исключение - scip

#books@ergonomic_code

Привет!

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

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

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

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

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

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

#posts@ergonomic_code

И заодно -- как вы относитесь к явной рекламе?

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

Сейчас сделаю опрос

Привет!

Если долгими томными вечерами вы как и я любите позаниматься странным - например, почитать древние научные статьи на английском - то рекомендую почитать статью VALUES AND OBJECTS IN PROGRAMMING LANGUAGES, которая рассматривает с математически-философской точки зрению разницу между объектами и данными (ака сущностями и объектами-значениями).

ТЛДР - объекты изменяемые, а данные - нет; и в реальной жизни надо и то и то.

Ещё пара хлёстких цитат оттуда:
1) "Computer science - это объектно-ориентированная математика"
2) Программирование - это объектно-ориентированная математика, математика - это "value-oriented" программирование.

Эта статья подтолкнула меня поискать объекты в Trainer Advisor. И хотя конструкция object встречается 17 раз, изменяемый объект я нашёл только один - билдер динамических запросов. И то он изменяемый только потому, что Котлин (пока?) не достаточно data-oriented и не поддерживает литералы списков и мап.

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

#papers@@ergonomic_code #oop@ergonomic_code #dop@ergonomic_code

И про рекламу

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

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

В итоге я сформировал следующую позицию (с учётом того, что большинство читателей не против рекламы):
1) У меня нет и не будет цели монетизировать этот канал с помощью рекламы
2) Но я допускаю размещение рекламы для развития канала, при условии что:
2.1) Рекламируемый продукт не противоречит УК РФ и моим морально-этическим убеждениям
2.2) Реклама будет сопровождаться соответствующим дисклеймером
2.3) Я сам верю в то, что пишу

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

2) Совместный проект - сейчас в голову приходит только мой приход в гости в чей-то подкаст и соответственно ссылки друг на друга, но в целом возможны и другие варианты.

Привет!

Финализирую первый пост с описанием тестирования TA и походу дела накапал небольшую неопубликованную заметку с его архитектурой и стеком. И вот опубликовал:)

А пост с тестированием, думаю, на этой недели опубликую.

#trainer_advisor@ergonomic_code

Привет!

Опубликовал первый пост про тестирование TA с общими идеями и принципами (но уже здесь с иллюстрациями реальным кодом из TA).

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code