Всем привет! Это разработческий канал от сотрудников Red Collar.
Каждую неделю один из сотрудников компании рассказывает о своих задачах, сложностях, решениях, делится полезными ссылками и мыслями на тему разработки.

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

В компании занимаемся двумя направлениями:
- Разработкой сложных продуктов, сервисов для сотен тысяч пользователей для ведущих финтех-, телеком-, IT-, HoReCa- и логистических компаний.
- Созданием эстетичных корпоративных и промосайтов, которые становятся лучшими в своей сфере и берут самые сложные международные награды.

По тегам можно найти темы:
#rdclr_frontend — #Vanilla_JS #JavaScript #React #WebGL

#rdclr_backend — #Java #Python #PHP #NN

#rdclr_DevOps

#rdclr_QA

#product (мысли, применимые к сервисно-продуктовым историям)
#aesthetic (про эстетичность интерфейсов) #teamlead — про роль, практики и рост в тим-лида
#optimization (про оптимизацию кода для скорости и плавности работы проекта) и #library (набор инструментов для упрощения жизни разработчика)
#read (полезные ссылки для изучения нового материала)
#meme (на посмеяться) и #news (новости)

Чтобы совместить два тега — введите оба в поисковую строку канала.

Всем привет! Меня зовут Андрей и в компании Red Collar я занимаю позицию Backend Java-разработчика. На этой неделе у меня будет много ревью-кода от стажеров до middle разработчиков, поэтому вначале рассмотрим решения и инструменты, с помощью которых можно повысить качество проекта.

#rdclr_backend #java

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

В разработке Spring-based приложений зарекомендовал себя подход разделения приложения на «слои» — Controller -> Service -> Repository (в базовом представлении). При его использовании важно следить, чтобы нижний слой не имел доступа к слою выше. Наших данных это тоже касается и, если в слое контроллеров у нас участвуют сущности БД, то это считается плохим тоном и требуется проводить рефакторинг. Тут нам на помощь приходят DTO (Data Transfer Object), в которые мы заносим данные из наших сущностей и оперируем уже ими.

И, чтобы не делать это вручную, можно использовать библиотеку MapStruct. В лучших традициях спринга она помогает с помощью «магических» аннотаций конвертировать один объект в другой, снимая с нас большой пласт работы.
Попробовав однажды, писать вручную уже не захочется!

Ссылка на библиотеку — https://mapstruct.org/

#rdclr_backend #java #library

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

Если делать прямо в лоб, то мы пишем большой SQL запрос, где будет перебор параметров фильтра в блоке where. Минусы тут очевидны: при увеличении размеров фильтра будет раздуваться и SQL запрос, из чего следует повышение сложности запроса, ухудшение его читаемости, сложность дебага и рост ошибок.

Тут на помощь приходит CriteriaApi. Данный пакет инструментов позволяет динамически строить запрос в БД, оперируя объектами, а не самим SQL. Вдобавок к этому, Spring фреймворк предоставляет нам интерфейс Specification<T>, который упрощает взаимодействие с CriteriaApi. Пример работы приведен на картинке ниже.

#rdclr_backend #java

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

Задача состоит в следующем: отловить ошибку и превратить стек-трейс в понятое всем сообщение. В этом нам поможет «магия» от спринга в виде аннотации @RestControllerAdvise, которую мы повесим над классом-обработчиком. И так же аннотация @ExceptionHandler, с помощью который мы обозначаем, какие именно ошибки перехватывать.

Если Вам требуется возвращать не объект в респонсе, а какое-то представление (например, html), то можете воспользоваться @ControllerAdvise. Разница между ними такая же, как и между @Controller и @RestController. В итоге получаем единую точку обработки всех исключений, и если в приложении что-то случится, весь поток выполнения программы перейдет в RestControllerAdvise.

Также, глобальная обработка ошибок хороша тем, что мы можем задействовать i18n в единственном месте (с помощью MessageSource), а не размазывать логику по проекту.

#rdclr_backend #java

Ловушка @Transactional или использование Self-inject’ов
В бине имеется 2 метода: a() и b(), помеченных аннотацией @Transactional. Если мы из метода а() вызовем метод b() — как поведет себя транзакция метода b()?
Правильный ответ — транзакция метода b() не выполнится.

