Привет!

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

Привет!

Вчера задеплоили в прод результаты первых трёх спринтов -первый кусочек (~20%) нового бэка Проекта Э, в проде нашли один баг нового бэка, и старый баг в старом бэке:) Я считаю неплохо.

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

Касательно Эргономичного подхода у меня на подходе (pun intended) лендинг для него - планирую зарелизать на следующей недели

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

После этого я наконец вернусь к большим постам. Сейчас у меня есть идеи четырёх потенциальный поста:
1) Наконец написать пост по декомпозиции проекта TSP на базе диаграммы эффектов
2) Пост о шаблоне раскладки кода по пакетам в Эргономичном подходе
3) Пост о том, почему я считаю, что ФП стиль даёт лучшие результаты, с точки зрения суммарной стоимости разработки
4) Собственный пост о функциональной архитектуре с заходом через трансформационно-центричную морфологию из структурного дизайна.

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

#project_e@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Зарелизил анонсированный на прошлой недели лендинг Эргономичного подхода:)

Теперь вам есть куда отправить уставших от багов и вечных спринтов разработчиков и владельцев продуктов:)

Пользуясь случаем, хочу ещё раз выразить благодарность руководителям проектов, на которых я обкатывал ранние версии ЭП: Николаю Макарову, Денису Исаеву, Евгению Тимофееву и Дмитрию Семёнову - парни, без вас бы ЭП не было.

#ergo_approach@ergonomic_code

Привет!

Написал очередной микропост на тему того, "Почему ФП?".

#posts@ergonomic_code #whyfp@ergonomic_code

Привет!

А вот и подошла очередь анонсированного ранее релиза спеки диаграммы эффектов в0.1.0.

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

К этим изменениям в модели меня подтолкнули грамотные вопросы специалиста из documentat.io, у которых я заказал техническую редактуру спеки.
Это - полировка текста профессиональным техническим писателем - второе больше изменение в спеке.

#posts@ergonomic_code #effects_diagram@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Нашёл железобетонный аргумент в пользу классической школы тестирования:)

> You may have heard of famous Classicist TDD practitioners including Uncle Bob and Kent Beck. If you want an example of a Mockist look no further than Sandi Metz, J.B Rainsberger or Steve Freeman
Test Driven Development Wars: Detroit vs London, Classicist vs Mockist

Так, ну анкл Боба и Бека каждая собака знает. Если что, Фаулер - тоже классицист.

А вот за эти ваши моки - что за господа (и дамы) с горы топят? Они даже в выдаче стартпейджа ниже футболистов. Единственное известное (мне) творение этих авторов - Growing Object-Oriented Software, Guided by Tests - Хориков (тоже классицист) в части дизайна и качества тестов разнёс в пух и прах.

А если серьёзно, я начинаю потихоньку отходить от абсолюта "не используйте моки никогда!" - так что не сильно удивляйтесь, увидев пост "Когда и как стоит использовать моки?":) Тизер: тогда, когда надо симулировать ошибку, отгородится от дорогой/медленной/нестабильной внешней системы и стараться мокать только стабильные интерфейсы.

#posts@ergonomic_code #ergo_testing@ergonomic_code #tdd@ergonomic_code #whynomock@ergonomic_code