Эргономичный код

Привет!

У нас в группе за последнюю пару недель было сразу два холивара на тему разделения на слой приложения и домена в DDD. Я смотрел на них и про себя думал, что это очень попахивает искусственной/побочной сложностью.

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

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

И для выбора места размещения кода у меня есть два подхода на выбор разработчика.
1. снизу вверх. Код помещается на максимально низкий уровень, где доступно требуемое состояние. Трансоформация/вычисление на базе одной сущности помещается рядом с ней. Код, меняющий только один репоз помещается рядом с этим репозом. Код трансформирующий/вычисляющий на базе нескольких агрегатов/сущностей помещается в слой приложения рядом с операцией, которая его использует или в общий код пакета, содержащего все операции, которые его используют. Код работающий с несколькими ресурсами помещается аналогично максимально близко к операции(ям), его использующим
2. сверху вниз. Код помещается на самый высокий уровень, доступный всем его клиентам. Этот подход, на самом деле имеет смысл только для трансформаций сущностей и тут по большому счёту только два варианта. Трансформация одной сущности, которая используется только в одной операции помещается рядом с ней. Если он нужен нескольким операциям - помещается рядом с сущностью.

Я обычно придерживаюсь подхода снизу вверх, вынося трансформации выше если:
1. она явно относится к одной конкретной операции
2. вокруг сущности накопилось более 10 методов, многие из которых используются только в одной операции

Кроме того у меня есть пачка защитных-правил, которые предотвращают превращение реализации в кровавое месиво бизнес-логики и ввода-вывода и разных уровней абстракции:
1. каждая технология должна быть инкапсулирована либо в порте, либо в ресурсе. При том в случае ресурса инкапсуляция означает, что технология не фонит в API ресурса. В АПИ репозитория не должны упоминаться таблицы, колонки, внешние ключи и т.п. В АПИ хттп клиента внешней системы не должны упоминаться хттп методы, заголовки, куки, мультипарты и т.д.
2. Ни порты, ни операции, ни репозитории** не могут вызывать друг друга
3. метод порта не может вызывать более одной операции или метода ресурса
4. метод порта может содержать только одну конструкцию ветвления (if/when/switch) для выбора представления ответа
5. метод, который прямо или косвенно содержит ввод-вывод (методы портов, операций и репозиториев) может иметь когнитивную сложность не более 4
6. классы поведения (операции, ресурсы) должны иметь не более 7, край 10 зависимостей. А в идеале - до 5

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

Подробнее об этом у меня написано в заготовке статьи Эргономичная архитектура

#ergo_approach@ergonomic_code #ddd@ergonomic_code

Эргономичный код pinned «Привет! Свершилось!🎉🎉🎉 Наша исследовательская группа — я, @goloshchapov и @VektorAB — закончила разработку анкеты и приглашает вас поучаствовать в опросе! Напомню кратко цель исследования: выяснить, как делать проекты так, чтобы последователи сочли их …»

Привет!

Свершилось!🎉🎉🎉

Наша исследовательская группа — я, @goloshchapov и @VektorAB — закончила разработку анкеты и приглашает вас поучаствовать в опросе!

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

Как гипотетический пример: в 60% поддерживаемых проектов применялся DDD и в то же время он применялся только в 20% неподдерживаемых проектов. Из чего можно будет сделать вывод, что применение DDD повышает вероятность высокой оценки поддерживаемости вашего кода последователями.

Или гипотетический пример несущественной характеристики: и в поддерживаемых, и в неподдерживаемых проектах микросервисы и монолиты использовались в 50% случаев. Из этого можно сделать вывод, что архитектура системы не влияет на восприятие поддерживаемости вашего кода последователями и при выборе архитектуры можно не учитывать аспект поддерживаемости.

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

Поэтому нам крайне важно собрать как можно больше исходных данных, чтобы выводы были статистически обоснованы и наш «среднестатистический разработчик» был репрезентативен. Соответственно, нам крайне важно, чтобы вы сами заполнили анкету, а также рассказали о ней всем своим знакомым разработчикам-бэкендерам.

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

Дальнейший план исследования:
1. Примерно до 17 августа заниматься пиаром анкеты - ходить по знакомым блогерам с просьбой дать ссылку и написать небольшой пост на Хабр
2. В течение месяца после окончания пиар активностей собираем данные
3. Примерно 17 сентября закрываем анкету
4. Анализируем данные и пишем отчёт. На это, думаю, уйдёт 1-3 месяца
5. Публикуем сырые данные и наш отчёт

Потратьте 20 минут на благо всего сообщества разработчиков - заполните анкету сейчас:)

Привет!

Я из лесу вышел - а тут такоооое!

Если вы как и я посматриваете на VS Code из-за тормозов или проблем с подпиской в IDEA, но вас среди прочего останавливало отсутствие DB Client-а, то вам может быть интересно, что MS недавно выпустили официальный плагин для PostgreSQL. Пока в превью.

#ide@ergonomic_code #tools@ergonomic_code

Привет!

И пока:)

Мы сегодня запустили бета-тест анкеты и я отчалил в отпуск:)