Один из самых популярных вопросов на собеседовании для java-разработчиков вплоть до middle позиций включительно. В реальной жизни тоже встречается довольно часто, поэтому стоит следить за аннотациями над методами и понимать, как они работают.

Почему же транзакция не выполнится? Дело в том, что когда мы делаем someService.callMethod() — вызывается метод Бина, а когда внутри a() дергаем b() — вызывается метод Класса, т.е. без каких-либо прокси-оберток Спринга и прочего. Именно из-за этого транзакция метода b() и не выполнится, потому что сам класс про неё ничего не знает.

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

#rdclr_backend #java

АОП. Аспектно-ориентированное программирование

Всем привет! С вами снова Андрей, java-разработчик. Мы продолжим говорить об экосистеме java и смежных вещах. Сегодня затронем АОП. Тема очень обширная, поэтому в этой мини-статье заденем минимальные основы.

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

Пару недель назад мы уже краем касались этой темы, когда рассматривали self-inject’ы и Transactional-аннотацию. Под этой аннотацией, как и под многими другими, как раз таки и скрывается механизм аспектно-ориентированного программирования.

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

Давайте попробуем разобраться на простом примере (примеры будут сразу в следующих постах). Для начала, в pom.xml, вы должны иметь следующие зависимости: spring-boot-starter-web, spring-boot-starter-aop. Это минимальный набор, чтобы начать изучать spring aop. Рассмотрим самописные аспекты по логированию какой-то информации сигнатуре метода и по доступу к файлу.

#rdclr_backend #java

Аспект для логирования сигнатуры метода. Связан через аннотацию LogSomething (написана вручную, в ней нет ничего особенного)

#rdclr_backend #java

Аспект для логирования сигнатуры метода. Связан через аннотацию CheckFileAccess (написана вручную, в ней тоже нет ничего особенного)

#rdclr_backend #java

Сервис, где методы будут помечены созданными аннотациями LogSomething и CheckFileAccess

#rdclr_backend #java

Spring framework: под капотом

До этого мы с вами разбирали основные инструменты фреймворка Spring, которые помогают сделать нашу разработку проще.

Настало время разобраться, как же работает та самая «магия» Спринга под капотом. С помощью каких инструментов создаются бины, инжект бинов, что такое в принципе понятие Бин. Весь процесс от запуска приложения, до его окончательного рабочего состояния. И в этом нам поможет довольно известный разработчик Евгений Борисов, который в своих лекциях посвящает нас в работу движка фреймворка на самом низком уровне. Для качественной разработки эти знания просто необходимы, поэтому на собеседованиях java-разработчиков довольно часто попадаются вопросы этой тематики.

У Евгения на ютубе имеется целый цикл лекций по Спрингу на самые разные темы. Предлагаю вам начать изучение с одной из самых популярных из его лекций — Spring-потрошитель. Не пугайтесь, что видео 2014 года: оно актуально и по сей день, ибо под капотом фреймворк почти не изменился.

Часть 1 https://youtu.be/BmBr5diz8WA
Часть 2 https://youtu.be/cou_qomYLNU

#rdclr_backend #java #read

Java. Какую версию выбрать?

Начиная с 2017 года релизная политика версий java в корне поменялась. Вместо продолжительных застоев в несколько лет с накоплением большого количества фич, было принято решение перейти на релизы каждые полгода, выпуская маленькими партиями новый функционал. Если раньше можно было выбрать просто 8 версию, которая являлась LTS, и не прогадать с выбором, то теперь версий стало куда больше (на текущий момент уже 17). В связи с этим у многих новичков встает очевидный вопрос: как выбрать версию джавы? Может я просто возьму последнюю и все? Не совсем так, давайте разбираться.

Основным провайдером java является компания Oracle, которая предоставляет нам 2 типа jdk: OpenJdk и OracleJdk. Основное их отличие в том, что OracleJdk является платной и содержит в себе поддержку от самой компании (вы сможете им позвонить или написать письмо), если у вас возникнут какие-то проблемы. Такой вариант обычно необходим только очень большим продуктам и компаниям, поэтому мы его отбрасываем и будем пользоваться бесплатной версией. Скачать её можно тут – http://jdk.java.net

Теперь про версионность. Основной выбор всегда падает на LTS (Long Time Support) версии java, так как из-за долгой поддержки и исправления багов эти версии наиболее стабильны и преподносят меньшее число сюрпризов в продакшне. На текущий момент в мире все еще преобладает использование java 8, которая вышла в 2014 году. В основном это связано с тем, что на этой версии уже написаны крайне массивные продукты, которые потребуют больших трудозатрат и средств для переноса на более новые версии. А так как эти огромные продукты продолжают жить, то продолжает жить и java 8.

