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

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

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

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

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

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

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

Привет!

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

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

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

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

Привет!

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

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

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

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

Привет!

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

Пока я пилил #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

Привет!

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

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

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

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

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

Привет!

И пока:)

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

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

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

Привет!

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

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

#ide@ergonomic_code #tools@ergonomic_code

Привет!

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

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

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

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

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

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

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

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

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

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

Привет!

У нас в группе за последнюю пару недель было сразу два холивара на тему разделения на слой приложения и домена в 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

* - на самом деле не только репозитории, но и любые штуки с состоянием - клиенты внешних АПИ, очереди сообщений, мапы в памяти, сервисы отправки почты и сообщений в телеграм и т.д.
** - в случае если какую-то пару репозиториев надо позвать в нескольких операциях и этому действию можно дать вменяемое имя, оно оформляется в доменную операцию - класс, экземпляры которого создаются руками в классах операциях, а не ДИ-контейнером/composition root-ом.
Так же есть сложные ресурсы, инкапсулирующие нескольких простых. Например, если клиенту внешнего АПИ надо кэшировать в БД системы токен авторизации, то это реализуется тремя классами - верхнеуровневым ресурсом, ресурсом-клиентом внешнего АПИ и ресурсом-дао/репозом токенов. В это случае верхнеуровневый ресурс (и только он) может вызывать вложенные ресурсы.

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

Красивое