Привет!

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

С учётом того, что я заявляю, что ЭП позволяет существенно сократить кол-во багов, а в этом релизе на бэке нашли штук 5-6 багов (справедливости ради - только при тестировании МП и в течении 2-3 недель), то я этот релиз и все баги разберу по косточкам. И постараюсь опубликовать разбор, если удастся сохранить смысл, не нарушая NDA.

#posts@ergonomic_code #project_e@ergonomic_code

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

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

#posts@ergonomic_code #whyfp@ergonomic_code

Привет!

Я завершаю работу над Проектом Э с 1 января 2024 года и ищу новый проект.

Со мной возможен широкий спектр вариантов сотрудничества - от реализации проекта под ключ по фикс прайсу силами моей команды до краткосрочного аутстаффа меня лично.
Работаю я по договору с ИП (ЭДО есть) и оплатой на расчётный счёт.

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

Если вы или ваша компания сейчас ищете подрядчика/субподрядчика на выполнение работ по разработке ПО - напишите, пожалуйста, мне в личку - @d_r_q, или на почту - me@azhidkov.pro.

Привет!

Я рассматриваю вариант существенного изменения концепции канала, и прежде чем принять окончательное решение, хочу узнать ваше мнение.

Изменения будет два:
1) Переключение фокуса на практику
2) Переход на формат быстрых (без особой режиссуры и монтажа) видео

Посты будут о разработке (интересных, не обычных и сложных частях) моего пет-проекта - QYoga (название рабочее, сегодня проведу брейншторм нового названия:) )

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

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

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

Сейчас заведу пару опросов.

#trainer_advisor@ergonomic_code

Привет!

Я определился с форматом и планами канала на ближайшие полгода-год.

Основным форматом остаётся текстовый.

Потому что:
1. Почти половина против видео (Я занёс в против тех, кому ок видео нормального качества, см. п. 3)
2. В комментариях 100% против
3. Я провёл небольшой тест-драйв такого формата и понял, что без подготовки получается лажа.

Но, я хочу всё-таки попробовать продемонстрировать разработку по эргономичному ТДД, поэтому как минимум один видеопост всё-таки будет.

Контент станет преимущественно практическим (на базе QYoga).

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

Сейчас у меня план постов следующий:
1. 22 ноября - микропост с нотацией описания неизменяемой модели данных (пригодится для следующего поста)
2. 23 ноября - микропост с общим описанием QYoga
3. 24 ноября - микропост о том, как мы моделируем самую сложную часть QYoga
4. 2 декабря- микропост с описанием устройства кодовой базы QYoga
5. 3 декабря- видеопост с демо эргономичного ТДД
6. 10 декабря - пост с третьим томом ретро Проекта Э (устройство кодовой базы)
7. 24 декабря - пост с четвёртым томом ретро Проекта Э (проблемы унаследованные от .net-бэка)

И спасибо всем, поучаствовавшим в опросе:)

Эдит: обновил планируемые даты постов

Привет!

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

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

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

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

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

#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