Для новых решений зачастую берется просто последняя LTS версия джавы. Да, вот так вот просто! До недавнего времени это была java 11, на текущий момент java 17. Но так как 17 версия все еще очень молодая (ей всего пару месяцев), я бы рекомендовал вам пока что выбрать 11 версию для изучения, так как не все еще основные инструменты и библиотеки успели переехать на новый релиз.

Также предлагаю вам посмотреть наикрутейшее выступление Тагира Валеева на JockerConf про то, как менялась java под капотом с 9 по 14 версию. https://youtu.be/5Y0Alqb9H_I

#rdclr_backend #java #read

Java. Какую версию выбрать? Часть 2

Помимо основного вендора java в лице Oracle, существуют и другие выпуски от других компаний. Давайте их рассмотрим:

🍒 1) AdoptOpenJDK
Проект, поддерживаемый сообществом. Команда выпускает билды, основанные на OpenJDK, отличие лишь в более долгосрочной поддержке. Команда занимается только билдами и не выпускает патчи для openjdk

🍩 2) Red Hat OpenJDK
Основана на версиях сборки OpenJDK, является коммерческим продуктом с платной поддержкой. В своих версиях компания нацелена на исправления безопасности в OpenJDK. В прошлом Red Hat отвечали за security-апдейты Java 6 и 7.

🫀 3) Azul Zulu
Основана на версиях OpenJDK, поставляется как open-source, но так же имеется — по сравнению с OracleJDK — более длительная коммерческая поддержка java 9, 13, 15.

🩱4) IBM JDK
Компании IBM требовалось написать свой собственный JIT-компилятор и свою собственную JVM, чтобы программы, написанные на java, могли запускаться на их мейнфреймах и при этом не заставлять разработчиков изучать новую java. Поэтому эти версии, с точки зрения программиста, практически идентичны.

🥡 5) Amazon Correto
Бесплатная версия сборки OpenJDK с долгосрочной поддержкой. Данная версия нацелена на максимальную производительность в облачных вычислениях. Так же Амазон каждый квартал выпускает багфиксы, что позволяет более оперативно устранять уязвимости.

🛺 6) Liberica JDK
Отечественная версия java, основанной также на OpenJDK. Плюсы перед OpenJDK все те же, что и других вендоров. Она бесплатна, более продолжительная коммерческая поддержка, частые выпуски обновлений безопасности, маленький размер контейнера (минимальный — всего 43.5мб).

Еще существенным плюсом является тот факт, что Liberica JDK Pro была внесена в реестр российского ПО. Это означает расширение диапазона применения Liberica JDK в государственных информационных системах, где крайне важна защита ПО от внешних факторов (например, санкций).

#rdclr_backend #java #read

Микросервсиная архитекутера

Наверняка вы уже работали с приложением, построенным на микросервисах, а если нет, то слышали об этой архитектуре.

Можно взять и разбить приложение на микросервисы. Но это не даст гарантий, что проект будет легко поддерживать и масшабировать, гибко изменять код — рано или поздно вы столкнетесь с проблемами. Для решения таких проблем как раз и появились различные принципы программирования — SOLID, DRY, KISS, CQRS.

#rdclr_backend #Java

Друзья, привет! На связи всё так же я, Павел, Java-разработчик Red Collar. 🤝

Решил потестить новый формат, чтобы текст легче воспринимался, а иллюстрации кода не терялись потом в поиске.

В общем, встречайте первую статью в Telegraph! Собрал здесь все принципы SOLID с примерами, подсветил сложные моменты, про всё рассказал подробно. 🦾

Читайте тут: https://telegra.ph/Open-closed--princip-otkrytosti--zakrytosti-05-16


#rdclr_backend #Java

Друзья, всем привет! Это вновь я, Java-разработчик Red Collar Павел.
Продолжаю тестить Телеграф и рассказывать вам о фишках разработки. На этот раз — о Spring DATA JDBC.

Это классная альтернатива JPA, но у неё, конечно, есть свои подводные камни.

Читайте о них здесь: https://telegra.ph/Spring-DATA-JDBC-05-24

#rdclr_backend #Java