Backwards compatibility

При создании любого открытого API, будь то HTTP, gRPC endpoint, public метод в Java - необходимо помнить про обратную совместимость.

А суть его в следующем:
код существующих клиентов открытого API не должен сломаться при обновлении этого API. Старые клиенты должны уметь работать с новой версией API.

К сожалении, не всегда очевидно - обратно совместимо ли какое-то изменении в API или нет.

Но есть несколько правил, которых можно придерживаться для этого:

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

2. Не делать поля обязательными в существующих сообщениях (в новых сообщениях тоже стараться делать поля optional)

3. Не удалять или переименовать уже существующие компоненты (переименование - это аналог “удалить + добавить поле”). Более того, придется продолжать заполнять старые поля, даже если они стали избыточными (redundant)

4. Не менять типы существующих полей

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

Вывод
Не так-то просто писать открытый API, особенно если им пользуется большое количество клиентов.
Да и становится понятно, почему в Java Core столько старых классов и методов 🙂

Сode review н-нада?

Многие поддержали данное предложение, что ж, давайте попробуем реализовать его!

Кто хочет, чтобы я провел code review вашего кода - присылайте ссылку на github в комменты под этим постом.
Я рандомно выберу один проект и в следующем посте опубликаю краткое резюме по коду с ссылкой на код с моими комментариями

Условия участия:
- Проект опубликован на github
- Весь код в виде одного пул реквеста или коммита
- Чем больше кода - тем больше добавить описания о нем в README файле (чтобы я понимал о чем проект)
- Не удалять пул реквест или коммит после code review
- Согласие на то, что ваш разбор попадет в этот канал
- Ссылки жду до 6 мая включительно

P.S. Если зайдет рубрика, то можем ввести ее на постоянной основе, например, каждое первое число
#dmdev_code_review

15.000 подписчиков на YouTube!
Это в 1,5 раза больше людей, чем в городе, котором я вырос.

И всех этих людей связывает один общий интерес - Java.

3 года прошло, как я создал канал DMdev.
И он совсем не похож на среднестатистический канал ютуба.

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

За это время:
- уже более 1.000.000 просмотров
- 666 видео
- 12 курсов (пройдя которые - действительно можно стать разработчиком)

Благодарю каждого за доверие и активное участие!
Без вас - ничего этого не было бы🙌🏻

P.S. 🔔 Напоминаю, что сегодня последний день, как я жду ваши ссылки на гитхаб для code review (подробнее в посте выше)

#dmdev_code_review
Как и обещал, выбрал одного из участников, чтобы провести code review.

Хотелось бы отметить общие частовстречаемые ошибки, которые в то же самое время очень важны:

1. Не следует изменять статические поля в нестатическом контексте. Чаще всего это приводит к ошибкам в многопоточности или попросту неверно работает код.

2. Четко разбивать приложение на слои и следовать строгой коммуникации между ними. Например, избегая выполнения sql запросов напрямую из сервлетов. Иначе это приведет к спаггети коду и тесной взаимосвязи всего со всеми, что в принципе делает возможность рефакторинга крайне затруднительной.

3. Не стоит писать код на исключениях - клиентский код потом становится громоздким с кучей try/catch блоков. Пробрасывать исключения следует тогда, когда действительно произошла ИСКЛЮЧИТЕЛЬНАЯ ситуация, которую никак не избежать. Например, гораздо приятнее возвращать true/false в методе delete вместо пробрасывания исключения, если такой сущности не оказалось по переданному id.

4. Связанно с предыдущим пунктом: не нужно проглатывать исключение, пробрасывая свое кастомное - иначе теряется stacktrace рутовой ошибки и будет очень сложно понять что произошло. Если нужно обернуть одно исключение в другое - просто передавайте его как параметр в конструктор: new DatabaseException(sqlException)

5. Разумно подходить к использованию Optional & Streams. Какой-то код лучше писать в функциональном стиле, какой-то в императивном, какой-то в комбинации двух предыдущих. Но в любом случае стоит граммотно использовать все подходы. Возьмем простой случай: возвращать Optional из метода, который может вернуть null. И, наоборот, если метод всегда возвращает объект - то не стоит оборачивать его в Optional, ибо это доставляет неудобства клиенту.

