Привет!

Соскучились? Это затишье перед бурей - у меня зреет сразу три большие новости:)
Но новости будут в мае, а пока пара ссылок.

Я в последнее время много думаю о том, как мне железобетонно обосновать пользу применения ЭП и пока не придумал.

А сегодня наткнулся на то, что у Фаулера были примерно те же проблемы 20 лет назад.
В статье 2007 Design Stamina Hypothesis, он рисует "псевдографик", на котором задизайненная система довольно быстро (в течении недель) начинает обгонять по объёму фич, незадезайненную. Тем самым обосновывая дизайн системы (например по ЭП).

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

А проверить её невозможно, потому что по его (и моему) мнению из 2003 года эффективность разработки надо оценивать как <увеличение выручки бизнеса> - <стоимость разработки>. Но как привязать увеличение выручки к реализованной фичи - хз.

#posts@ergonomic_code

Ну и за одно полезняшка - рыба статьи на вики о том как поддержать мультитенантность на базе схем в Spring Data JDBC. Основана на опыте её реализации в #project_r

#spring_data_jdbc@ergonomic_code #ergowiki@ergonomic_code #project_r@ergonomic_code

Привет!

Полезняшка. А для кого-то может и целых три за раз:)

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

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

А ещё если не знали - для Gradle есть плагин, который позволяет закинуть в проект git.properties-файл с инфой о сборке (дата, ветка, тэг, автор и т.д.), который можно добыть в рантайме через Actuator.

Но есть была проблема - плагин не умеет в worktrees и по дефолту взрывает всю сборку при запуске из директории со вторичной копией.
Я года 4 хачил это комментированием плагина во вторчных директориях. И раза три это случайно коммитал и откатывал.

И вот наконец написал 8 строк, которые костыляют эту проблему аккуратнее

// build.gradle.kts

gitProperties {
    val dotGit = File(".git")
    if (dotGit.isFile) {
        val actualGitDir = dotGit.readText().substringAfter("gitdir: ").substringBefore("/worktrees")
        this.dotGitDirectory.set(File(actualGitDir))
    }
}

Важное уточнение - это именно костыль и в git.properties при этом попадут данные из основной рабочей директории, а не той, где была запущена сборка

#tools@ergonomic_code #tips@ergonomic_code #git@ergonomic_code

Привет!

Что-то последняя большая новость никак не дозреет, поэтому пока расскажу о двух созревших.

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

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

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

Но сразу хочу предупредить, что ревью будет дотошное и каждый МР скорее всего будет проходить 2-3+ итерации ревью.
И что делать надо будет не только бэк, но и фронт. Как минимум вёрстку на Twitter Bootstrap (с чем неплохо чат-боты справляются) и, иногда UI-логику на AlpineJS типа такой: 1, 2, 3, 4.
В целом сейчас разбивка строк кода по типам следующая: Kotlin - 81%, html - 14%, css - 3%, js - 2%
Но фронт я ревьювлю уже не так дотошно. Думаю, если вы нагенеряете код гопатычем и он будет работать - я не замечу:)

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

И быстрого прогресса по книге не ожидайте - она будет бороться за мой ограниченный временной бюджет ещё и с ТА, блогом (где у меня план таки дописать пост про SQL в ближайшие пару недель, а потом таки написать ретро #project_r) и двумя детьми.

Кроме того, я под книгу планирую написать отдельную версию ТА, чтобы:
1. коммиты были привязаны к главам
2. API сделать в виде более распространённого JSON over HTTP, а не Тру REST API
3. в целом убрать исторические наслоения и быстрые хаки в коде, чтобы код был образцово-показательным, а не реальным в части компромиссов.

В общем, интуитивно, с учётом всех вводных мне кажется, что писать книгу я буду ещё года 2-3.

Так что стей тюнед, будет интересно:)

А ну и с третьей новостью - там тоже будет интересно (я мастер интриги 😂) - надеюсь в начале июня она таки дозреет:)

#trainer_advisor@ergonomic_code #ergo_book@ergonomic_code

Привет!

Тогда я решил посмотреть на Котлин. И больше не оглядывался [на Java]
— Род Джонсонс, создатель Spring Framework, Kotlin Conf 2025

#why_kotlin@ergonomic_code #talks@ergonomic_code

Привет!

Полезняшка.

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

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

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

В общем я по этому поводу не парился и коммитался как получится.

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

