ЧИСТЫЙ КОД (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.

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

Сегодня идея меня встретила так

🎙️ Ищем людей для короткого исследования!

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

Интересны все, кто:
1. За последний год проходил платные курсы по программированию или смежным темам (не важно, онлайн/оффлайн, длинные/короткие).
2. Или использовал AI (ChatGPT, Copilot и др.) для учёбы, практики или экспериментов.

Если был опыт обеих активностей, то ещё лучше 🙌

🗣️ Исследование пройдёт в формате беседы/интервью и займёт примерно 40-45 минут.

Если вы были бы рады поучаствовать, напишите, пожалуйста в личку или оставьте сообщение в комментариях. Спасибо!

Java 25 — новая LTS 🎉

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

На прошлой неделе вышла Java 25 — свежая LTS-версия.

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

✍️ Букавы писать не любим

• JEP 512: Compact Source Files and Instance Main Methods — о многословности Java слагаются легенды, именно поэтому об этом JEP’е мне написало особенно много друзей, которые с Java никогда не работали :)
На первый взгляд JEP выглядит как пустяк для текущих джавистов, но для привлечения новых пользователей может являться конкурентным преимуществом.

• JEP 511: Module Import Declarations — забавный JEP, полезен скорее для прохождения собеседований. В реальной жизни вряд ли пригодится — текущие чекстайлы всё равно запрещают import *.

🔧 Полезные улучшения

• JEP 513: Flexible Constructor Bodies — наконец можно валидировать параметры до вызова родительского конструктора.

• JEP 519: Compact Object Headers — экономия памяти.

• JEP 514 и 515: AOT Ergonomics + Method Profiling — оптимизация работы приложений прямо из коробки.

📝 Итог

Фич, которые можно «потрогать руками», не так уж много. Но меня радует, что Java продолжает развиваться.

Мне близок подход, что Java не тащит фичи из других языков «во что бы то ни стало», а тщательно отбирает опыт и адаптирует под свою культуру. А если не получается — спокойно отказывается (как это было с pattern matching).

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

👋 Привет, Пол. И привет всем.

Недавно на конференции я разговорился с разработчиком, которого явно раздражало, что на работе его заставляют использовать AI:

"Я не для этого учился computer science, чтобы AI писал код за меня".

И вообще

"Мне нравится писать код самому".

Этот разговор натолкнул на мысль, что у меня самого отношение к AI неожиданно смешанное. Я оставлю за рамками поста вопросы вроде насколько AI эффективен, какая модель лучше и где он реально приносит пользу — меня зацепило другое. В какой-то момент я стал замечать, что при решении некоторых задач периодически появляется странное чувство, что-то между грустью и разочарованием.

После пары сеансов саморефлексии стало понятно, что меня расстраивает вообще даже не сам факт использования AI — скорее, наоборот, мне нравится, что AI может помочь быстрее найти варианты, заметить риски и в итоге принять более качественное решение. Проблема в другом: иногда вместе с этим приходит другое ощущение, будто работу сделал не я, а агент, ну а я просто стоял рядом. И вот это осознание стало для меня важнее всех споров про “заменит / не заменит”, потому что, кажется, нам важно не только получить результат, но и чувствовать, что это именно наш результат.

И тут же всплыло ещё одно наблюдение, напрямую связанное с этим ощущением — фраза "я погуглил / я поисследовал" воспринимается мной гораздо приятнее, чем "я спросил у GPT" или "GPT мне сказал". Хотя по сути во многих случаях это просто про разные интерфейсы для работы с информацией, поэтому все еще похоже, что многое упирается в то, как именно мы воспринимаем своё участие в процессе.

Если напоминать себе, что AI — это всё-таки инструмент, а не самостоятельный автор, безусловно, становится проще принять происходящее. Да, очень мощный инструмент и иногда почти пугающе полезный, но без нашего запроса, без нашего контекста, без нашего выбора и без нашей оценки ответа результат всё ещё не “возникает сам", просто форма нашего участия меняется.

P.S. Забавно, что очень похожую фрустрацию я когда-то испытывал, когда начал руководить группой инженеров. Тогда тоже появлялась мысль: "Я ничего не сделал — всё сделали без меня". Похоже, в обоих случаях неприятно не отсутствие действий, а потеря привычного ощущения прямого вклада.