6. Давать хорошие имена переменным, методам, классам - всему в коде. Иначе очень сильно усложняется чтение кода, на которое программист тратит большую часть своего рабочего времени. Особенно избегать таких имен, которые подразумевают только ЧТЕНИЕ, а по факту там происходит изменения состояния объектов - т.е. ЗАПИСЬ. Например, findProduct(productId) - а внутри изменение состояния объекта Product.

P.S. Весь список комментариев по code review можно найти в пул реквесте по ссылке

P.P.S. Если есть вопросы по коду/моим замечаниям, что я оставил - то можете задавать их прям здесь под постом в комментариях

Ребят, в конце июня стартую последнюю 2-ую ступень менторства в этом году

Осталось 4 места 0 мест.
Так что, кто желает окунуться в интенсивное обучение Java со мной - welcome.

Записаться и почитать подробнее можно по ссылке:
https://dmdev.tilda.ws/second-level

#dmdev_qa - под этим хештегом отвечаю на ваши вопросы.
Вопрос на фото, ответ ниже👇

Этот подход зародился очень давно, можно сказать, исторически так сложилось. Даже в книгах писалось, что так нужно делать. Раньше это считалось best practices.

Потому что:
1️⃣ Ты легко можешь создать Dynamic Proxy, не прибегая к сторонним библиотекам и делая прокси через наследование, ибо у тебя есть интерфейс со всеми методами. Но сейчас по умолчанию даже Spring делает cglib прокси через наследование, ибо этот подход оказался более жизнеспособным.

2️⃣ Ты можешь описывать документацию над методами в интерфейсах или выносить туда константы (например, длинные SQL запросы для Repository), чтобы не делать этого в классах. Но сейчас тоже не актуально, ибо интерфейсы созданы именно для функционала, а не как хранилище констант, и второе - современные среды разработки и так умеют сворачивать документацию над методами, чтобы не смущать программистов.

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

Теория бесполезна без практики

Сейчас сел перечитывать книгу “От 800 метров до марафона” Джека Дэниелса, которую прочел еще в прошлом году, когда только начал заниматься бегом. Только в этот раз я осознал, на сколько возросло мое понимание написанного в этой книге. Каждое предложение просто отпечатывалось в моем мозгу (наверное, даже на всю жизнь). Тогда как в прошлый раз - все просто выветривалось и очень быстро.

Если раньше я мог пролистывать часть страниц, думая, что это “не важно”, или давая себе совсем другие смыслы написанному, нежели закладывал автор (пытаясь понять и запомнить по-своему) - то сейчас как будто мир заиграл новыми красками. В голове всплывал лишь один вопрос - как я не понимал этого 10 месяцев назад?

А ответ довольно прост - я все эти 10 месяцев просто практиковался в беге, постоянно и методично. Экспериментируя, анализируя все, что делаю “на практике”.

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

Практикуй то, что изучаешь!

Может все-таки велосипед?

Каждый раз, когда приступаю к написанию какого-то функционала, руки так и рвутся создать что-то с “нуля”. Чтобы было в этот раз уж точно гибко, расширяемо, без багов, а главное - свое!

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

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

Например, если мне нужно создать endpoint, который возвращает список чего-либо, я просто посмотрю как его реализовывают такие компании как Google, Amazon и т.д. Крупные компании имеют свойство хорошо документировать свои решения и даже выкладывать его в public доступ.

Поэтому, я открываю API документацию (в нашем случае list endpoint) и начинаю читать ее. И практически всегда я точно нахожу для себя что-то полезное, о чем “не подумал“, и что могу переиспользовать для своего решения 🙂

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

Старт: 4 сентября
Продолжительность: ~3,5 месяца
Свободно: 5 мест 1 место

Вся подробная информация о менторстве DMdev и запись тут:
https://dmdev.tilda.ws/first-level

