Пол — это Java

👋 Привет Пол (и все, кто интересуется улучшением процесса тестирования) Сегодня я хочу поделиться с вами подходом к работе с тестовыми данными, который я активно использую каждый день. Я храню тестовые данные в JSON-файлах и написал библиотеку для работы с ними. Давайте разберёмся, почему это так удобно и как это может упростить вашу жизнь. Преимущества подхода: 1️⃣ Наглядность данных На мой взгляд, JSON-файлы гораздо нагляднее, чем использование билдеров в коде. Данные можно легко читать и редактировать. 2️⃣ Понятность данных для стейкхолдеров Один из ключевых плюсов вытекает из предыдущего пункта: на прошлом проекте я мог прямо на встрече с бизнес-стейкхолдерами изменять тестовые данные в JSON-файле и после встречи начать править код. 3️⃣ Лаконичность тестов В тестировании есть замечательное правило: "Тест должен охватываться одним взглядом", что дает возможность использовать тесты как спецификацию. Вынесение данных в JSON позволяет свести их представление в тесте к одной строке. Такой подход помогает абстрагироваться от подготовки тестовых данных и сосредоточиться на главной ответственности тестов — непосредственном тестировании. 4️⃣ Работа с большими и сложными запросами JSON позволяет хранить сложные структуры данных, которые максимально приближены к тем, что используются в боевой среде и без излишней громоздкости. 5️⃣ Легкость дебага В случае необходимости можно взять JSON с боевой среды и использовать его для отладки проблемы прямо в юнит-тестах. 6️⃣ Интеграция с IDEA Еще одно удобство заключается в том, что с помощью IntelliJ IDEA можно легко навигироваться из теста прямо в JSON-файл. Это значительно ускоряет работу, ведь вы можете быстро переходить к данным, менять их и сразу видеть результат в тесте. (Скрин приложу в комментариях) Однако у такого подхода есть и свои недостатки: — Накопление неиспользуемых данных Со временем в JSON-файлах могут накапливаться лишние поля, которые перестали использоваться в коде. Это усложнит чтение и поддержку т

👋 Привет Пол (и все, кто интересуется улучшением процесса тестирования) Как и обещал, рассказываю о своей библиотеке для работы с тестовыми данными в формате JSON, которая закрывает недостатки подхода, описанного ранее, и делает тестирование еще удобнее. Когда-то она начиналась с 2х простых методов getJson и getObject, и я дорабатывал и улучшал ее на протяжение последних 3х лет, пока не пришел к формату, которым с удовольствием делюсь с вами. Мой репозиторий: polyackov-test-util Проблемы подхода, которые решает моя библиотека: 01. Накопление неиспользуемых данных Со временем в JSON-файлах могут накапливаться лишние поля, которые перестали использоваться в коде. Библиотека помогает выявить такие лишние поля благодаря настройке: mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, true); 02. Некорректные данные Данные в JSON-файле могут не соответствовать актуальной валидации. В библиотеке есть методы getValid***, которые провалидируют данные перед их использованием, обеспечивая их корректность. 03. Локализация ошибок Когда тесты ломаются из-за некорректных JSON-данных, они завершаются не как Failed (красные), а как Ignored (серые). Это помогает локализовать причину проблемы и точно указывает на ошибку в тестовых данных, а не в самом тесте. *️⃣Дополнительно в репозитории можно найти тесты, которые демонстрируют ключевые особенности работы с библиотекой. Это позволит быстро познакомиться с ее возможностями и начать использовать в своих проектах. Кроме того, даже если вы не используете Spring или Jackson, всегда можно адаптировать библиотеку, заменив компоненты на привычные. Надеюсь, моя библиотека станет полезной вам в работе, так же, как стала полезной мне, и поможет сделать тесты понятными, а данные актуальными и корректными. Буду благодарен, если поделитесь своим опытом и отзывами и покликаете на звездочку!

