Привет!

Довольно часто встречаю у студентов и молодых разработчиков ошибку добавления ИД в таблицу связку: user_roles(id, user_id, role_id).
Раньше я в таких случаях из чисто на основе интуиции говорил "лучше убрать и заменить на составной ключ, потому что ИД нафик не нужен и чуть лишней памяти жрёт".

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

#posts@ergonomic_code #relational_model@ergonomic_code

Привет!

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

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

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

Привет!

Я тут вынашиваю страшный план - отказаться от REST-стиля в "бэке одного фронта".

Как я собираюсь это делать:
1) Ядро продолжать так же делать из подсистем-объектов
2) Вокруг ядра сделать слой app, где по конторллеру на каждую страницу/экран/вью
3) урлы будут вида /api/app/login-page/login, api/app/dashboard-page/get-init-data
В общем в некотором смысле вернуться к структуре из этого поста, но сервисы приложения смёржить с контроллерами. Ну либо к пакетированию по компонентам Брауна

Что надеюсь получить:
1) Упростить процесс проектирования. Я давно этим занимаюсь и прочитал пачку книг по РЕСТу, но всё равно буквально в каждом проекте вылазит какая-нибудь штука, над которой я долго грею голову
2) снизить сцепленность ядра. в моём текущем подходе зачастую в подсистему надо тащить зависимость на другую подсистему, только для того чтобы вытащить вложенную сущность для какой-нить админки
3) Повысить удобство для фронтендеров - у них постоянно возникают вопросы что откуда брать для данной конкретной страницы. Тут, надеюсь, не будет. Плюс в доках появится понятное место куда можно будет сиквенс диаграммы работы страницы воткнуть
4) Повысить производительность. Как засунуть в рест один запрос для формы ввода, который вернёт пачку справочников для выпадающего списка - я не очень понимаю. А в эту схему - очень понимаю

Что потеряю и как планирую нивелировать потери
1) идиоматичность. С РЕСТом в целом народ как-то уже разобрался, а тут опять какая-то непонятная хрень. Это я попробую нивелировать за счёт простоты, возможности перенести общие принципы проектирования и постами с описанием идеи и кейсов
2) универсальность. Новому клиенту может не подойти существующее АПИ. Для второго клиента можно будет завести свой набор методов, а для третьего уже спроектировать и прикрутить сверху REST апи

Пока не очень понимаю что делать с методами, которые нужны на разных страницах. Но есть несколько идей:
1) по факту дублировать эндпоинты для них с минимизацией дублирования кода через делегирование в Котлине (и кстати о Котлине - я последнее время работаю с .net и чёт прям устал от NullPointerException - хочу назад в налло-безопстность 😥)
2) оставить такие методы в ядре
3) завести понятие ui-компонента на бэке - урлы вида /api/app/image-component/load

Я пока ещё думаю на эту тему и не уверен, что пойду туда, но возможно в ближайшем времени опробую её на личном проекте. И если опробую - расскажу как впечатления:)

#http_api@ergonomic_code #rest_api@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Соскучились? Я тоже:)

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

#posts@ergonomic_code

Привет!

Я почти доделал лендинг для Диаграммы Эффектов, но его надо ещё пополировать.

Зато под руку подвернулась хорошая линка про то, как писать доки:)

#posts@ergonomic_code

Привет!

Java 19 зарелизали О_О
ещё недавно ток 17ая была
сколько между 7ой и 8ой лет прошло? 4?
Щяс даже Котлин, кажись, раз в год релизается

Туда ещё и структурную канкаренси в инкубаторе впихнули О_О
так глядишь, году к 30, на юбилейной 30ой джаве можно будет жить почти как на Котлине

#tools@ergonomic_code #java@ergonomic_code

Привет!

По ряду причин сейчас нет ресурса на Эргономичный подход, но внезапно PR-повод подъехал с другой стороны:)

Если и вам надо сделать работу быстро и всё равно достаточно хорошо - приходите, свободные специалисты у меня есть

#ergo_approach@ergonomic_code #why_ergo_approach@ergonomic_code

Привет!

Раскрою одну из причин, почему я приостановил проработку Эргономичного подхода.

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

Я уже несколько раз упоминал в этом канале, что мне достался на саппорт и вывод в прод легась на дотнете. Так вот я умудрился сделать финт ушами и сначала продать РП идею переписывания его по ЭП на Котлине, потом вместе с РП и клиенту. На этом я и буду сфокусирован в ближайшие 4-5 месяцев.

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

Объём проекта:
1) примерно человеко-год разработки
2) 42 таблицы
3) 100+ рест эндпоинтов
4) 14 микросервисов