PS. Вопросы можно также задавать здесь в комментариях
PPS. Пример финального проекта по окончании менторства есть на YouTube (проект можно выбрать абсолютно любой)

Полнотекстовый поиск

Пожалуй, один из немногих инструментов, который остался, надёжно закрепился и активно используется у меня при решении многих проблем при разработке ПО - это полнотекстовый поиск!

Хочешь найти применение класса, метода, куска кода в каком-то репозитории, да даже любой интересующий тебя ключ в yaml файле? Используй полнотекстовый поиск (особенно когда нет возможности открыть проект в среде разработки или это заняло бы неоправданно много времени).

Из совсем недавних примеров…

1. На менторстве при старте интеграционных тестов происходило обращение к Postgres по урлу 192.168.0.150:5432, хотя должен был определяться порт динамически из библиотеки testcontainers. Полнотекстовый поиск по ip 192.168.0.150 - и оказывается этот урл указан в забытом файле hibernate.cfg.xml.

2. Точно помнишь, что в каком-то видео на каком-то курсе dmdev слышал/видел информацию об аннотации @DynamicPropertySource. Открываешь индекс dmdev, ctrl + F - и находишь то, что хотел.

Так что смело используй полнотекстовый поиск как одно из возможных и очень хороших решений твоей проблемы!

PS. И это я еще забыл упомянуть, как он меня выручает при поиске чего-либо в многотерабайтном монорепозитории гугла, который в принципе невозможно открыть и развернуть локально

Смогу ли я устроиться на работу?

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

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

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

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

Поэтому что бы я сделал:

1️⃣ Лучше формулировал бы вопрос. Хороший вопрос - это уже половина ответа. Добавил информацию в каком городе буду искать работу, сколько ресурсов денежных и временных у меня есть для обучения. Кто-то может позволить только самообучение, кто-то наставника. От чего зависит и скорость, и качество обучения.

2️⃣ На каком языке программирования я хочу сфокусироваться. За двумя зайцами погонишься - ни одного не поймаешь.

3️⃣ Предварительно пробил информацию о рынке труда. Сейчас в каждой локации/стране есть сайты-агрегаторы об открытых вакансиях. Лишь благодаря такому анализу я могу вообще передумать изучать программирование или увеличить в 4 раза свои шансы на получение работы, выбрав, например, язык Java, а не C#. Потому что в моем регионе вакансий на Java в 4 раза больше. Или даже запланировал смену места жительства, ибо в городе, где я живу - с программированием все обстоит не очень.

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

Напоминаю, что еще осталось 1 место на менторство 1 ступени, которое уже стартует через 2 недели!

Можно писать в личку, в комментариях к посту, или просто оставить заявку на сайте https://dmdev.tilda.ws/first-level (там же вся информация о процессе обучения)

Чем ты готов пожертвовать ради достижения цели?

Эти мысли я решил изложить здесь в тему предыдущего поста…

Для того, чтобы достичь хорошего уровня в чем-либо - необходимо заплатить соответствующую цену. И чем выше уровень, тем сложнее и больше цена.

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

Чем потребуется пожертвовать в угоду этой цели?
- меньше времени уделять семье
- уволиться с работы
- финансами
- комфортом
- забросить любимое хобби
- вставать на 2 часа раньше или меньше спать

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

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

Делись к комментариях, чем тебе пришлось пожертвовать, чтобы стать программистом или достичь любой другой цели? А я в другом посте поделюсь своими примерами…

Самый сложный фреймворк

Я не раз говорил, что считаю одним из самых сложных фреймворков в Java - это Hibernate. Именно при его использовании допускается большинство ошибок в приложениях. А т.к. это ORM фреймворк, что означает большое количество запросов в СУБД, а значит много IO операций и проблемы с перформансом всего приложения в целом.

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

Как бы то ни было, из огромного пласта информации я хочу выделить всего лишь 4 основных аспекта, понимание которых будет более чем достаточно, чтобы избавиться от страха в использовании Hibernate и понять его раз и навсегда:

