Начала реализовывать гексагональную архитектуру. Она оказалась для меня не интуитивно понятной, но однозначно интересной и стоящей внимания.
Основной смысл этой архитектуры заключается в максимальном применении SOLID и атомизации компонентов исходного кода.
Из основных плюсов я для себя отметила:
⁃ упрощение работы с кодом классов и тестов. Они стали меньше по объему и соотвественно читать их стало проще.
⁃ тестируемость. Можно протестировать бизнес логику приложения изолированно.
⁃ меньше кода в классе -> меньше потенциальных конфликтов при слиянии веток от различных разработчиков при работе в команде.
⁃ больше гибкости в конфигурации сервисов. Напрмер, проще добавить кэш только в одном методе.
Из минусов:
⁃ больше классов и интерфейсов. Единственный способ упростить этот момент - грамотно и внимательно организовать типы по пакетам и модулям.
Лично для меня такой тип архитектуры так и остался пока очень не привычным. Теперь в планах прочитать книгу «Чистая архитектура» Роберта Мартина.

Кажется что Telegram боты есть сейчас у всех. Вот и в свой проект решила его добавить. Это оказалась действительно очень просто. Спасибо Telegram’у за это 🙂
Основное количество туториалов на эту тему в интернете предлагают создавать бота на Python, но я буду писать на java + spring + maven и TelegramAPI версии 6.9.7.1. Реализацию сделала с помощью LongPolling, т.к. этот метод не требует сертификатов шифрования и запускаться может с любой машины. Для этого я наследовалась от TelegramLongPollingBot.
В отличии от версии 3.5 здесь произошли изменения:
- из базовых методов теперь не нужно реализовывать public String getBotToken(), т.к. токен теперь передается в конструкторе.
- Конструктор без параметров и конструктор который не принимает токен теперь помечены как deprecated.
Получается что при создании своего бота теперь обязательно нужно передавать токен в родительский класс.
Так же нужно подключить своего бота к TelegramAPI. А т.к. я поручила Spring создавать моего бота (с помощью @Component), то использовала @PostConstruct в котором вызывала метод registerBot.
Получать, обрабатывать и отвечать на сообщения бот умеет через метод public void onUpdateReceived(Update update) который нужно реализовывать.
Креды бота конечно же лучше убрать в конфиги, например с помощью spring.config.import. Получить их можно у отца всех ботов в Telegram (@BotFather).
Вот в принципе и все. Реализация бота оказалась самой легкой частью, а вот реализовать логику обработки сообщений может быть уже далеко не так просто (конечно же, в зависимости от придуманных фичей). Благодаря понятным API у Telegram получилась сделать легкий старт в создании ботов для каждого. Единственный маленький минус - это устаревшая документация в официальных источниках, про то что есть изменения свежих версий от старый там не упоминается.

На этой неделе прошел первый online день конференции Jpoint (это одна из двух крупнейших в России конференций для Java разработчиков). Я послушала 4 полных доклада и дискуссий.
1. «PG для Java-разработчиков». Автор рассказывал о процессе миграции продукта с Oracle на Postgres. К моему сожалению JPA/Hibernate в докладе не рассматривались, использовался jdbc. Но для пула коннектов использовался HikariCP, так же как и у нас. Благодаря наводкам автора я решила сделать ревизию настроек подключения к базе, возможно наши конфиги не так оптимальны. Также нужно будет обновить библиотеки: как минимум liquibase уже давно напрашивается, версию зависимости postgresql также нужно проверить. Автор рассказывал о том что новые фичи не всегда включены по умолчанию из-за желания разработчиков поддерживать обратную совместимость, нужно читать changelog-и. А еще во время доклада пришла идея сделать также как в продукте докладчика: для создания Excel отчета можно читать данные из read-only реплики. У нас есть некоторые отчеты и возможно такое решение снизит нагрузку на систему в целом. Еще автор рассказал про интересную возможность настройки application_name при запросе pg_stat_activity. Дефолтное имя вида PostgreSQL JDBC не самое удобное для анализа. А с помощью настройки

spring.datasource.hikari.data-source-properties.ApplicationName=yourAppName