👋 Привет Пол (и все, кто любит чистый код) Хочу обсудить с вами решение, которое, на мой взгляд, облегчает восприятие кода и улучшает его читаемость. Дядюшка Боб в своих книгах неоднократно критикует такие подходы к именованию классов, как использование префикса I для интерфейсов и постфикса Impl для их реализаций: Префикс I, столь распространенный в старом коде, в лучшем случае отвлекает, а в худшем — передает лишнюю информацию. От префикса I я отказался довольно быстро, но отказаться от постфикса Impl, честно говоря, было куда труднее. Лишь спустя время, когда я настроил цветовую схему в IntelliJ IDEA, я полностью перешел на более лаконичный подход без "синтаксических костылей". Настройка цветовой схемы стала для меня must-have в разработке по следующим причинам: 01. Легкость восприятия кода Используя цвета для разных типов классов, я сразу визуально понимаю, какой тип объекта передо мной. Это особенно удобно в больших проектах, где легко потеряться в многочисленных классах и интерфейсах. Цвета моментально привлекают внимание и позволяют "считывать" структуру кода без необходимости изучать его подробности. 02. Отказ от синтаксического сахара Как мы уже обсудили ранее, префиксы I & Impl — это по сути избыточная информация, которая засоряет код. В идеале, имя класса должно быть самоочевидным. Но, будем честны, отличать интерфейсы, абстрактные классы и их реализации — это очень удобно. И вот тут как раз цвета приходят на помощь в виде компромиссного решения. *️⃣ Дополнительное преимущество: Если у вас больше нет возможности использовать I & Impl, это предотвращает возникновение таких имен, как Service & ServiceImpl. Вместо этого вы столкнетесь с ситуацией, где интерфейс и его реализация имеют одинаковые имена — например, Service & Service. Такой подход еще раз напоминает про ответственность (Single Responsibility) классов. Благодаря этому вы назовете свои классы более точно или даже решите отказаться от избыточного интерфейса, задавшись вопросами:

⚙️ Как настроить цветовую схему в IntelliJ IDEA В предыдущем посте я делился своими выводами по преимуществам использования цветовых схем в коде. Небольшой tutorial, как эти настройки применить: » » Откройте Settings -> Editor -> Color Scheme -> Java. » » Найдите разделы Interface, Abstract class и Enum. » » Установите удобные вам цвета для каждого типа класса. Моя цветовая схема: Interface — #88E062 (зеленый оттенок) Abstract class — #66A8E9 (голубой оттенок) Enum — #EBC4FF (пастельно-фиолетовый) Record — #FFB86C (янтарный/персиковый) Со временем цветовая схема становится естественной частью процесса работы с кодом. Она упрощает чтение, и нам не нужно каждый раз вчитываться в названия или проваливаться в класс — мы просто ориентируемся по цветам. А какие инструменты или фичи IntelliJ IDEA помогают вам? Делитесь в комментариях! #intellijideafeature

ЧИСТЫЙ КОД (Part 1) 👋 Привет Пол (и все, кто задумывается о чистом коде) Семь месяцев назад я сменил работу, и теперь одна из моих ключевых задач — обучать и делиться экспертизой. И за это время мне часто приходилось отвечать на вопросы, так или иначе связанные с чистотой кода. Что такое чистый код? Это самый базовый вопрос, на который, тем не менее, нет простого ответа. Нельзя просто следовать чек-листу и гарантировать, что код при этом станет чистым. Сам подход подразумевает, что иногда важно придерживаться принципов, а иногда осознанно от них отходить. В следующих постах мне хочется разобрать и порефлексировать, как именно я принимаю такие решения. Я покажу свою логику, постараюсь объяснить, на чем она основана, и между какими вариантами я привык выбирать в реальной разработке. P.S. А еще оказалось, что многие вещи делаются настолько бессознательно и интуитивно, что при необходимости передачи знания приходится буквально воссоздавать с нуля алгоритм действий. Поэтому я был бы очень рад и благодарен, если вы поделитесь в комментариях своим опытом или мнениями под грядущими постами!