1. Кэш первого уровня (First Level Cache).
Невозможно работать с Hibernate не создавая сессию. И ни одна сессия невозможна без кэша первого уровня, ибо это ее неотъемлемая часть. Проще говоря - это обычный ассоциативный массив, где ключом является id сущности, а значением - сама сущность, ассоциированная с сессией. Такая простота почему-то все равно вводит в заблуждение многих программистов.

2. Жизненный цикл сущности (Entity Lifecycle).
Этот пункт основывается на предыдущем, потому что каждое состояние сущности так или иначе означает “находится ли сущность в кэше первого уровня той или иной сессии”. Вообще, я считаю, что жизненный цикл любого фреймворка или инструмента - это must have откуда нужно начать изучать его, буть то это JUnit, Spring, Hibernate, Maven, Gradle, Apache Tomcat, Asynchronous programming, etc. Это как Java Core для понимая более сложных тем.

3. Паттерн прокси (Proxy).
Многогранность этого паттерна воистину достойна того, чтобы его изучить и понять как следует. Он встречается практически в любом фреймворке, только с разными применениями, начиная от mock/spy в JUnit, добавление динамического функционала для Spring beans, и заканчивая ленивой инициализацией сущностей и коллекций в Hibernate. Именно отсюда черпает свою славу знаменитое исключение LazyInitializationException (естественно вместе с предыдущими двумя пунктами).

4. N + 1 проблема (N + 1 selects problem).
Для любого backend языка программирования невозможно обойтись без общения с СУБД, а знание SQL - это навык, который должен занимать первую строчку в рейтинге у таких программистов. Поэтому понимание того, как оптимально использовать ORM фреймворк Hibernate для работы с СУБД, держа в уме предыдущие 3 пункта - и есть показатель отличного качества и хорошей квалификации Java разработчика.

🎁 Best practices при использовании Hibernate я рассказываю в этом небольшом видео

#11 Мой путь

Искал я работу просто выложив резюме на сайте jobs.dev.by, указав все свои навыки, которые я получил за 3 курса университета, самообучения, бесплатных курсов и лаборатории компании EPAM Systems c желаемой зарплатой 650$. Я думал на тот момент, что этого будет более чем достаточно. Ибо если никто не ответит - значит ничего страшного, у меня есть EPAM. А на меньшее и нет смысла менять место работы, проще сидеть ровно. Тем более от учебы вообще никак не отвлекало ничего неделание в лаборатории. А Linkedin на тот момент еще не был на столько раскручен, чтобы я решил использовать его для поиска работы.

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

Само собеседование проходило в небольшом кабинете, где было кроме меня еще трое человек. Потом я узнал, что это были руководитель департамента разработки и 2 ведущих Java разработчика, которые собственно и искали джунов себе на проекты. Спрашивали в основном только Java Core. Когда беседа вдруг заходила о фреймворках по моей инициативе, то меня, наоборот, останавливали и спрашивали о том, смогу ли я вместо Hibernate написать все на JDBC. И, как я понял позднее, это было связано с тем, что у них не было фреймворков как таковых, все на Java Core или что-то свое самописное. Например, вместо Hibernate они использовали Bodhi, который сами же и разработали.

Само собеседование продлилось около часа. Я им определенно понравился, потому что буквально сразу же после окончания мне предложили работать в их компании с зарплатой в 700$. Недолго думая, я конечно же согласился. На одной чаше весов лаборатория EPAM Systems с зарплатой 300$ и ожиданием задач на реальном проекте в будущем, а на другой - новый проект прямо сейчас и 700$.

Все, что мне оставалось сделать - это поговорить об увольнении со своим ментором в лаборатории и уволиться с EPAM Systems. Что я собственно и сделал в течение следующих недель - увидев впервые и подержав в руках свою трудовую книгу! На прощание мне выдали презент и сказали, что компания хорошо относится к тем сотрудникам, которые сами ушли из нее. Поэтому будут ждать меня, если я передумаю и решу вернуться. Но как покажет история - больше наши пути не пересекутся.

#my_little_story - по этому хэштегу можно прочитать мой путь с самого начала