Ключевые проблемы проекта:
1) 0 (ноль) тестов
2) микросервисы. В данном случае они не решают никаких проблем
3) плохая нарезка на микросервисы.
3.1) Больше всего меня поразил метод генерации отчётов, который задействует 5 (пять) микросервисов. А если считать предварительную генерацию токена доступа, то 6
3.2) В целом практически каждый рест эндпоинт в своей работе идёт в 1-2 микросервиса
4) Библиотека shared, задействованная во всех МСах и ещё больше сцепляющая их
5) Взаимодействие между микросервисами на базе RabbitMQ и с протоколом в shared. В результате его сложно дебажить, а изменение нового требует кучу церемоний (поправить shared, собрать-опбликовать, обновить зависимость сервера, обновить сервер, обновить зависимость клиента, обновить клиент, выкатывать их строго вместе)
6) Вертикальная архитектура на базе MediatR. Даже самый простой эндопоинт требует пачку лишних приседаний - класс команды, класс обработчика, класс ответа, класс содержания ответа.
7) По определённым причинам проект заморозили в 19ом году, и он остался на устаревшей и более не поддерживаемой версии дотнета
8) У меня в команде нет экспертизы дотнета

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

Как я собираюсь это делать.
В подробностях я пока не спланировал работы, но в общих чертах план примерно следующий:
1) Мы в ближайшее время выводим в прод текущую версию
2) Сейчас у нас основные работы ведутся по созданию админ-панели к системе и часть АПИ мы уже сделали на дотнете, но на прошлой недели я начал заводить бэк на Котлине и в следующем релизе админку мы уже будем делать на Котлине
3) Все новые методы будем делать на Котлине
4) Все большие баги переписывать на Котлин и фиксать там (?)
5) Параллельно в обратном направлении графа зависимостей МСов методично всё переписывать и покрывать тестами. Выкатывать обновлённые методы будем каждый спринт

Сколько это стоит
Точную цифру я не назову, по понятным, причинам, но я планирую осилить эту работу за 3-4 месяца силами себя и двух джунов

Как я буду оценивать результаты
Для меня успех выглядит так: РП и заказчик отвечают утвердительно на вопрос "Видите ли вы на глаз как минимум удвоение скорости разработки?". Понятно, что это субъективно, но это именно то, что я продаю.
Кроме того, я посмотрю кол-во багов и регрессий, а так же среднее время задачи от "In Progress" до "Done" за месяц работы "до" и "после".
Если РП и клиент заметят удвоение на глаз и оно подтвердиться цифра - это будет оглушительный успех
Если РП и клиент не заметят удвоения, а на цифрах оно будет - пойду учиться доносить результаты
Если наоборот - можно так и оставить 😂
Если РП и клиент не заметят удвоения и это не подтвердиться цифрами - ну всё, расходимся

Касательно проработки ЭП - как только я выведу в прод этот проект и у меня устаканится ещё пара моментов, я надеюсь вернуться к практике "30 минут ЭП в день" и потихоньку продолжить двигать и эту тему.

Вот такие дела, пожелайте мне удачи:)

#project_e@ergonomic_code

Привет!

Я тут тихой сапой перечитал рекламирую мной структуру и интерпретацию компьютерных программ.
И я несколько поменял своё мнение о ней. В целом книга действительно крутая и рассматривает все ключевые вопросы программирования.
Однако, на мой взгляд, относительно просто перенести на реальную практику только первые 3 главы, посвящённые общим понятиям программирования.
А вот главы про интерпретацию и компиляцию перенести на реальную практику довольно сложно, если вы ещё не понимаете как это работает.

Наверное поэтому недавно выпустили редакцию с примерами на JavaScript (только на английском). Я её сам не читал, но может быть её будет проще перенести на реальную практику.

Ну и подтверждаю, что русскую версию можно смело читать.

Итого, вердикт:
1) Книга крутая, рекомендую к прочтению как минимум первые 3 главы
2) Главы 4-5 оригинальной версии не факт, что зайдут и будут полезны
3) Можно попробовать прочитать версию на JS-е, скорее всего так будет проще, если вы не умеете в лисп, или не собираетесь глубоко проштудировать эту книгу, с набором всех примеров и выполнением упражнений

#books@ergonomic_code

Утащил текст про xUnit Patterns в телеграф: https://telegra.ph/Strategiya-testirovaniya-kotoraya-srabotaet-dlya-bolshnistva-proektov-10-13

Привет!

Накатал микропост с описанием плана реинженеринга Проекта Э.
Там в целом никаких великих откровений нет, пожалуй, но надеюсь хоть кто-то хотя бы что-то полезное для себя почерпнёт. Ну и "на безпостье и микропост пост":)

#posts@ergonomic_code #project_e@ergonomic_code

Привет!

У меня на той недели был полуотпуск, за который я посмотрел кучу видосов и собрал микропост о том, что увидел.

#talks@ergonomic_code

Привет!

Наконец-то деделал лэндинг и спеку для Диаграммы Эффектов.
Плюс на лэндинге выложил ещё один кейс диаграммы реального коммерческого проекта, значительно большего, чем True Story Project

#effects_diagram@ergonomic_code #ergo_approach@ergonomic_code #project_geoservices@ergonomic_code #case@ergonomic_code

Привет!