ЧИСТЫЙ КОД (Part 2) 👋 Привет Пол (и снова привет всем) Обычно, когда говорят про чистый код, обсуждают размер методов, длину названий или форматирование. Но я убежден, что чистый код начинается задолго до того, как будет написана первая строка. Перед тем как писать код, важно все же понять контекст, в котором он будет существовать. Для этого я задаю себе (и коллегам) несколько ключевых вопросов: 1️⃣ Кто наши стейкхолдеры (технические и бизнес)? Стейкхолдеры, в свою очередь, помогут нам ответить на вопросы ниже. 2️⃣ Каковы архитектурные риски и ключевые качества системы? Это понимание позволит валидировать каждое принимаемое решение. Примером риска может являться утечка клиентских данных, а качеством системы в таком случае является безопасность. 3️⃣ Какой объем изменений ожидается в будущем? — Значительный → стоит искать более продуманное решение, которое позволит в будущем более удобно добавлять новые функции или изменять старые. — Малый → можно позволить себе решение более простое, прямолинейное и быстрое по срокам реализации. 4️⃣ Долгосрочная или краткосрочная ли ожидается поддержка? — Долгосрочная → код должен быть гибким и легко поддерживаемым. — Краткосрочная → можно принять больше компромиссов. 5️⃣ Насколько жесткие дедлайны? — Сжатые сроки → приходится делать упрощенные решения. — Гибкие сроки → можно уделить больше времени качеству. Ответы на эти вопросы могут быть зафиксированы в аналитике к задаче или существовать только в головах команды. Но чем больше информации удастся собрать, тем лучше. По итогу: чем выше уровень неопределенности, тем выше шанс принять некачественное и неподходящее решение. P.S. В следующих постах я хотел бы разобрать разные вариации контекстов и поразмышлять, какие решения можно принять на их основе. Буду рад вашим мнениям!

ЧИСТЫЙ КОД (Part 3) Скажи свое мнение и беги: не откладывай на завтра то, что можно сделать послезавтра Звучит как сомнительный совет, однако я убежден, что это один из ключевых принципов качественной архитектурной работы. Под профессиональный контекст это можно перефразировать как Откладывай принятие важных архитектурных решений как можно дольше. Оно же верно и в концепции чистого кода. Это не значит избегать решений и ответственности вовсе. Скорее наоборот, это значит принимать только те решения, без которых невозможно двигаться дальше прямо сейчас. Остальные же будет дальновиднее оставить на момент, когда появится больше данных о контексте задачи (про план сбора контекста я писал в посте выше). Если к моменту принятия решения информации не прибавится, мы со спокойной душой возьмем в работу изначальные идеи. Но если контекст дополнится, новое решение будет осмысленнее и качественнее, что в долгосрочной перспективе окажется выгоднее. P.S. А какие принципы у вас есть в работе?

