Краткая выжимка и иллюстрации также доступны в pdf

В прошедшую пятницу прошел ArchDays
Хотел бы поделиться своими мыслями и впечатлениями, а также тенденциями, которые уже давно волнуют архитектурное комьюнити

1️⃣ Диктатура VS Культура
Почти в каждом выступлении эта тема поднималась по несколько раз, но именно после доклада Петра Туголукова, кажется, все вопросы из зала были связаны с тем, как убедиться, что команды делают работу качественно, не косячат и не замалчивают проблемы. Здесь хочу сказать, что, когда я начинал свое погружение в архитектуру, я задавал такие же вопросы, и этот доклад еще раз помог мне провалидировать мысли и решения, к которым я пришел.
Во всех же вопросах из зала был общий базис в виде недоверия.

Недоверие к людям – следствие отсутствия понимания их принципов. Единая культура помогает нам с большей уверенностью полагаться на коллег и делегировать.

#arch #archday
@polyackov_ot

2️⃣ Устаревание документации
Много вопросов было про то, как бороться с устареванием документации и архитектуры.
Как я понимаю, тенденция ведет нас к принципу "Архитектура as code". А раз это код, значит на него нужно писать Юнит тесты 😁 Их очень воодушевляющий и уже работающий прототип (github) представил в докладе Руслан Сафин.

Это решение встраивается в GitLab-pipeline и сравнивает application.yaml, yaml конфигурацию K8S и plantUML диаграмму.

3️⃣ Единый Язык
Следующая неугасающая тенденция – единый язык (DDD). О нем на конференции также говорили много, но Евгений Хренов пошел дальше и представил всем в докладе свою простую и понятную методичку.

Важно не только качество конкретного имени, но и системность формирования всех имен

Вижу большую ценность, что благодаря предложенному Женей соглашению, можно не задумываться, как выбирать имена для сервисов, сущностей кубера, REST api, Kafka topics и баз данных. Таким соглашением легко могут пользоваться все команды независимо.

Единственный минус, это решение лишает возможности в кулачном поединке с ТехЛидом дать своему детищу имя super-puper-service-2000

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

Буду рад вашим лайкам!

#arch #archday
@polyackov_ot

Всем привет
Знакомьтесь — это разработчик по имени Пол.
Пол — senior, junior, middle, principle, lead, который возможно еще что-то не знает или, наоборот, так давно в разработке, что уже что-то забыл. Именно к нему мы будем обращаться в попытке что-то объяснить, а, заодно, и разобраться самим.

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

Добро пожаловать!

Привет, Пол — это мой первый опыт публичных выступлений.

Познакомься, это 15 новых лиц, которые присоединились к нашему комьюнити. И которые готовы вместе с тобой, мной и остальными подписчиками, все-таки, узнать что такое Java)

40 человек в пике, и 15 в онлайне после 5,5 часов. Звучит мощно, и это было действительно супер!

У нас не было плана, но была идея, и, чтобы с чего-то начать и растопить лёд, я спросил следующее:

1) Как можно к вам обращаться?
2) Какой опыт в Java от 0 до 3 ?
3) Что ожидаете от этой встречи?

Эти вопросы помогли мне взаимодействовать и делиться более релевантной для аудитории информацией.

Мы начали от базовых вопросов, затем перешли к TDD, затронули историю развития it и как это привело нас к микросервисам. А какие же микросервисы без DDD, поэтому обсудили еще и его.

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

Кажется, вышло продуктивно и полезно. Рад, что получился живой разговор на основе живого интереса. Уверен, что нужно продолжать и дальше, а всем присутствующим большое спасибо

Привет Пол (и привет всем)
Хочу поделиться недавним комментом из Merge Request, который будет интересен и тебе.

Кратко опишу задачу:
Мне нужно было слушать топик в Kafka, где могут быть сообщения, которые моей системе не нужно обрабатывать.

Для этой задачи я реализовал фильтр, давай посмотрим мой код ниже:

@Bean
public ConcurrentKafkaListenerContainerFactory<String, String> filterNonCurrentSourceSystemResponse(ConsumerFactory<String, String> consumerFactory) {
    var factory = new ConcurrentKafkaListenerContainerFactory<String, String>();
    factory.setConsumerFactory(consumerFactory);
    factory.setRecordFilterStrategy(record -> {
        var sourceSystemHeader = record.headers().lastHeader(KafkaConstants.SOURCE_SYSTEM_HEADER);
        var sourceSystemHeaderValue = new String(sourceSystemHeader.value());
        return !SourceSystemName.isCurrentSourceSystem(sourceSystemHeaderValue);
    });
    return factory;
}

