На этой неделе у меня было 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. В выбранном вами коде не должно быть много незнакомых слов, понятий, которые вызовут внешнюю когнитивную нагрузку. Также полезным оказывается чтение блогов, в которых программисты рассказывают о своем опыте решения задач 🙂

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

Это был самый теплый и переключающий отпуск.
Ни каких экранов и интернета.
2 прочитанных сборника рассказов Айзека Азимова.
5 видов фруктов в день.
Очень много спорта.
Снорклинг среди коралловых рифов и их обитателей.
Как итог - сегодня я с трудом вспомнила пароль от рабочего ноутбука.

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

Это Loqseq – проект с открытым исходным кодом для ведения заметок, списка дел и личной базы знаний. Он поддерживает Markdown, а ещё все ваши файлы хранятся локально.
Я уже пользовалась ранее Obsidian, но его интерфейс не такой уж дружелюбный для новичка и на рабочий ноутбук его невозможно установить в отличие от Loqseq.
Ведение списка дел очень простое: достаточно ввести /NOW и текст после будет считаться задачей.
Также присутствует маркетплейс плагинов и тем (они, кстати, все просто на css) у которых тоже открытый исходный код. Особенно мне понравился плагин с таймером помодоро прямо в интерфейсе Loqseq. Таким образом получается очень удобный интерфейс для сфокусированной работы.
Loqseq умеет строить графы и в нём можно создавать карточки для запоминания. Есть возможность сложного поиска (по запросам, типам записей, датам). Но подробнее пока ничего не смогу написать про этот функционал, потому что практически не пользовалась.

Больше всего я использую это приложение в качестве дневника. В течение дня обязательно пишу туда все свои рабочие мысли, например: «завести задачу на обновление библиотеки», «когда приступлю к следующей задаче - надо проверить, что в базе данных присутствуют индексы на поля name» и т.д. Такая практика очень помогает работать сфокусировано над текущей задачей и при этом не терять мысли, которые кажутся ценными в этот момент времени. К ним можно вернутся позже и обдумать уже более тщательно. В конце дня я трачу примерно 5 минут на подведение итогов прошедшего дня и планированием следующего, записываю все со ссылкой на завтрашний день. Благодаря этому с работы я выхожу без навязчивых мыслей о делах прошедшего дня - ведь его итог я уже подвела «письменно». А утром следующего дня очень легко возвращаться к работе и рассказывать на дейлике о сложностях и планах. Каждый раз утром возвращаясь к этим рабочим заметкам, ловлю себя на ощущении, что вечером я просто поставила задачи на паузу, а утром бесшовно к ним возвращаюсь. Это как загрузка в играх, просто спокойно продолжаешь там где остановился. Именно так выглядит самая основная польза этого инструмента для меня.

▎Реактивное программирование

Начало года для меня выдалось весьма насыщенным: я выступила перед нашей командой Java-разработчиков с темой — реактивное программирование. Оказалось, что, не считая нашего лида, у меня самый большой опыт в этой области. Это было волнительно — пульс подскакивал до 132 ударов в минуту, и я поняла, что публичные выступления нужно практиковать чаще.

В статье немного того о чем я успела рассказать.

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

Хочу просто оставить самую теплую фотографию из последнего отпуска здесь.

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

▎Внимательное чтение кода может сэкономить время

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

Что же произошло? Дело в том, что я не сталкивалась с таким багом ранее. Однако, когда я увидела код, у меня возникло подозрение. Вот фрагмент запроса, который привлек мое внимание:

SELECT string_agg(employee, ‘; ’),

Использование символа «;» в SQL-запросе, который будет обработан фреймворком ORM, — это потенциально опасная практика. Без заглядывания в исходники вы не можете быть уверены, какой результат получится в итоге.

Затем я заглянула в логи и увидела SQL-запрос, сгенерированный Spring JPA:

SELECT string_agg(employee, ‘; offset ? rows fetch first ? rows only’),

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

По всей видимости, Spring JPA, увидев символ «;», который используется в конце запроса, решил, что запрос завершен. Это и стало причиной бага.

Решение оказалось простым: мы заменили символ «;» на «,» в запросе. И всё заработало! 😊

Я стала сертифицированным scrum мастером. Уже некоторое время веду все церемонии в своей большой команде и познаю все прелести и боли этого дела. Из плюсов - процессы в команде меняются в лучшую сторону и я (пока) получаю позитивную обратную связь. Из минусов - активностей стало больше, а вот времени нет.
Еще есть сложность в тех ситуациях, когда мне нужно переключаться между двумя своими личностями - scrum мастера и разработчика 🙃
В таких ситуациях нужно как scrum мастер - продолжать фасилитировать событие и помогать команде выработать решение самостоятельно, и одновременно как разработчик - предлагать свои идеи. Сложно отлавливать такие ситуации, и не начинать продвигать только свои интересы, но я стараюсь.