ЧИСТЫЙ КОД (Part 4) 👋 Привет Пол (и привет всем) В одном из прошлых постов мы говорили на тему вариации контекста, формирующего решения разработчика. Теперь спустимся на уровень конкретных примеров и подумаем, а как можно в разном контексте действовать. 💼 Представим, что мы работаем в крупной корпорации N, где есть ресурсы на реализацию максимально качественных решений. 🎯 Нам была поставлена задача: Разработать калькулятор комиссий, который заменит менее гибкое и производительное вендорское решение. Ответим на вопросы о контексте: 🧑🏻‍💻 Кто наши стейкхолдеры? Каковы их запросы и ожидания? • Команда бизнеса — хочет предлагать клиентам уникальные условия, а потому ожидает гибкости решения в виде точечных настроек калькулятора и быстрого добавления новых вариантов комиссий. Однако на первом этапе считает достаточным просто заменить вендора. • Команда поддержки — недовольна сложностью текущей системы, где в случае ошибок трудно разобраться в причинах и найти корректный способ исправления. • Финансовый контроль — косвенный стейкходлер, который заинтересован в точности расчетов и прозрачности начислений, чтобы исключить возможные ошибки. ⚠️ Каковы архитектурные риски и ключевые качества системы? • Во время пиковой нагрузки могут возникать задержки обработки запросов → Требуется высокая производительность и масштабируемость системы, а именно способность обрабатывать большое количество расчетов в короткие сроки, а также сохранять этот параметр при росте нагрузки • Ошибки в расчетах могут приводить к финансовым потерям → Важна целостность данных, учет атомарности операций, работа с округлениями и защита от ошибок интеграций. • Бизнес ожидает, что со временем появятся новые требования → Система должна обладать расширяемостью. Если изначальная архитектура не учитывает возможность модульного расширения, стоимость доработок может вырасти в разы. • Калькулятор комиссий, скорее всего, будет зависеть от других сервисов (биллинг, CRM, внешние платежные систе

📚 Время пробовать новые форматы, а потому мы с коллегами анонсируем запуск ридинг-клуба "Пол — это Java" 📚 В чем особенность формата, и почему мы ему уже рады? • Каждая встреча клуба будет ознаменована дискуссионной темой из профессиональной жизни разработчика, на которую есть неоднозначные точки зрения в статьях и литературе. Мы заранее подберем наиболее ключевые и интересные работы по теме для ознакомления. Они не будут слишком большими, чтобы все участники успели подготовиться! • Встречи будут в формате живой модерируемой дискуссии, которая поможет систематизировать знания, посмотреть на знакомые вещи под новым углом и обменяться реальным опытом. • Все это делает формат прекрасным как для тех, кто еще ничего знает о теме, так и для погруженных: ✔️Начинающие познакомятся с современными теориями подходами, смогут перенять живой опыт более опытных участников. ✔️Опытные осмыслят и отрефлексируют знания, обменяются инсайтами с другими профессионалами. ☕️Тема первой встречи: Роль архитектора в Agile-командах ✔️Мы проанализируем подходы к распределению архитектурных задач в командах ✔️Подискутируем, как меняется понимание архитектуры в условиях гибкой разработки ✔️Обсудим, нужен ли архитектор в классическом смысле или команды могут справляться сами, полагаясь на собственную экспертизу ⏳ Когда: 25 мая (воскресенье) 12:00–15:00 (по Мск, GMT +3) онлайн 📼 Записаться можно здесь: 📼 https://forms.gle/af4KWj4fQRno6v2L9 Все участники будут добавлены в Telegram-чат, где получат статьи для подготовки и вопросы для саморефлексии.

Уже в это воскресенье в 12:00 по Мск мы проведем первую встречу читального клуба, в котором есть еще пара мест для желающих 📚 Подробнее про формат и тему описали в посте выше ⬆️ А записаться можно здесь: https://forms.gle/af4KWj4fQRno6v2L9 До встречи!

Пол (и все-все-все) — это исполнилось 30 лет лучшему языку программирования 📱

🎙️ Ищем людей для короткого исследования! Друзья, всем привет! Мы готовим исследование о том, как опытные программисты обучаются новым навыкам и хотим услышать ваши истории. Интересны все, кто: 1. За последний год проходил платные курсы по программированию или смежным темам (не важно, онлайн/оффлайн, длинные/короткие). 2. Или использовал AI (ChatGPT, Copilot и др.) для учёбы, практики или экспериментов. Если был опыт обеих активностей, то ещё лучше 🙌 🗣️ Исследование пройдёт в формате беседы/интервью и займёт примерно 40-45 минут. Если вы были бы рады поучаствовать, напишите, пожалуйста в личку или оставьте сообщение в комментариях. Спасибо!

HDD без магии — как «железо» диктует индексы 👋 Привет Пол (и привет всем) Сейчас в ридинг-группе по 'кабанчику' мы готовимся к обсуждению третьей главы, посвящённой хранению и извлечению данных. Чтобы глубже понять причины оптимизаций, сделанных в базах данных для операций чтения и записи, я решил чуть приоткрыть «black box» под названием Hard Disk Drive (HDD). А именно -- верхнеуровнево посмотреть, как же устройство жёсткого диска повлияло на оптимизации в алгоритмах баз данных в целом и индексов в частности. Конечно, знание устройства «железа» не является обязательным для качественной работы разработчика, но позволяет лучше усвоить причинно-следственные связи и не воспринимать оптимизации как абстрактную данность. 🎥 По теме попалось отличное видео How HDDs Work?, где наглядно объясняется устройство жёсткого диска, как данные хранятся, записываются и читаются, а также откуда берутся те самые 4 KB, которые считаются best practice для хранения фрагментов данных. Если у вас есть общее любопытство к теме, это видео отлично закроет пару «как это устроено» вопросов. Буду рад вашим наводкам на другие полезные материалы в комментариях 😐

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 для учёбы, практики или экспериментов. Будем очень рады с вами познакомиться и пообщаться ☕

Привет Пол, и привет всем! 👋 Хочу поделиться каналом Димы, а заодно сказать ему большое спасибо за упоминание и фидбек Рекомендую заглянуть к Диме, там много интересного про Java и не только https://youtu.be/ZrUm1DV6XOU?t=1166&is=qFBJp3W9CPfoNm85

Привет, Пол, и привет всем! Опубликовал свой первый ролик на YouTube про Harness Engineering на основе статьи Биржитты Боклер. Забавный факт: из 4+ часов отснятого материала в итоге получилось всего 9 минут видео, а суммарно на финализацию первого ролика ушло ~80 часов. Буду очень рад, если посмотрите и поделитесь видео с друзьями 🙌