Ваня практически продал мне Project Loom. Особенно после включения в него Structured Concurrency.

Если это всё зарелизят к очередному LTS-у и добавят хотя бы экстеншн-функции, а в идеале ещё и передачу хвостовых лямбд, и дефолтные параметры - я, пожалуй, буду готов снова писать код на Java:)

#talks@ergonomic_code #java@ergonomic_code

Привет!

Недавно посмотрел доклад с последнего JPoint-а, который продвигает подход, процентов на 80 совпадающий с Эргономичным.

По традиции, в этом докладе не было ничего о декомпозиции систем.
Но самое важное - в докладе продвигается традиционный подход к Railway-Oriented Programming на монадах.

Я пробовал так делать, мне не понравилось и сейчас я переключился на "пролетарский ROP на охранных выражениях".

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

#posts@ergonomic_code #talks@ergonomic_code

Привет!

Тизер моей текущей активности.

Года два-три назад я как-то рассказывал коллеге насколько плохО пакетирование по слоям. В ответ он задал мне невинный вопрос без задней мысли - "А как по другому"?
И тут я сдулся - вменяемого ответа на тот момент у меня не было.

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

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

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

Поэтому сейчас я переключился на последний кусочек паззла "Стратегия декомпозиции бакэндов информационных систем по Эргономичному Подходу".

В целом у меня есть готовый вариант который совершенно случайно (я серьёзно :) ), очень похож на структуру модулей из доклада, который я недавно рекламировал (и пост на ту же тему) и сейчас я хочу пытаться структурировать модули Проэкта Э и других своих последний проектов в соответствии с этой схемой и посмотреть, что получится.

И напоследок: ещё один любопытный подход к декомпозиции систем

#ergo_approach@ergonomic_code #project_e@ergonomic_code #guideline@ergonomic_code #posts@ergonomic_code #clojure@ergonomic_code

Привет!

Я в целом собрал свою версию структуры модуля. Она всё так же похожа на структуру из Let's build components, not layers и базируется на интерфейсе и реализации. Но я решил отдельно вынести порты - штуки, которые публикуют АПИ модуля наружу и "конфиг" - спринговый конфиг, который позволяет создать экземпляр модуля в рантайме.

У меня получился такой список типовых (под)пакетов модуля:
- api
- dtos - классы DTO АПИ модуля
- events - классы событий модуля
- model - классы сущностей и объектов-значений из DDD, в случае если они "выставлены" в АПИ
- *Exception - файл с иерархией исключений модуля
- *Service - файл с интерфейсом модуля
- internal
- db - классы репозитория и сущностей модуля и, при наличии, DAO и строки
- submodule1 - подпакет с кодом реализации подмодуля
- Submodule2.kt - котлин-файл кодом реализации подмодуля
- *ServiceImpl - файл с классом реализации интерфейса модуля
- *Props - класс конфигурационных параметров модуля
- ports
- *Controller - Spring MVC контроллер и обработчик ошибок
- *Listener - Spring RabbitMQ слушателя
- *Config - Spring-конфигурация модуля

Я перепаковал так Проект Э, TSP Project и ещё один нетиповой проект - пока полёт нормальный. Дальше хочу ещё перепаковать Кэмп, Проект Л и ещё один коммерческий проект (у каждого из них есть уникальные особенности) и после этого пойти писать вторую версию поста "Структура эргономичной кодовой базы" (осторожно, материал этого поста частично устарел).

#ergo_approach@ergonomic_code #ergo_arch@ergonomic_code #project_e@ergonomic_code #project_camp@ergonomic_code #project_geoservices@ergonomic_code

Привет!

Я уже писал, что даже декомпозиция на базе эффектов не является уникальной для ЭП.

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

Identifying Microservices Using Functional Decomposition

Сам эту статью ещё не читал, горячим пирожком поделился:)

#papers@ergonomic_code #effects_diagram@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Я прочитал Identifying Microservices Using Functional Decomposition - вы можете не читать, там ни чего особо нового:)
Самый полезный бит информации, это то что авторы экспериментально на трёх реализациях одного проекта подтвердили мой тезис "Она [декомпозиция на базе эффектов] проще в изучении и применении группировок по фичам, компонентам и ограниченным контекстам/агрегатам, но даёт результаты такого же качества." [1].
У них получилось, что интуитивная декомпозиция требует "дней", а автоматизированная на базе эффектов - "часов". А результаты идентичные

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

#effects_diagram@ergonomic_code #ergo_approach@ergonomic_code

Молния!

Я, возможно, тормоз, но я тут открыл github codespaces

И они реально работают - мне тут надо было подправить пулл реквест в спеку диаграммы эффектов, я открыл ветку в спейсе, мне открылся ВС Код, я там поставил плагин аскиидока, и открыл превью! О_О
Поставил вим и он заработал
А вот синк сеттинги на веб не поставились.
Но в любом случае, это вполне рабочий вариант что-то подхачить в приличной среде, не выходя из облака

#tools@ergonomic_code