Привет!

Прочитал Software Architecture: The Hard Parts, более подходящим названием которой было бы "Yet another монолит в микросервисы - практическое пособие для мазохистов по выбору инструментов самоистязания".

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

В остальном - очень качественный, полноценный и "comprehensive" материал, с обзором вариантов архитектур и адекватным обзором плюсов и минусов.
Так что рекомендую.

Особенно понравилось/зацепило глаз:
1. идея разделения на статическую и динамическую сцепленность. Думаю я себе это утащу в будущий пост про неё.
2. Идея пакетирования домен.поддомен.компонент и требование, чтобы компоненты были только в листах. У меня сейчас всё компоненты, при том допускаются вложенные компоненты и это не всегда работает. Не уверен, что утащу эту идею к себе, но точно подумаю в эту сторону
3. Они там так же как и я предлагаю технику выбора имени компонента, для определения его "разумности". И в целом в части декомпозиции, возможных вариантов решения сложных случаев и советов по выбору среди них - у нас совпадение процентов 80, но в книге материал больше проработан. Думаю, чем-то из книги смогу дополнить свой подход.
4. Понравилась идея семантической сцепленности - сцепленности в самой предметной области. Правда, эта штука ещё более расплывчатая, чем сцепленность в техническом решении.
4.1. Туда же хорошая идея, что техническое решение может только ухудшить (и часто так делает), семантическую сцепленность
4.2. Туда же идея, что при дизайне архитектор может "push back"-ать требования, если они содержать избыточную семантическую сцепленность, в лёгкой форме это у меня было в дизайне интеграции с ЕМИАС, где по изначальным требованиям казалось, что заказчик хочет семантической сцепленности регистрации пользователя в системе и привязке его к ЕМИАС

#books@ergonomic_code #project_e@ergonomic_code

Привет!

Подглядел в https://t.me/byndyufeed

https://ralphammer.com/make-me-think/

Пока сам не прочитал, но гифки завораживают.
Узнаёте себя при работе с современными фреймворками на левой гифке? Я да.

Привет!

Прочитал Functional Design: Principles, Patterns, and Practices.
Впечатления не однозначные

С одной стороны, там и правда, слово монада встречается ровно один раз в месте, где Мартин пишет, что не будет писать о них:
> As such, I will not spend any appreciable time on the more theoretical aspects of functional programming such as Monads, Monoids, Functors, Categories, and so on

И там и правда хорошо иллюстрируются плюсы ФП, его совместимость с ООД/П и то, что код в ФП-стиле может выглядеть достаточно знакомым большинству разработчиков.

С другой стороны, там нет ни строчки кода работы с БД - аспектом, который вносит больше всего "интересностей" в применение ФП при разработке бэков информационных систем. Более того, в книге вообще никаких интересных эффектов с вводом-выводом нет.

И отсюда же, видимо, вообще не раскрыта важная и одна из самых сложных частей ФП стиля - проектирование модели данных. Неизменяемой. И эффективно хранимой в БД.

Ну и Clojure. Мне язык нравится, и я согласен с тем, что на скобки глаз набивается быстро, но использовать книгу с примерами на Clojure в качестве инструмента популяризации ФП я не стану.

Поэтому рекомендовать книгу как единый источник для изучения прагматичного ФП нельзя, на мой взгляд. Но в рамках погружения в этот дивный мир книгу стоит прочитать.

#books@ergonomic_code

Привет!

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

С учётом того, что я заявляю, что ЭП позволяет существенно сократить кол-во багов, а в этом релизе на бэке нашли штук 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