tgindex

Пол — это Java

описание

Канал, в котором живет вымышленный на основе реальных событий разработчик Пол, и вместе с ним мы пробуем узнать, что такое Java и не только👨🏻‍💻 @polyackov_ot

← к каналу@polEtoJava
163
подписчиков
Охват к подписчикам
201,8%
ERR
Реакции к просмотрам
3,69%
261 на 21 постов
Пересылки к просмотрам
0,34%
24
Постов в день
0,1
всего 21

Где отзываются чаще

доля реакций к просмотрам
  • 13 авг.Привет Пол, и привет всем! 👋 Хочу поделиться каналом Димы, а заодно сказать ему большое спасибо за упоминание и фидбек Рекомендую заглянуть к Диме, там много интересного про Java и не только https://youtu.be/ZrUm1DV6XOU?t=1166&is=qFBJp3W9CPfoNm8520,00%
  • 22 апр. 2025 г.ЧИСТЫЙ КОД (Part 2) 👋 Привет Пол (и снова привет всем) Обычно, когда говорят про чистый код, обсуждают размер методов, длину названий или форматирование. Но я убежден, что чистый код начинается задолго до того, как будет написана первая строка. Перед тем как писать код, важно все же понять контекст, в котором он будет существовать. Для этого я задаю себе (и коллегам) несколько ключевых вопросов: 1️⃣ Кто наши стейкхолдеры (технические и бизнес)? Стейкхолдеры, в свою очередь, помогут нам ответить на вопросы ниже. 2️⃣ Каковы архитектурные риски и ключевые качества системы? Это понимание позволит валидировать каждое принимаемое решение. Примером риска может являться утечка клиентских данных, а качеством системы в таком случае является безопасность. 3️⃣ Какой объем изменений ожидается в будущем? — Значительный → стоит искать более продуманное решение, которое позволит в будущем более удобно добавлять новые функции или изменять старые. — Малый → можно позволить себе решение более простое, прямолинейное и быстрое по срокам реализации. 4️⃣ Долгосрочная или краткосрочная ли ожидается поддержка? — Долгосрочная → код должен быть гибким и легко поддерживаемым. — Краткосрочная → можно принять больше компромиссов. 5️⃣ Насколько жесткие дедлайны? — Сжатые сроки → приходится делать упрощенные решения. — Гибкие сроки → можно уделить больше времени качеству. Ответы на эти вопросы могут быть зафиксированы в аналитике к задаче или существовать только в головах команды. Но чем больше информации удастся собрать, тем лучше. По итогу: чем выше уровень неопределенности, тем выше шанс принять некачественное и неподходящее решение. P.S. В следующих постах я хотел бы разобрать разные вариации контекстов и поразмышлять, какие решения можно принять на их основе. Буду рад вашим мнениям!7,49%
  • 8 апр.👋 Привет, Пол. И привет всем. Недавно на конференции я разговорился с разработчиком, которого явно раздражало, что на работе его заставляют использовать AI: "Я не для этого учился computer science, чтобы AI писал код за меня". И вообще "Мне нравится писать код самому". Этот разговор натолкнул на мысль, что у меня самого отношение к AI неожиданно смешанное. Я оставлю за рамками поста вопросы вроде насколько AI эффективен, какая модель лучше и где он реально приносит пользу — меня зацепило другое. В какой-то момент я стал замечать, что при решении некоторых задач периодически появляется странное чувство, что-то между грустью и разочарованием. После пары сеансов саморефлексии стало понятно, что меня расстраивает вообще даже не сам факт использования AI — скорее, наоборот, мне нравится, что AI может помочь быстрее найти варианты, заметить риски и в итоге принять более качественное решение. Проблема в другом: иногда вместе с этим приходит другое ощущение, будто работу сделал не я, а агент, ну а я просто стоял рядом. И вот это осознание стало для меня важнее всех споров про “заменит / не заменит”, потому что, кажется, нам важно не только получить результат, но и чувствовать, что это именно наш результат. И тут же всплыло ещё одно наблюдение, напрямую связанное с этим ощущением — фраза "я погуглил / я поисследовал" воспринимается мной гораздо приятнее, чем "я спросил у GPT" или "GPT мне сказал". Хотя по сути во многих случаях это просто про разные интерфейсы для работы с информацией, поэтому все еще похоже, что многое упирается в то, как именно мы воспринимаем своё участие в процессе. Если напоминать себе, что AI — это всё-таки инструмент, а не самостоятельный автор, безусловно, становится проще принять происходящее. Да, очень мощный инструмент и иногда почти пугающе полезный, но без нашего запроса, без нашего контекста, без нашего выбора и без нашей оценки ответа результат всё ещё не “возникает сам", просто форма нашего участия меняется. P.S. Забавно, что очень похожую фрустрацию я когда-то испытывал, когда начал руководить группой инженеров. Тогда тоже появлялась мысль: "Я ничего не сделал — всё сделали без меня". Похоже, в обоих случаях неприятно не отсутствие действий, а потеря привычного ощущения прямого вклада.6,67%
  • 26 апр. 2025 г.👋 Привет Пол (и все, кто любит полезные фичи 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.6,28%
  • 24 апр. 2025 г.ЧИСТЫЙ КОД (Part 3) Скажи свое мнение и беги: не откладывай на завтра то, что можно сделать послезавтра Звучит как сомнительный совет, однако я убежден, что это один из ключевых принципов качественной архитектурной работы. Под профессиональный контекст это можно перефразировать как Откладывай принятие важных архитектурных решений как можно дольше. Оно же верно и в концепции чистого кода. Это не значит избегать решений и ответственности вовсе. Скорее наоборот, это значит принимать только те решения, без которых невозможно двигаться дальше прямо сейчас. Остальные же будет дальновиднее оставить на момент, когда появится больше данных о контексте задачи (про план сбора контекста я писал в посте выше). Если к моменту принятия решения информации не прибавится, мы со спокойной душой возьмем в работу изначальные идеи. Но если контекст дополнится, новое решение будет осмысленнее и качественнее, что в долгосрочной перспективе окажется выгоднее. P.S. А какие принципы у вас есть в работе?6,01%
  • 18 апр. 2025 г.ЧИСТЫЙ КОД (Part 1) 👋 Привет Пол (и все, кто задумывается о чистом коде) Семь месяцев назад я сменил работу, и теперь одна из моих ключевых задач — обучать и делиться экспертизой. И за это время мне часто приходилось отвечать на вопросы, так или иначе связанные с чистотой кода. Что такое чистый код? Это самый базовый вопрос, на который, тем не менее, нет простого ответа. Нельзя просто следовать чек-листу и гарантировать, что код при этом станет чистым. Сам подход подразумевает, что иногда важно придерживаться принципов, а иногда осознанно от них отходить. В следующих постах мне хочется разобрать и порефлексировать, как именно я принимаю такие решения. Я покажу свою логику, постараюсь объяснить, на чем она основана, и между какими вариантами я привык выбирать в реальной разработке. P.S. А еще оказалось, что многие вещи делаются настолько бессознательно и интуитивно, что при необходимости передачи знания приходится буквально воссоздавать с нуля алгоритм действий. Поэтому я был бы очень рад и благодарен, если вы поделитесь в комментариях своим опытом или мнениями под грядущими постами!5,05%
  • 31 мая 2024 г.👋 Привет Пол (и привет всем) Последние несколько месяцев я проверяю работы студентов-джавистов на курсе по 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()); } Буду благодарен, если вы поделитесь в комментариях, что на ваш взгляд должно быть или не быть в хорошей ошибке! #exception4,84%
  • 26 апр. 2025 г.⚙️ Live Templates в IntelliJ IDEA Надоело писать одни и те же конструкции снова и снова? На помощь приходят Live Templates — инструмент, который позволит генерировать фрагменты кода по паре букв. Live Templates — это заготовки кода, которые можно вставлять по сокращённым ключам. Например, вместо того чтобы каждый раз писать System.out.println(), достаточно написать sout и нажать Enter. IDEA сама развернёт код. Live Templates поддерживают Java, Kotlin, JS, Groovy, SQL и XML/HTML. 📌 Полезные шаблоны по умолчанию 🟢 sout → System.out.println(); 🟢 fori → for (int i=0; i< ; i++) {} 🟢 psvm → public static void main(String[] args) {...} 🟢 ifn → if (obj == null) {} 🟢 prsf → private static final Полный список live templates: File → Settings→ Editor → Live Templates. ⚙️ Как создать свой шаблон 1️⃣ Открываем File → Settings→ Editor → Live Templates 2️⃣ Выбираем группу или создаём свою. 3️⃣ Нажимаем "+" и задаём аббревиатуру (триггер шаблона). 4️⃣ Пишем в поле Template text код с переменными ($VAR$). 5️⃣ Указываем Context, где шаблон будет работать (Java, SQL, XML и т. д.). 6️⃣ Применяем и тестируем. Live Templates – это must-have инструмент для ускорения написания кода. Настройте под себя и забудьте про шаблонный код. 💬 Делитесь интересными кастомными шаблонами ✅ Java библиотека #java4,25%
  • 6 мая 2025 г.ЧИСТЫЙ КОД (Part 4) 👋 Привет Пол (и привет всем) В одном из прошлых постов мы говорили на тему вариации контекста, формирующего решения разработчика. Теперь спустимся на уровень конкретных примеров и подумаем, а как можно в разном контексте действовать. 💼 Представим, что мы работаем в крупной корпорации N, где есть ресурсы на реализацию максимально качественных решений. 🎯 Нам была поставлена задача: Разработать калькулятор комиссий, который заменит менее гибкое и производительное вендорское решение. Ответим на вопросы о контексте: 🧑🏻‍💻 Кто наши стейкхолдеры? Каковы их запросы и ожидания? • Команда бизнеса — хочет предлагать клиентам уникальные условия, а потому ожидает гибкости решения в виде точечных настроек калькулятора и быстрого добавления новых вариантов комиссий. Однако на первом этапе считает достаточным просто заменить вендора. • Команда поддержки — недовольна сложностью текущей системы, где в случае ошибок трудно разобраться в причинах и найти корректный способ исправления. • Финансовый контроль — косвенный стейкходлер, который заинтересован в точности расчетов и прозрачности начислений, чтобы исключить возможные ошибки. ⚠️ Каковы архитектурные риски и ключевые качества системы? • Во время пиковой нагрузки могут возникать задержки обработки запросов → Требуется высокая производительность и масштабируемость системы, а именно способность обрабатывать большое количество расчетов в короткие сроки, а также сохранять этот параметр при росте нагрузки • Ошибки в расчетах могут приводить к финансовым потерям → Важна целостность данных, учет атомарности операций, работа с округлениями и защита от ошибок интеграций. • Бизнес ожидает, что со временем появятся новые требования → Система должна обладать расширяемостью. Если изначальная архитектура не учитывает возможность модульного расширения, стоимость доработок может вырасти в разы. • Калькулятор комиссий, скорее всего, будет зависеть от других сервисов (биллинг, CRM, внешние платежные системы) → Непродуманная работа с интеграциями может стать узким местом. 🛠 Какой объем изменений ожидается в будущем? Долгосрочная или краткосрочная ли ожидается поддержка? • Значительный объем изменений • Долгосрочная поддержка ⏳ Насколько жесткие дедлайны? Сроки гибкие, но первый тип комиссии должен начать работать через 2 месяца. После этого начнется этап переноса остальных комиссий и, при необходимости, разработка новых. ⸻ ⸻ ⸻ ⸻ ⸻ Даже получив ответы на вопросы выше, объем известного значительно меньше того, что мы до сих пор не знаем. Но откладывать больше нельзя — пора начинать писать код. Думаю, все мы знаем это чувство, когда легче начать, а разбираться уже при необходимости по ходу дела. Благо, agile давно помог нам справляться с этой сложностью. В нашем кейсе уже изначально мы можем предсказать, что и core, и integration слои будут сложными. Интеграции — это больше техническая проблема, поэтому решать её нам легче — применяем гексагональную архитектуру. Со второй же проблемой так просто не получится, поэтому применяем мудрость из прошлого поста и просто откладываем решение до лучших времён. А текущую реализацию делаем максимально простой, но при этом не забываем про 100% покрытие core тестами, которые дадут нам уверенность при необходимости менять код по 50 раз в день. Уже в дальнейшем, когда наберётся некоторая критическая масса кода в ядре, мы сможем его отрефакторить и реализовать onion / clean architecture / DDD. 💬 Как бы вы подступились к решению этой задачи? Делитесь в комментах!4,01%
  • 7 мая 2025 г.📚 Время пробовать новые форматы, а потому мы с коллегами анонсируем запуск ридинг-клуба "Пол — это Java" 📚 В чем особенность формата, и почему мы ему уже рады? • Каждая встреча клуба будет ознаменована дискуссионной темой из профессиональной жизни разработчика, на которую есть неоднозначные точки зрения в статьях и литературе. Мы заранее подберем наиболее ключевые и интересные работы по теме для ознакомления. Они не будут слишком большими, чтобы все участники успели подготовиться! • Встречи будут в формате живой модерируемой дискуссии, которая поможет систематизировать знания, посмотреть на знакомые вещи под новым углом и обменяться реальным опытом. • Все это делает формат прекрасным как для тех, кто еще ничего знает о теме, так и для погруженных: ✔️Начинающие познакомятся с современными теориями подходами, смогут перенять живой опыт более опытных участников. ✔️Опытные осмыслят и отрефлексируют знания, обменяются инсайтами с другими профессионалами. ☕️Тема первой встречи: Роль архитектора в Agile-командах ✔️Мы проанализируем подходы к распределению архитектурных задач в командах ✔️Подискутируем, как меняется понимание архитектуры в условиях гибкой разработки ✔️Обсудим, нужен ли архитектор в классическом смысле или команды могут справляться сами, полагаясь на собственную экспертизу ⏳ Когда: 25 мая (воскресенье) 12:00–15:00 (по Мск, GMT +3) онлайн 📼 Записаться можно здесь: 📼 https://forms.gle/af4KWj4fQRno6v2L9 Все участники будут добавлены в Telegram-чат, где получат статьи для подготовки и вопросы для саморефлексии.3,85%
  • 26 сент. 2025 г.HDD без магии — как «железо» диктует индексы 👋 Привет Пол (и привет всем) Сейчас в ридинг-группе по 'кабанчику' мы готовимся к обсуждению третьей главы, посвящённой хранению и извлечению данных. Чтобы глубже понять причины оптимизаций, сделанных в базах данных для операций чтения и записи, я решил чуть приоткрыть «black box» под названием Hard Disk Drive (HDD). А именно -- верхнеуровнево посмотреть, как же устройство жёсткого диска повлияло на оптимизации в алгоритмах баз данных в целом и индексов в частности. Конечно, знание устройства «железа» не является обязательным для качественной работы разработчика, но позволяет лучше усвоить причинно-следственные связи и не воспринимать оптимизации как абстрактную данность. 🎥 По теме попалось отличное видео How HDDs Work?, где наглядно объясняется устройство жёсткого диска, как данные хранятся, записываются и читаются, а также откуда берутся те самые 4 KB, которые считаются best practice для хранения фрагментов данных. Если у вас есть общее любопытство к теме, это видео отлично закроет пару «как это устроено» вопросов. Буду рад вашим наводкам на другие полезные материалы в комментариях 😐3,74%
  • 28 мая 2025 г.Сегодня идея меня встретила так3,40%