👋 Привет Пол (и привет всем)
Недавно я сходил на свою первую 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 из своего прикладного опыта, но вовсе даже не поэтому рекомендую ее к прочтению.

👋 Привет Пол (и все, кто интересуется новыми архитектурными подходами)

Сегодня я хочу поделиться своими впечатлениями от статьи про Cell-Based Architecture.

Сell-based Architecture (CBA)
— это подход, при котором система делится на независимые ячейки (cells), каждая из которых полностью самодостаточна и выполняет определенную бизнес-логику.

Основная идея
— каждая ячейка содержит все необходимые ресурсы для своей работы, что упрощает масштабирование и изоляцию проблем.

Статья приводит список преимуществ такой архитектуры над Микросервисной (MSA), но ряд из них выглядит спорным, как, например, тезис про самодостаточность ячейки.

Самодостаточность ячейки, как свойство, кажется мне довольно похожим на самодостаточность микросервиса.
Однако в MSA самодостаточность сервисов направлена на устранение краеугольной проблемы — распределённых транзакций.
В CBA же сама концепция объединения нескольких сервисов в одну ячейку порождает эту самую проблему, что загадочно выставляется преимуществом, хотя она сгубила бессчетное число микросервисов.

Если рассматривать обе архитектуры в контексте запуска в Kubernetes кластере, то единственная разница — в MSA Helm будет контролировать только один сервис, а в CBA несколько.

Поэтому, если подытожить первое впечатление, то кажется, что CBA — скорее маркетинговый ход AWS, поскольку это оптимизация именно для самого AWS.

А как вам кажется, есть ли реальные преимущества Cell-Based Architecture по сравнению с Микросервисами?

ЧИСТЫЙ КОД (Part 1)

👋 Привет Пол (и все, кто задумывается о чистом коде)

Семь месяцев назад я сменил работу, и теперь одна из моих ключевых задач — обучать и делиться экспертизой. И за это время мне часто приходилось отвечать на вопросы, так или иначе связанные с чистотой кода.

Что такое чистый код?

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

Сам подход подразумевает, что иногда важно придерживаться принципов, а иногда осознанно от них отходить.

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

P.S. А еще оказалось, что многие вещи делаются настолько бессознательно и интуитивно, что при необходимости передачи знания приходится буквально воссоздавать с нуля алгоритм действий.

Поэтому я был бы очень рад и благодарен, если вы поделитесь в комментариях своим опытом или мнениями под грядущими постами!

ЧИСТЫЙ КОД (Part 2)

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

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

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

1️⃣ Кто наши стейкхолдеры (технические и бизнес)?

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

2️⃣ Каковы архитектурные риски и ключевые качества системы?

Это понимание позволит валидировать каждое принимаемое решение.

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

3️⃣ Какой объем изменений ожидается в будущем?

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

4️⃣ Долгосрочная или краткосрочная ли ожидается поддержка?

— Долгосрочная → код должен быть гибким и легко поддерживаемым.
— Краткосрочная → можно принять больше компромиссов.

5️⃣ Насколько жесткие дедлайны?

— Сжатые сроки → приходится делать упрощенные решения.
— Гибкие сроки → можно уделить больше времени качеству.

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

По итогу: чем выше уровень неопределенности, тем выше шанс принять некачественное и неподходящее решение.

P.S. В следующих постах я хотел бы разобрать разные вариации контекстов и поразмышлять, какие решения можно принять на их основе. Буду рад вашим мнениям!

ЧИСТЫЙ КОД (Part 3)

Скажи свое мнение и беги: не откладывай на завтра то, что можно сделать послезавтра

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

Под профессиональный контекст это можно перефразировать как

Откладывай принятие важных архитектурных решений как можно дольше.

Оно же верно и в концепции чистого кода.

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

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

P.S. А какие принципы у вас есть в работе?

👋 Привет Пол (и все, кто любит полезные фичи IntelliJ IDEA)

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

А сейчас увидел отличный материал про Live Templates — тоже классная фишка для ускорения работы. Репостнул оригинал ниже ⬇️

🎯 Что сделал для себя по мотивам поста

Добавил несколько своих шаблонов для тестов:

@org.junit.jupiter.api.Test
void $NAME$_when$WHEN$_then$THEN$() {
    $END$

    var actual = $SUT_NAME$.$NAME$();

    var expected = $EXPECTED$;
    assertEquals(expected, actual);
}

@org.junit.jupiter.api.Test
void $NAME$_when$WHEN$_thenThrow() { $END$
    var actual = assertThrows($EXCEPTION$.class, () -> {
        $SUT_NAME$.$NAME$();
    });

    assertEquals($EXPECTED_MESSAGE$, actual.getMessage());
}

Отредактировал стандартный шаблон для тестов. Теперь метод создаётся сразу в формате, принятым моей командой:

@org.junit.jupiter.api.Test
void ${NAME}_when_then() {
    ${BODY}
}

Навигация для изменения стандартных шаблонов:
Command + N (macOS) / Alt + Insert (Windows)
→ три точки
→ Edit Template

🎥 Также очень рекомендую видео, где показано, как настраивать переменные Live Templates, например, указать default value или конвертацию в camelCase.

ЧИСТЫЙ КОД (Part 4)

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

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

Теперь спустимся на уровень конкретных примеров и подумаем, а как можно в разном контексте действовать.

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

🎯 Нам была поставлена задача:

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

Ответим на вопросы о контексте:

🧑🏻‍💻 Кто наши стейкхолдеры? Каковы их запросы и ожидания?

• Команда бизнеса — хочет предлагать клиентам уникальные условия, а потому ожидает гибкости решения в виде точечных настроек калькулятора и быстрого добавления новых вариантов комиссий. Однако на первом этапе считает достаточным просто заменить вендора.

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

• Финансовый контроль — косвенный стейкходлер, который заинтересован в точности расчетов и прозрачности начислений, чтобы исключить возможные ошибки.

⚠️ Каковы архитектурные риски и ключевые качества системы?

• Во время пиковой нагрузки могут возникать задержки обработки запросов
→ Требуется высокая производительность и масштабируемость системы, а именно способность обрабатывать большое количество расчетов в короткие сроки, а также сохранять этот параметр при росте нагрузки

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

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

• Калькулятор комиссий, скорее всего, будет зависеть от других сервисов (биллинг, CRM, внешние платежные системы)
→ Непродуманная работа с интеграциями может стать узким местом.

🛠 Какой объем изменений ожидается в будущем? Долгосрочная или краткосрочная ли ожидается поддержка?

• Значительный объем изменений

• Долгосрочная поддержка

⏳ Насколько жесткие дедлайны?

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

⸻ ⸻ ⸻ ⸻ ⸻

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

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

В нашем кейсе уже изначально мы можем предсказать, что и core, и integration слои будут сложными.

Интеграции — это больше техническая проблема, поэтому решать её нам легче — применяем гексагональную архитектуру. Со второй же проблемой так просто не получится, поэтому применяем мудрость из прошлого поста и просто откладываем решение до лучших времён. А текущую реализацию делаем максимально простой, но при этом не забываем про 100% покрытие core тестами, которые дадут нам уверенность при необходимости менять код по 50 раз в день.

Уже в дальнейшем, когда наберётся некоторая критическая масса кода в ядре, мы сможем его отрефакторить и реализовать onion / clean architecture / DDD.

💬 Как бы вы подступились к решению этой задачи? Делитесь в комментах!