Однако этот метод подтолкнул меня к версии создания сфокусированных коммитов, с приемлимым для меня кол-вом оверхеда и геммороя.
Выглядит он так:
1. пилите фичу до победного ваще не парясь про размер
2. шелвите всё что есть.
3. глазами просматриваете изменения в шелве выглядывая там сфокусированные коммиты и их примерный порядок
4. аншелвите изменения первого вспомогательного коммита, прогоняете тесты, коммитаете
5. повторяете п. 4 пока не закоммитаете все предварительные изменения
6. аншелвите изменения целиком (решая конфликты идеевской волшебной палочкой), ещё раз просматриваете, что там нет ничего лишнего и коммитаете финальный коммит
6.1 если нашли что-то лишнее - повторить с п. 2

Эта процедура в зависимости от тяжести случая занимает от 15 минут до пары часов, но даёт таки сфокусированные коммиты.

Это не то чтобы прям гениальное изобретение, но я 10 лет не мог додуматься - может кому-то сэкономлю пару лет:)

#tips@ergonomic_code #git@ergonomic_code

Привет!

Вы уже запомнили как расшифровывается IODA-архитектура?:)

Вот вам ещё акроним, чтобы блеснуть на собесе эрудицией - self-contained systems (SCS) architecture.

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

#talks@ergonomic_code

Привет!

Статья про чтение SQL-я уже на финишной прямой. Думаю в среду-четверг опубликую.
А пока - меня похвалил гопатыч. Хоть он и СЛАУ-переросток, а всё равно приятно:)

PS> каждая буква этой статьи написана лично мной.
Ток в коде есть немного тривиального автодополнения

Привет!

Не прошло и квартала, как я опубликовал Учимся читать SQL SELECT!

Если вы уже давно тут (в бакэнд разработке) сидите - вряд ли в посте будут для вас большие откровения.
А вот если только присели и побаиваетесь SQL-я - пост должен помочь. По-крайней мере у меня опыт объяснения работы SELECT-а таким способом для студентов - строго положительный.

#posts@ergonomic_code

Привет!

Жутиков вам в утреннюю ленту.

В текущем мастере Хибера 1.3М строк Java-кода:

atomic-armchair : ~/tmp > git clone https://github.com/hibernate/hibernate-orm.git                                                             
Cloning into 'hibernate-orm'...
remote: Enumerating objects: 763047, done.
remote: Counting objects: 100% (333/333), done.
remote: Compressing objects: 100% (162/162), done.
remote: Total 763047 (delta 243), reused 171 (delta 171), pack-reused 762714 (from 2)
Receiving objects: 100% (763047/763047), 281.04 MiB | 2.20 MiB/s, done.
Resolving deltas: 100% (471253/471253), done.
atomic-armchair : ~/tmp > cloc hibernate-orm/
   17126 text files.
   17002 unique files.                                          
     204 files ignored.

github.com/AlDanial/cloc v 2.04  T=25.71 s (661.3 files/s, 77566.1 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Java                         15603         266991         243111        1348435
AsciiDoc                       128          10432            660          32337
XML                            816           4135           4441          25428
XSD                             21           3912           1455          22496
SVG                             29             11             28           6548
Gradle                          41            788            436           3426
CSS                              7            176            184           3164
SQL                            218            401            346           2981
ANTLR Grammar                    8            414            698           1760
Bourne Shell                    13            222            427           1599
Text                            46            322              0           1354
Properties                      34            179            257            952
DTD                              2            143            185            805
YAML                             6             37             77            588
Groovy                           5             75             63            367
Markdown                         6            114              6            302
HTML                             2             24              4            256
Maven                            7             33             24            225
DOS Batch                        2             42              4            138
Dockerfile                       5             20            145             75
JavaScript                       1              6              0             52
Kotlin                           2              6              4             25
-------------------------------------------------------------------------------
SUM:                         17002         288483         252555        1453313
-------------------------------------------------------------------------------

#whynotjpa@ergonomic_code #tools@ergonomic_code

Привет!

Запулил статью про sql на хабр и читатели как всегда порадовали - спустя 9 минут после публикации 20 минутной статьи, какой-то скорочитатель заминусил за низкий технический уровень🤦‍♂️😂

Кстати, я с предыдущим постом про Чистую архитектуру на 50+ рейтинга попал в программу поддержки авторов и теперь мне при рейтинге поста от 30 накидывают по 3 т.р., а от 50 - по 5 т.р. - так что можете поддержать меня и канал простым кликом:) И вам не сложно, и мне приятно:)

Привет!

Я тут недавно прочитал Overengineering in Onion/Hexagonal Architectures (перевод).

В целом с посылом поста я согласен (кроме мёржа REST-аннотаций в сервисы, хотя сам об этом думал), но там ничего суперкрутого - этот мой пост не про тот пост:)
А про собственную... Глу... человечность, назовём это так:)

В посте по ссылке есть тезис:

To put it another way, it is a design goal of the Application Service to host orchestration logic to allow lower-level components to become less coupled to one another.

—

Другими словами, Application Services предназначены для размещения логики оркестрации, что позволяет компонентам более низкого уровня быть менее связанными друг с другом.

Но я в 22-ом году (на 18-ом году коммерческой практики и примерно 5-ом году знания про Чистую архитектуру, ДДД, оркестрацию и сервисы приложений) всё равно изобрёл объектно-ориентированную декомпозицию. И пошёл делать по ней #project_e. И получил ровно, то, чего позволяют избегать сервисы приложений - высокую связанность между модулями-объектами.

Сколько ещё у меня таких "изобретений" из-за того что "смотрю в книгу, вижу фигу"? Вопрос риторический, конечно. Время покажет, всё что покажет - расскажу как на духу. Сегодня начал писать пост с ретро #project_r

PS>
И в топик "простых" CRUD приложений из комментов ко вчерашнему посту: в Overengineering in Onion/Hexagonal Architectures про них тоже тоже есть:

Like any tool, concentric architectures are not suitable for any software project. If the domain complexity of your problem is fairly low (CRUD-like), or if the challenge of your application is NOT in the complexity of its business rules, then the Onion/Hexagonal/Ports-Adapters/Clean Architecture might not be the best choice, and you might be better off with vertical slicing, anemic model, CQRS, or another type of architecture.

—

Как и любой другой инструмент, концентрическая архитектура подходит не для всех проектов. Если сложность предметной области вашей задачи довольно низкая (CRUDо-подобная) или если сложность вашего приложения заключается не в сложности его бизнес-правил, то архитектура Onion/Hexagonal/Ports-Adapters/Clean может оказаться не лучшим выбором, и вам, возможно, лучше использовать вертикальную архитектуру, анемичную модель, CQRS или другой тип архитектуры.

#posts@ergonomic_code #ergo_arch@ergonomic_code #ergo_approach@ergonomic_code

Привет!

С подачи @niktimf (Никита, спасибо) прочитал

https://habr.com/ru/articles/919168/
https://habr.com/ru/articles/919368/

Мне понравилось - сам расставил все лайки на Хабре и подписался на канал автора и вам рекомендую как минимум ознакомиться:)

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

В первом посте есть тезис:

Ну и завершим духоту следующим замечанием: [из результатов исследования] видно, что IT-Performance организации хоть и имеет связь с успехами организации, но явно слабую. С одной стороны, это весьма логично: было очень бы странно, если бы можно было облажаться с идеей, бизнес-планом, маркетингом, продажами, менеджментом, но иметь успешный бизнес чисто за счет крутых технарей. С другой стороны, это замечательно объясняет тот факт, что большинство компаний делает с точки зрения техники откровенный шлак и при этом имеют вполне себе прибыльные бизнесы.

В посте автор, судя по всему, говорит об архитектуре больших-огромных (500К+ строк?, десятки разработчиков) систем, а я могу это подтвердить для небольших-средних приложений (10-500к строк, 1-5 разработчиков).

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

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

И это противоречит тому, что и я сам пытался приземлить ЭП на деньги и ценность для бизнеса, и не раз встречал других разработчиков, которые оценивали/критиковали идеи/подходы вопросом "А что это даст бизнесу". И ответ, видимо - ничего. Как и все альтернативные технически упражнения.

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

Когда вы в последний раз приходили на проект и думали: какая удачная получилась архитектура, кто тот гений с зарплатой вдвое больше, чем у меня, что придумал этот алмаз? Я вот такого не припомню

— цитата из того же поста

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

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

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

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

#posts@ergonomic_code #philosophy@ergonomic_code

Те, у кого был такой опыт: расскажите, пожалуйста про эти проекты:)

Привет!

Результаты опроса оказались обескураживающими и отрезвляющими для меня.
Ещё вчера я был уверен на 146%, что написать код, который последователи не зачмырят невозможно и в опросе максимум ожидал 80 на 20 в пользу "нет".
А на деле оказалось, что возможно.

Вопрос в том как?

И я думаю в наших силах найти ответ на этот вопрос.
Я думаю, если мы проведём доморощенное исследование, соберём хотя бы те же 80 анкет о "хороших" и "плохих" проектах и сможем найти сильную корреляцию между какими-то атрибутами/характеристиками проектов и их высокой оценкой последователями - то это и будет ответом:)

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

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

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

Привет!

Подглядел в канале Давида Шекунца про конкурс (канал: @tg_contest_main) авторских каналов и тоже решил попробовать выйти из информационного пузыря:)

Приходите, читайте, голосуйте:) За кого голосовать - вы знаете :)