можно отслеживать запросы не только по их содержимому, потому что это сложно уже даже для среднего размера проекта.
2. «Миграция на Spring Boot 3». Это было интересное обсуждение, т.к. в нашем продукте используется java 11 и spring boot 2.5. Очевидно обновится нам стоило бы, но времени на это нет (фичи не ждут!). Поэтому нужно составить четкий план миграции и делать это постепенно и по возможности безболезненно. Как вариант эксперты предложили сравнить
dependecy treе вашего текущего проекта с целевой версии (сгенерить можно свежий через https://start.spring.io/). Думаю что это интересная идея, которая поможет понять на сколько зависимости отличаются и в каком участке кода предстоит больше всего работы.
А в случае нашего приложения конечно нужно вначале мигрировать хотя бы на 17 java. Дальше эксперты предлагают поднять версию spring boot до 2.7. И потом уже когда выровняли зависимости до 3.2 - так процесс должен пройти мягче. Хотя конечно переезд на Jakarta EE, новый Hibernate, обновленная Security добавят некоторое количество часов проведенных за правками кода.
3. «System Design-интервью для практиков». С помощью этого доклада можно в очередной раз убедиться что собеседования в FAANG это свой отдельный мир с очень жесткими таймингами ограничениями. Жалею что не смотрела доклад Владимир Маслов — System Design. Как построить распределенную систему и пройти собеседование с прошлого jpoint, а докладчик советовал. Теперь и его надо посмотреть 🙂
4. «Как готовить свой код к виртуальным потокам». Все круто, классно, полезно, но в текущих рабочих реалиях этот доклад я не могу применить к рабочему проекту, потому что работа в банке - это много ограничений и java 21 пока у нас отсутствует 🙁
И в обсуждении тоже было много комментариев о том что очень хотелось бы добавить виртуальные потоки в свой код, но проект на java 17, 11 и даже 8.
А вообще мысль про обновление на более свежие версии библиотек, фреймоворков, языка и т.д. для меня была основной в этом дне, но на это вечно нету времени, а жаль. Планирую его все же найти, потому что прирост производительности приложения это должно дать.
Конференция пока выглядит очень насыщенной и полезной, теперь я жду продолжения.

Сегодня о втором дне конференции JPoint, который мне удалось посетить в offline. Перед тем как переходить к докладам, хочу отметить организаторов. Они отлично поработали! Не возникало вообще никаких проблем, все было просто, понятно и очень хорошо организовано.
Итак, к докладам:

1. «Бросить нельзя поймать: основы и детальная механика Java-исключений». Было очень много полезной информации об исключениях: когда ловить, логировать ли (иногда это очень дорого), нужно ли оборачивать и как. Я узнала про ключи запуска jvm «OmitStackTraceInFastThrow» и «CrashOnOutOfMemoryError». И первый точно поможет если на проде откуда-то прилетел NPE и нужно понять откуда и получить трейс. По умолчанию его конечно лучше не включать, но для расследования инцидента нужно запомнить. А второй ключ уронит jvm и снимет дамп.

2. «Hibernate, OOM и ооочень длинные запросы». Получилось интересно, потому что вторую часть первого доклада как раз обсуждали OOM и как его искать и что делать. Получилось небольшое продолжение 🙂

3. «Правильный DevOps для Spring Boot и Java». Один из самых классных докладов на конференции. Когда его выложат в открытый доступ, однозначно рекомендую посмотреть не только джавистам, но и DevOps-инженерам. Если нюансы изменения конфигурации приложения знакомы многими, то о том, что с помощью Spring (layertools) можно решить вопросы кэширования слоев докер образа, знают не многие.

4. «Как мы построили самобалансирующийся мониторинг обработки топиков Kafka с помощью самой Kafka». Докладчик интересно рассказывал о пути продукта и как они решали задачи связанные с обработкой потоков данных. Было интересно послушать, но в текущем проекте данную информацию, к сожалению, нигде не применить.

5. «Spring Data JDBC. Проблемы известные, проблемы неизвестные». Это был самый смешной доклад всей конференции 🙂 Докладчик является действующим контрибьютором в Spring Data JDBC и он знает о текущих проблемах проекта. Было много багов, которые оказались фичей. И еще часть проблем о которых разработчики знают, но: «Исправлять мы это конечно же не будем» 😁

6. «Образование в области IT: фундамент и индустриальная повестка». Докладчик рассказал о Физтех-школе прикладной математики и информатики, как им удается сохранять фундаментальное образование, но при этом работать совместно с потребностями бизнеса. Это было интересно послушать.

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

Сегодня о третьем, заключительном дне конференции JPoint 2024. В этот день у меня не получилось посетить все доклады, которые хотелось, т.к. два шли в одно и то же время.

1. «Поиск проблем Java-приложения с 31G heap и 500G off-heap на примере Apache Ignite». Посетила этот доклад в продолжение темы о снятии и анализов дампов. Но в этом докладе докладчик рассказывал не только о том как «лечить» Java приложение, но и много внимания уделил настройкам Linux для высоконагруженного приложения, что встречается крайне редко.

2. «Запуск по расписанию в Java: как не проспать работу и успеть к дедлайну». Этот доклад смотрела уже после конференции в online. Здесь докладчик рассказывал о существующих решениях для планировщиков задач, получилась такая обзорная экскурсия по инструментам. Основное что можно почерпнуть для себя из этого доклада - это то к какому решению прибегать в зависимости от обстоятельств в которых оно будет использоваться.

3. «Мы писали DSL в Spring и грабли ловили». Этот доклад напомнил о Евгении Борисове и Spring-потрошители. Докладчики явно им вдохновлялись. Было очень много про создание бинов и копания в «кишках» Spring’а. Таких докладов не хватает. И пусть мне в ближайшее время вряд ли пригодится создавать бины таким образом, все равно было очень полезно и интересно.

4. «Как мы сделали интеграционную шину вместо SAP и при чем тут Java». Ожидала от этого доклада намного большего, т.к. тема миграции с SAP близка к рабочим задачам и хотелось почерпнуть больше полезного. Но по моим ощущениям докладчики уделили больше внимания бюрократическим нюансам получения гос. сертификатов для работы с «чувствительными» данными, чем техническим нюансам реализации решения. Итого, получилось, что это единственный доклад конференции на котором я была и который не порекомендую.

5. «БД-укротитель». Очень полезный, интересный, динамичный доклад. Было и о типичных проблемах при работе с БД, и о работе с ORM, и о самой СУБД. Если подвести краткий итог доклада - пишите оптимальные запросы, устанавливайте границы транзакций, экономьте коннекшены и знайте внутреннее устройство СУБД которую используете (не надо думать что простого знания ORM достаточно). А еще рассказали о других докладах с других конференциях которые тоже стоит посмотреть. Пожалуй, это тот доклад который стоит пересмотреть вместе с кодом рабочего проекта.

6. «Вложенные сущности по требованию в API на Spring Data JPA». Докладчик рассказал о своем опыте миграции с OData на Spring. Послушать было интересно, но на вопрос из зала: «Стоило ли реализовывать такие «хотелки» фронта или пусть фронт все таки делает разные запросы для тех данных которые хочет получать, а не забирает все данные в одном API?», - докладчик ответил что еще раз он бы на такое не пошел и правильней было бы дорабатывать фронт 🙂

6. «Интегральное скерцо: как машины пишут музыку и поют». Единственный доклад про модную тему ИИ и тот был после официального закрытия конференции 🙂 Здесь не было ничего про Java, но послушать о том как музыку анализируют для работы с компьютерами и ИИ в частности было довольно интересно.

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

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

Код ревью — это процесс, в ходе которого другие разработчики из команды изучают ваш код, ищут ошибки, предлагают улучшения и обсуждают возможные альтернативы. Это не просто формальный шаг в процессе разработки, а важное звено, способствующее повышению качества кода и улучшению коммуникации в команде. Результатом проведенного ревью является обратная связь по выполненной задаче: либо необходимость доработать код (need works), либо готовность задачи к последующему тестированию и релизу (approve).

Вот несколько причин, почему ревью кода необходимо проводить:

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

2. Обмен знаниями: в процессе код ревью разработчики могут узнать что-то новое или поделиться своим опытом. Это способствует обучению и развитию команды в целом. Поэтому ревьюерами должны быть все члены команды, даже джуниор разработчики. Не нужно бояться задавать глупые вопросы при ревью, нужно уметь получать пользу от кода своего коллеги. Не стыдно не знать, стыдно не хотеть знать 🙂

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

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

5. Улучшение коммуникации: ревью кода способствует общению в команде, помогая разработчикам лучше понимать друг друга и работать более эффективно.

Есть всего два минуса и на мой взгляд они не значительны:

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

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

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

Посмотрела доклад Федора и Ильи Сазоновых «Добровольно-принудительный Spring» и мне понравилось, несмотря на то что было больше философии, чем практической пользы.
Суть доклада в том что с помощью популярных фреймворков Java сообщества (в частности Spring + Lombok) разработчикам стало очень легко и просто писать некачественный код, который нарушает SOLID. К сожалению, я вынуждена согласиться с этой мыслью. Например, видела код, который кое-как работает в продакшене, где все методы для API лежали в одном GOD классе (да, в одном классе и ‘/api/user‘, и ‘/api/book’, и ‘/api/cat’), был просто ApplicationController. Разработчики спокойно добавляют по 10+ зависимостей в класс и не видят проблем даже на уровне конструктора, потому что @RequiredArgsConstructor - и все хорошо.
Авторы утверждают что никакого ООП в современных проектах на Java + Spring нет и если хорошенько присмотреться, то мы увидим Pascal 🙃 И я даже соглашусь! Сейчас типичный код - это бин, который по факту является мешком для функций. А единственное отличие от Pascal’а - удобство тестирования. Значит им надо пользоваться изо всех сил. Выводы: «не использовать private и static методы», «не вызывать внутри бина его собственные методы», «тестировать фреймворки», - на мой взгляд спорные.
А вот быть осторожнее с DDD (domain driven development) и использовать TDD (test driven development) я соглашаюсь на все 100%. Потому что лучше написать и отлаживать код на тестах, которые все равно нужны, чем использовать SDD (swagger driven development) и потом все равно преодолевая огромное нежелание писать тесты 🙂

Наша команда разработки приступила к новому проекту, еще не полностью передав в сопровождение из разработки старый. Участвовать одновременно в двух сложно, но я всё же пока большую часть времени участвую в процессе передачи старого проекта, где нужно было обновить интеграционное взаимодействие. Часть сервисов остается в нашей команде, часть передается в другую. Там где раньше сервисы отдавали запросы в рамках одного кластера, теперь два разных кластера, а соотвественно нужны сертификаты, настройки istio и ACL… Вообщем много головной боли и дебага, чтобы понять что именно на инфраструктуре отвалилось, а из кода - это просто добавить возможность читать и писать в два разных сервера Kafka.

Но самая большая боль последних недель заключается в том что мы не можем стартовать новый проект с 21 Java и Spring Boot 3+ 🥲 С тем что мы не сможем использовать свежую версию языка было понятно давно - к нам его еще просто не завезли 😅 Да, Java есть в качестве образов для сборки, но поставить на свою машину чтобы писать код возможности нет. Получается бюрократический парадокс - мы можем привезти в прод код (который теоретически даже будет корректно работать) написанный на 21 версии, но писать будем в слепую - коммитить и запускать тесты на сборщике. Ладно, это грустно, но я уже успела даже смириться.

А вот что библиотека которую мы обязаны использовать не поддерживает 3+ версию Spring Boot’а узнали только в процессе того как долго и мучительно пытались завести болванку проекта. Ошибки были самые разнообразные, пришлось залезть в кишки библиотеки и увидеть что там используется более старая версия Apache Kafka. И именно конфликтующие версии зависимостей давали не понятные и странные ошибки. Пришлось идти к разработчикам библиотеки и узнавать как же так. Оказалось, что действительно, нужно использовать Spring Boot версии 2.7.4 максимум. Есть ли об этом хоть строчка в документации? Конечно, нет! Зато есть информация какую зависимость подтягивать, если у вас 3+ Spring Boot. Зачем, если это все равно не будет работать и только вводит в заблуждение? Потому что вдруг вы будете использовать эту библиотеку только для определенной второстепенной функциональности, где все заведется. Есть ли информация в документации что тогда первостепенная функциональность, для которой мы и обязаны использовать эту библиотеку отвалится? Конечно, нет! Как же так? Поправит ли это кто-то в документации, чтобы другие команды разработчиков не теряли человеко-часы на такие же ошибки? Нет, потому что «документация поставляется с дистрибутивом, а в августе этого года мы добавим поддержку Spring Boot 3+». Остается только оставлять комментарии к документации об этой истории для следующих команд.

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

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

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

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

В целом, тесты - это еще и разновидность документации. Если тесты есть (еще и с понятным названием), то новому разработчику будет намного легче разобраться в коде.

Также тесты дают уверенность разработчикам (как старым, так и новым), что изменения и доработки в существующем функционале не сломают его.

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

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

В целом отказ от unit тестов приводит к росту ошибок в приложении. Причем, чем дольше вы будете отказываться от тестирования, тем сложнее будет потом разобраться в том, из-за чего все-таки возникли сложности.

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

По мотивам прошедшей рабочей недели хочу снова написать о важности индексов и зачем прикладному разработчику понимать как работает СУБД, которую он использует.

Индексы или методы доступа - это специальные объекты базы данных, которые в основном помогают ускорить доступ к данным. В PostgreSQL существует более шести различных видов (с учетом расширений) индексов, но все они в итоге устанавливают соответствие между ключом и строками таблицы в которых этот ключ встречается, что помогает не сканировать всю таблицу полностью. Индексы - это тоже самое, что оглавление или предметный указатель в книге.
Но у всего есть своя цена, и цена индексов - это повышение затрат на их поддержание: вставка, удаление, обновление строк таблицы требуют перестроения индексов, причем в рамках той же транзакции. Кстати, благодаря механизму HOT, обновление тех полей таблицы, на которые индексов нет, не приводит к перестроению индексов.

Все это требует от прикладного разработчика при создании таблиц и столбцов таблиц также думать: а нужно ли мне тут создавать еще и индексы?

Когда индексы не нужны:
- по этому полю (или таблице) поиск выполняется крайне редко или вовсе отсутствует;
- в таблицу намного чаще осуществляются вставки (удаления, изменения) записей, а не поиск.

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

В среду на проекте, в котором я теперь работаю, запустили инициализирующую выгрузку бизнес данных из смежной системы. Мы ожидали поступления и сохранения 780 тысяч записей. К концу дня стало очевидно, что сохранение происходит слишком медленно, потому что к тому моменту сохранилось лишь 50 тысяч записей. По моим оценкам, полная загрузка должна была завершиться примерно через два дня после старта, что очень много для такого объема данных. В коде я увидела следующее: когда данные поступают, то отрабатывает метод поиска по двум полям, и если такая запись есть в базе - то выполняется её обновление, а если нет - сохранение новой. Удаление же не происходит никогда. Посмотрев в саму базу данных, индекса я не увидела. Очевидно, что он в такой ситуации прямо напрашивается.

Мы добавили индекс и загрузка данных сразу ускорилась в разы. За следующий час в базе уже стало 200 тысяч записей и загрузка успешно завершилась к концу дня. Инициализация ускорилась в 12,5 раз (сохранение 100 записей до добавление индекса отрабатывало 25 секунд, а после добавления всего лишь 2 секунды). Также упала нагрузка на CPU базы: до создания индекса она составляла 69,7%, после едва поднималась до 12%.

По итогу я ещё раз убедилась, что проставление правильных индексов - это такая же важная часть работы бэкенд разработчика, как и написание кода; приобрела материал для этого поста 🙂 и решила, что теперь буду начинать анализ проблем с БД на новом проекте с проверки индексов.

На рабочем проекте мне нужно было провести smoke тест фичи, которую я закончила. Но дев стенд был занят и поэтому я захотела поднять Kafka локально. К сожалению, мне это не удалось - producer при попытке подключения постоянно получал ошибку: «nodename nor servname provided, or not known».

Проблема странная, я потратила около двух часов на попытки её решить.
А оказалось все очень просто - используемый мной образ bitnami/kafka:latest был не такой уж и latest 😅. Образ был скачен 520 дней назад.

После обновления образа проблема решились. Очередное доказательство для: «А вы пробовали выключить и снова включить?».

Купила книгу, описание многообещающее: «Прочитав эту книгу, вы
- узнаете, как именно ваш мозг видит код;
- научитесь бегло читать и быстро усваивать код;
- убедитесь, что есть простые приемы позволяющие распутать самый сложный код;
- сможете навести порядок в любой, даже самой запущенной базе кода.»
Отдельно заинтересовал последний пункт, т.к. сейчас для меня он очень актуален.

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

Читаю «Ум программиста».
Книга читается очень легко и приятно, не оторваться, а иногда вообще хочется разобрать ее на цитаты. Например, первое же предложение первой главы: «Замешательство — неотъемлемая часть программирования». Автор говорит о трех типах замешательства и связанных с этим когнитивных процессах. Я стала замечать, что в новом проекте сталкиваюсь чаще всего с тем, что мне не хватает информации (не знакомы бизнес процессы), и недостатком вычислительной мощности (код написан очень запутано).
Во второй главе автор предлагает очень интересное упражнение, которое можно использовать для самодиагностики вашего знания кода. Нужно выбрать кодовую базу, которую вы немного понимаете, но не знаете от начала и до конца. Выбрать метод в пол страницы и не более 50 строк. Затем поизучать код две минуты и попытаться воспроизвести его как можно точнее, не подглядывая. Когда будете уверены, что воспроизвели весь - сравните исходный код с результатом и порефлексируйте. Так как всегда легче запомнить то, что уже знакомо, вы сможете выявить знакомые и незнакомые паттерны проектирования, конструкции и концепции программирования, или же увидите что этому коду далеко до чистого(не очевидные имена переменных, методов и т.д.).
Я сделала это упражнение используя кодовую базу нового проекта и поняла, что рефакторить нужно именно в части снижения когнитивной сложности кода.
В третьей главе автор говорит о важности запоминания синтаксиса в долговременной памяти. И я с этим согласна, потому что если при написании кода приходится искать в интернете информацию по синтаксису, то из-за отвлечения первоначальная мысль может уже забыться. Так же очень важно регулярно повторять новую информацию, чтобы она уложилась в голове и не потерялась. Вообще, на эту тему подробней написано в книге Питера Брауна «Запомнить всё. Усвоение знаний без скуки и зубрежки» - рекомендую к прочтению.

Продолжаю читать «Ум программиста».
В четвертой главе речь идет о том, какая когнитивная нагрузка возникает, когда мы читаем сложный код. В такой ситуации мозг сталкивается с естественными ограничениями рабочей памяти, мы не можем удержать большое количество данных в уме одновременно. Значит нужно свести к минимуму их объем. Чем яснее будет код, тем легче будет его обрабатывать. Самое основное, что приходит в голову - это рефакторинг. Но помимо него автор также предлагает два интересных инструмента:
1. Граф зависимостей - помогает понять фрагмент сложного кода, состоящего из нескольких связанных между собой частей.
2. Таблица состояний - запись промежуточных значений переменных в таблицу помогает читать код, который требует сложных вычислений.
Думаю, что современных IDE с этим отлично помогают и распечатывать код на бумаге совсем не обязательно. Но лично я в сложном коде иногда прибегаю к ручке и бумаге и рисую блок-схемы. Обычно мне это требуется, когда я встречаюсь с распределенными вычислениями.

Пятая глава про чтение кода. В ней автор начинает с ролей переменных, с которыми знакомы практически все разработчики. Вот только оказывается существует 11 ролей переменных! Про счетчики, константы, флаги, накопители и т.д. я как и все знала. Но, например, о переменной «бродяга» я не знала. Иногда просто не задумываешься, что их можно выделить в отдельную роль.
Также один из главных выводов, которые я почерпнула для себя - это довольно простая мысль: понимание текста кода (знание синтаксических концепций) и понимание плана (понимание цели автора кода) - это две большие разницы. С понимаем текста работать легче, ведь для этого нужно уложить знания по языку (фреймворку, библиотеке и т.д.) в долговременную память. А вот для понимания плана нужно, чтобы чистый код писала вся команда разработки, а не только один разработчик.

А еще было приведено довольно неожиданное для меня исследование с соответствующим выводом. Оказывается, что когнитивные способности, указывающие на склонность к программированию - это в первую очередь рабочая память и логическое мышление (тут пока ожидаемо все). Но во вторую очередь помогают языковые способности и только потом математические. Я была уверенна что второе и третье место должны стоять наоборот. Однако, приведенные доказательства меня убедили. Стратегии, использующиеся для углубленного понимания текстов на естественном языке, например визуализация (вот кстати и про блок-схемы!) и резюмирование, могут использоваться и для углубленного понимания кода. Активней пишем документацию к коду, это поможет нам быть лучшими разработчиками во всех смыслах 🙂
Интересно, а ведение блога тоже поможет писать код лучше?

Вчера посетила JVM Day от Т-банка. Конференция мне понравилась, организаторы постарались, и это чувствовалось.
Кратко о докладах, которые мне удалось посетить:
1. Надежная отправка событий в Apache Kafka: от CDC до паттерна Transactional Outbox.
Спикер подробно погрузил в проблематику доклада и рассмотрел все существующие варианты решения проблемы (даже Kafka streams), а также взгляд на хранение Transactional Outbox в postgresql. Было полезно и интересно, советую посмотреть доклад, когда он появится в записи.
2. Оптимизация хранения transactional outbox в Postgres. Это было прямое продолжение первого доклада, но спикер раскрыл тему хранения более подробно. Доклад был полезным, но на некоторых слайдах был очень мелкий текст, который было сложно прочитать. Возможно, при пересмотре в записи такой проблемы не будет.
3. Могут ли Virtual threads заменить Webflux? Самый лучший доклад всего дня, лично на мой взгляд. Автор подробно с хорошими примерами и бенчмарками разобрал разницу в производительности между platform threads, virtual threads и webflux. Самую лучшую производительность показала связка webflux + virtual threads + reactive kafka. Прирост по сравнению с ванильным platform threads около 230%, что внушает уважение. При этом все-таки стоит учитывать, что такая связка не нужна для всех задач, и иногда будет достаточно просто перейти на java 21, без использования webflux. Я же с нетерпением жду, когда в компании будет возможность перейти на последнюю версию java, ведь в моем проекте уже используется webflux.
4. Fluent API на Java. Автор очень интересно рассказал о приемах проектирования Fluent API по шагам. Даже live coding был. Такой формат на мой взгляд отлично раскрыл тему и подходит даже новичкам в java. Однозначно рекомендую посмотреть доклад, особенно, если вы разрабатываете библиотеку для многих команд или фреймворк.
5. Модульность в Java. Доклад был «об истории развития модульности в Java и немного о нюансах ее проектирования». И его проблема была на мой взгляд именно в том, что автор много внимания уделил истории развития. Если бы чуть больше времени было посвящено рассмотрению Spring Modulith, то доклад бы был интереснее и полезнее.

Первые две лекции были из секции backend, поэтому, несмотря на приведенные примеры на Java, должны быть полезны всем backend разработчикам. К сожалению, лекции из секции Scala мне посетить не удалось. Планирую посмотреть их в записи. Также не успела посетить доклад «Деградируем со вкусом», который заинтересовал меня своим описанием. Обязательно посмотрю его в записи.
В целом, на мой взгляд такие конференции очень полезны, не только своими докладами, но и возможностью пообщаться с коллегами из разных компаний, посмотреть «а как это у них» и почерпнуть для себя новые полезные практики.
Лето закончилось продуктивно 🙃

В эту субботу снова была на конференции - на этот раз от Сбера.
1. А мы и не знали. Малоизвестные и мощные фичи Spring Data проектов.
Автор доклада - контрибьютор в модуль Spring Data и на последнем jpoint’e рассказывал о проблемах JDBC. Про интерфейс Persistable для upsert операций и ScrollingApi c keyset пагинацией я уже знала, а вот про возможность отдать entity публикацию различных событий с помощью @DomainEvents или использования AbstractAggregateRoot template class узнала только на этом докладе.
2. Двоичная Java: CRaC и нативная компиляция.
Доклад интересный, но сложно сказать на сколько применим в реалиях моей текущей работы. Автор говорил об инструментах, которые сокращают время старта приложения: Class Data Sharing, AOT + GraalVM, CRaC (Coordinated Restore at Checkpoint). Но CRaC решает проблему не только времени запуска, но и времени прогрева приложения, потому что можно создать контрольную точку в любое время.
3. Spring Security ACL, о котором мы не знали. Забытое сокровище или ловушка?
Вообще я не знала об этом инструменте, но не факт, что начну применять его после доклада, т.к. в нем есть много неоднозначных решений и ограничений. Показалось что в реалиях микросервисной архитектуры у приложения узкое место возникнет именно в Spring Security ACL. Отвечая на вопрос из названия - скорее ловушка 😁 Но сам доклад был очень хороший, автор смог осветить интрумент со стороны разработчика наиболее подробно, даже показал свой ход размышлений при применении ACL. А еще было очень много юмора, больше всего запомнилось: «Как учит нас Spring, свою первую конфигурацию - укради» 😁
4. Kotlin- и Java-разработка в open source.
Автор сразу предупредил, что будет много «инфоцыганства» и не обманул 😁
Доклад полезен тем, кто хочет организовать свой open source проект, а мне было просто интересно послушать.
В следующий раз на конференцию Сбера надо захватить теплую кофту, три лекции было ужасно холодно, потом организаторы ослабили вентиляцию.

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

Еще в моем проекте случился -1 коллега и я наткнулась на подходящую иллюстрацию этой ситуации.

Подбираюсь к концу книги «Ум программиста».

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

Девятая глава посвящена плохому коду, борьбе с ним и когнитивной нагрузке, которая его вызывает. Кстати, code smells и плохие имена также тесно связаны. God классы и методы, длинный список принимаемых параметров, большое количество ветвлений и многое другое - все это создает дополнительную когнитивную нагрузку на программиста, и это факт, подтвержденный наукой. Автор приводит ссылки на соответствующие исследования. У нас в команде принято не мерджить код, в котором есть много замечаний от сонара. Современные IDE отлично указывают на возможные проблемы в коде, но я еще поставила плагин SonarLint локально. И предпочитаю даже не пушить в репозиторий код, у которого есть замечания от сонара. К сожалению, это возможно не всегда. Иногда очень срочный релиз заставляет прилеплять костыль. Но важно, чтобы в следующей задаче разработчик устранил эти замечания. Таким образом кодовая база всегда содержится в чистоте.

Следующая глава предлагает идеи для совершенствования навыка решения сложных задач. Кстати, многие программисты считают, что навык решения задач - это общий навык, но на самом деле это не так. Я тоже так считала, но автор приводит убедительные доказательства того, что это не так. Стратегии решения задач из одной области крайне слабо помогают решать задачи в другой области. Помогают близкие области (изучение второго языка программирования) и знания, хранящиеся в долговременной памяти. Улучшить решение задач помогает доведение до уровня «на автомате». Когда можно действовать бессознательно, то это снижает когнитивную нагрузку. Для того чтобы найти элемент array[4] в [7, 4, 2, 1, 5] начинающему нужно больше времени и усилий для размышлений: «Начинается с 0, третий элемент считается за четвертый». В то время как разработчик, у которого информация уже попала на автономный этап, сразу укажет, что array[4] == 5. Автоматизация помогает программировать быстрее, т.к. не происходит многочисленных переключений контекста, а решение задачи происходит очень быстро и без лишних затрат энергии, потому что извлечение из памяти легче, чем активные размышления над задачей.
Для улучшения навыков, в которых мы еще не достигли полной автоматизации, автор предлагает два решения:
1. Осознанная практика.
Способов много: Можно писать много похожих, но отличающихся друг от друга программ. Когда вы сталкиваетесь со сложной концепцией программирования, можно адаптировать другие программы, а не писать их с самого начала. Интервальное повторение поможет закрепить навык - каждый день уделяйте немного времени практике и продолжайте повторять до тех пор, пока вы не доведете выполнение задачи до автоматизма.
2. Примеры с решением на практике.
Изучайте код и процесс его написания. Можно создать кружок чтения кода или работать вместе с коллегами, которые в этом заинтересованы. Регулярно обменивайтесь кодом и его объяснениями. Можно самостоятельно читать код, например open source проекты на GitHub. В выбранном вами коде не должно быть много незнакомых слов, понятий, которые вызовут внешнюю когнитивную нагрузку. Также полезным оказывается чтение блогов, в которых программисты рассказывают о своем опыте решения задач 🙂

Осталась последняя часть, в которой идет речь о совместной работе над кодом.