Поэтому в канале будет неделя-две тишины.

Всем чмоки в этом чатике 😘😄

Привет!

Вести с исследовательских полей:)

Заканчиваем полировку вопросов, закинул на ревью дипсику, в рассуждениях он пишет:

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

А ответ начинается с

Это комплексный и хорошо структурированный опросник для исследования поддерживаемости бэкенд-кода!

И к слову, про реальную обратную связь. И про то, что мне не дают покоя лавры анкл Боба:)

Наше исследование идёт своим чередом, и там между делом зашла речь про анкл Боба. В частности, что его идеи не ложатся на реальную практику. Я высказал предположение, что анкл Боб последние лет 20 не участвует в реальной разработке. А потом спросил у гопатыча, дипсика и алисы. Дипсик и алиса подтвердили, гопатыч соврал - сослался сюда и сказал что реальный опыт есть, но по ссылке ничего об этом не написано.

Короче, не слушайте анкл Боба, слушайте меня - у меня каждая идея выстрадана и опробована в коммерческой практике:)

#ergo_approach@ergonomic_code #solid@ergonomic_code #clean_architecture@ergonomic_code

Привет!

Третья большая новость наконец дозрела - я утряс все формальности и возобновил работу над Проектом Э!

Пока я пилил #project_r@ergonomic_code, заказчик пилил новый девайс, который делает замеры постоянно. И после его внедрения, нагрузка поднимется с ~3 измерений на пользователя в день до ~700.
А в самом оптимистичном сценарии - дорастёт до 50 RPS. Это ещё не хайлоад, конечно, но уже достаточно серьёзная нагрузка, которая не простит откровенно неэффективных решений.

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

И на мой взгляд, это очень крутая новость для ЭП. Это значит, что у меня будет реальная обратная связь из первых рук о том, как ЭП масштабируется и по размеру проекта (сейчас - 40k строк Котлин-кода и 72 таблицы) и по RPS.

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

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

Во-первых, за 1.5 года в продовый код пробралось несколько циклов. И это при том, что я часа 4 потратил на то, чтобы написать максимально строгий Арч-юнит тест. Но это была меньшая из проблем - их я разорвал за несколько часов.

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

В общем если вы делаете модульный монолит, и хотите иметь возможность быстро выносить модули в отдельные сервисы - не лениесь как я и заводите для них сразу отдельные модули

#project_e@ergonomic_code #ergo_approach@ergonomic_code

🤩 Свежие возможности Amplicode

В недавних обновлениях Amplicode появились два КРУПНЫХ блока нововведений — HTTP Client и Database Client.

Чтобы упростить изучение этих фич, мы создали два новых лендинга на сайте, где вы найдете короткие "How-to" видео с демонстрацией возможностей:

– ConneKt — HTTP-клиент в вашей IDE
– Database Client от Amplicode — управляйте БД прямо из IDE

P.S. К посту прикреплено одно из таких видео: "Просмотр структуры базы данных".

OpenIDE + Amplicode сделали мощную заявку на то, чтобы я переехал на них, когда очередной EAP IDEA закончится. Как минимум попробую.

Привет!

Шуточка за триста: что общего у программистов и программистов-исследователей? И те, и другие факапят сроки.

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

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

Привет!

Вести с исследовательских полей.

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

Всего нагенеряли 124 вопроса:
1. 6 про респондента (возраст, пол и т.д.)
2. 19 про "демографию" проекта (возраст, размер и т.д.)
3. 6 про "демографию" респондента на проекте (грейд, время работы и т.д.)
4. 93 про устройство проекта (архитектура, применение различных принципов, тесты, доки и т.д.).

Следующий этап - критический анализ нагенеренных вопросов

И я официально объявляю о начале работы над исследованием "Характеристики поддерживаемых кодовых баз бакэндов"!

Решился я во многом благодаря тому, что эту затею решили поддержать два человека.
Представляю наших героев:
- Алексей Голощапов. 11 лет занимается коммерческой разработкой, сейчас работает техлидом в финтехе.
- Виктор. 7 лет разрабатывает по на Java и Kotlin, сейчас работает тимлидом.

— так что у нас набралась исследовательская группа из трёх человек:) Ребята, спасибо вам огромное.

Цель исследования — найти характеристики кодовых баз, часто встречающиеся в проектах, которые новые разработчики сочли поддерживаемыми и редко встречающиеся в неподдерживаемых проектах. И на основе этого понять как делать проекты так, чтобы ваши последователи сочли их поддерживаемыми. Либо увидеть там белый шум и таки убедиться в том, что поддерживаемость проекта не зависит от того, как он написан:)

Так как мы все это будем делать в первый раз, коммитаться на сроки не будем. Но постараемся до 11 июля опубликовать анкету, а результаты анализа и сырые данные опубликовать в сентябре.

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

В общем, стей тюнед, возможно месяца через три вы узнаете обоснованный ответ на вопрос "Как писать поддерживаемые кодовые базы?" :)

Привет!

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

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

Привет!

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

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

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

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

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

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

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

Привет!

С подачи @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