На самом деле весь код читать и понимать не нужно, нам интересен фидбек к конкретной строке:

new String(sourceSystemHeader.value());

Для начала давай разберемся, что же здесь происходит:
🔸 sourceSystemHeader.value() возвращает byte[]
🔸 при конвертации в String каждый раз будет создаваться новый объект в heap
🔸 т.к. количество вариантов SOURCE_SYSTEM_HEADER сильно ограничено, возможно, для оптимизации работы с памятью стоит добавить интернирование в String Pool

Я так и поступил.

Пол и все-все-все, что думаете, стоит ли так помогать GC?
Также мы будем рады увидеть в комментах другие способы оптимизации работы с памятью.

PS: Хотел бы поделиться ссылкой, в ней довольно подробно и с примерами уже описаны оптимизации и String Pool. Думаю, вы сможете за 10-15 минут получить неплохой базис, и, при необходимости, погрузиться в эту тему глубже.

#String

👋 Привет Пол (и привет всем)
Недавно я сходил на свою первую Java конференцию в Лондоне.

В кулуарах мы занимались типичными активностями — травили байки и мерились, кто тут самый старпер. Всех уел разраб, первой средой разработки которого была еще IBM VisualAge (что-то древнее, что умерло 20+ лет назад).

Но дальше он начал рассказывать про свой опыт использования 4х разных AI в написании кода, и мне порвало шаблон. Все вокруг начали наперебой делиться опытом , а мне же оставалось только шаркнуть ножкой 🤡 Получается, единственный старпер здесь я

По всем законам конформизма я задумался:
с чем же и мне может помочь AI❓

⚠️ Сегодня на проде у меня потерялся запрос. Как оказалось, причиной была самая популярная ошибка в Java.

Я получил сообщение c номером счета, а метод ниже должен был вернуть валюту счета:

public String getCurrencyName(String account) {
    var currencyCode = account.substring(5, 8);
    return currencyCodeNameMap.get(currencyCode);
}
// пример данных в currencyCodeNameMap
//    810, RUR
//    840, USD
//    826, GBP
}

Но так получилось, что счет пришел битый, с кодом, которого не было в currencyCodeNameMap. Поэтому .get() вернул null, а где-то позже все и сломалось.

💡 Хорошим решением было бы ловить такие ошибки на уровне валидации полученного сообщения. С вопросом о том, как это лучше сделать, я решил выйти не в Интернет, а написать Machinet AI.

Примерно за 10 минут, большая часть из которых ушла на объяснение, что account состоит из 3х групп и что есть enum CurrencyType с уже нужными кодами, я получил такое решение:

String accountRegex = "\\d{5}(810|840|826|)\\d{12}";

Ответ почти устроил, ведь регулярку будет легко добавить в @Pattern.
Но оставался риск забыть поправить и ее при добавлении значения в enum.

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

а было бы интересно задать те же вопросы GitHab Copilot и сравнить...

Успех! Повторил первые два промта и точно также попытался скормить ему enum. Получил почти готовое решение (итоговая версия будет в комментах).

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

За 10 минут я получил ответ, освежил в памяти regex, чуть лучше начал понимать, как использовать AI.

🧠 Как итог, Copilot оказался намного умнее:
1. С первого сообщения понял, как нужно исползовать enum
2. Без подсказок решил проблему консистентности
3. Выдал готовое решение меньше, чем за 1 минуту (против 10-15 у Machinet AI)

🪦 Из минусов:
Copilot умер и уже часов 8 не подает признаков жизни
Вместе со смертью потер всю историю запросов

По общим ощущениям показалось, что Copilot больше заточен на работу с кодом, поскольку для Machinet AI пришлось руками вырезать из enum коды валют, несколько раз переписывать весь промт, тк иначе он не мог понять, что нужно сделать. Но, главное, каждый AI дал возможность сгенерировать regex декларативно.

Ну, и, как мне раньше советовал ChatGPT

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

Поделитесь своими любимыми способами использовать AI?
И, что вы думете, можно ли использовать технологию, которая каждый раз на один и тот же вопрос отвечает по-новому?

👋 Привет Пол (и привет всем)

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

В контексте темы хотел бы поделиться новым выпуском от той же студии подкастов — "От rename к intellij idea"

Почему выпуск понравился мне и возможно будет интересен и вам?

»» Во-первых, никогда не думал, что можно жить без Rename, но когда-то это был отдельный плагин для JBuilder.
Появление Rename было настолько значимым, что сам Мартин Фаулер написал в Crossing Refactoring's Rubicon, что программирование больше не будет прежним.

»» Во-вторых, было крайне интересно послушать от Макса Шафирова (ex-CEO JetBrains) историю роста JetBrains от 10 энтузиастов до корпорации, владеющей десятком лучших сред разработки для ключевых языков.
А еще понравились идеи об установке AI ассистентов в контуре и на серверах компаний, чтобы избежать юридических рисков у заинтересованных в использовании клиентов.

👋 Привет Пол (и привет всем)

Последние несколько месяцев я проверяю работы студентов-джавистов на курсе по Clean Architecture.

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

Одна из таких зон роста – работа с Exception, а именно:

🔸 Использование более конкретного типа ошибки вместо абстрактного
🔸 Добавление детальной информации, текста о контексте ошибки
🔸 Написание качественного теста, который будет способен проверить оба пункта выше

Разберём шаг за шагом на примере, как можно улучшить код.

Дано ⬇️

if (coordinate < MIN_COORDINATE_VALUE || coordinate > MAX_COORDINATE_VALUE) {
    throw new RuntimeException("wrong coordinate");
}

Что можно улучшить на основе выделенных выше пунктов:

1️⃣ Вместо абстрактного типа ошибки RuntimeException полезно воспользоваться более конкретным.

Мы видим, что в коде идёт речь про валидацию входных параметров, а потому имеет место более подходящий для ситуации тип IllegalArgumentException

✅ Более конкретный тип ошибки, даже без текста, уже даёт частичное понимание контекста и снижает риск обработки другой ошибки, которая также является наследником базовой.

2️⃣ Выбрав тип ошибки, необходимо определиться, что важно написать в ее тексте.

✅ Хороший message, отвечает на вопрос:

Почему произошла ошибка?

Чтобы ответить на данный вопрос, текст ошибки должен содержать описание -- нарушение чего приводит к возникновению подобной ошибки.

А также пояснение, что было передано в метод и привело к нежелательному результату:

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

После внесения улучшений из пункта 1 и 2 код может выглядеть следующим образом ⬇️

if (coordinate < MIN_COORDINATE_VALUE || coordinate > MAX_COORDINATE_VALUE) {
    throw new IllegalArgumentException("Expected coordinate should be between '%d' and '%d'. Actual coordinate is '%d'."
    .formatted(MIN_COORDINATE_VALUE, MAX_COORDINATE_VALUE, coordinate));
}

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

Также стоит всегда писать текст ошибки на английском, так как код будет запускаться на проде, и будет неприятно получить
?????? ?????? ?????? ?????? ? ?????? ?? '1' ?? '10'. ?????? ?????? ? '0'.

3️⃣ Negative path не менее важен, чем happy path, поэтому хорошая ошибка и ее текст должны быть закреплены хорошим тестом.

@Test
void create_whenCoordinateIsNotCorrect_thenThrow() {
    var actual = assertThrows(IllegalArgumentException.class, () -> Location.create(0, 2));


    assertEquals("Expected coordinate should be between '1' and '10'. Actual coordinate is '0'.", actual.getMessage());
}

Буду благодарен, если вы поделитесь в комментариях, что на ваш взгляд должно быть или не быть в хорошей ошибке!

#exception

Привет Пол (и привет всем)

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

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

С начала года уже случилось много интересного, например, две Q&A сессии с внешними комьюнити разработчиков (про первую я рассказал тут). За организацию и моральную поддержку большое спасибо моем другу и коллеге @sliceoflife0101

Сейчас же мы с моим partner in crime @diakaiuti дорабатываем последние штрихи нескольких нетривиальных для меня образовательных и дискуссионных форматов, так что уже совсем скоро расскажем what we do in the shadows.

P.S. Фраза "Пол — это Java", обросшая внутренними шутками и смыслами, когда-то стала названием этого канала. Думаю, новое фото отлично отражает ее многомерность.

Привет Пол (и привет всем)

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

Игорь Овчинин и Евгения Медникова, представляющие творческий тандем небезразличных аналитиков, тоже это понимают, а потому написали подробную статью, закрывающую основные вопросы простым и понятным языком.
А я помог наполнить ее good practice из своего прикладного опыта, но вовсе даже не поэтому рекомендую ее к прочтению.