#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 - по этому хэштегу можно прочитать мой путь с самого начала

Баланс в принятии решений программиста

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

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

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

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

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

Как и какие написать тесты?

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

Для этого нужно просто ответить на два вопроса:
1. Какие возможные тест кейсы могут произойти с этим кодом (начиная естественно с наиболее вероятностных)
2. Как бы я вручную проверял этот код?

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

Ответ на второй вопрос показывает, как должна выглядеть секция then (given/when/then) - т.е. наши asserts на результат выполнения кода. Здесь не стоит лентяйничать и проверять только часть. Например, если я пишу тест, проверяющий http endpoint, который возвращает картинку - мне недостаточно проверить, что http status равен 200. Это как проверка возвращаемого значения из обычного метода на not null. Нужно проверить и http body, что там действительно нужная картинка, и основные http headers, такие как Content-Type, Content-Lengh и т.д.

Более подробно про написание тестов и best practices я показываю в бесплатном практическом видео по JUnit 5.
Полный курс JUnit 5 можно приобрести на платформе GetCourse за 999 rub или YouTube по Senior подписке за 9.99$

#12 Мой путь

4 октября 2012 года - мой первый день на новом месте работы в компании IBA, в которой я проработаю следующие 3.5 года.

Здесь уже выдали и комп мощный, на котором действительно все летает, а не как в лаборатории я ждал минутами, пока просто рестартанет приложение. И место в небольшой комнате на 6 человек, а не open space на 50. Но самое главное - я увидел и начал прощупывать своими руками исходный код реального проекта, после которого все мои предыдущие казались просто детскими забавами. Настолько была колоссальная разница между ними. Именно на нем я провел первые 2 недели, обучаясь технологиям и фреймворками, принятым в этой компании и команде, прежде чем меня назначили на совершенно другой и новый проект с кодовым названием ЕГБДП.

С начальством я договорился, что буду работать по 35 часов в неделю, ибо чисто физически не смогу успевать на полный рабочий день из-за учебы. А учился я на 4 курсе тогда в “среднюю” и самую неудобную смену, когда пары начинались в середине дня. Поэтому я вставал рано утром и шел на работу, прихватив с собой йогурт и булочку на завтрак. Потом уходил на пары, естественно пропуская часть лекций, которые по моему мнению были не важны. Тогда-то и начался спад моей успеваемости и первые 4 балла по экзаменам (по 10-балльной системе).

Но это тогда для меня уже не имело значения - я целиком и полностью был в работе. После пар ближе к 6 часам я возвращался в офис и работал до 9-10 вечера. Тут мне опять повезло, потому что офис-общежитие-универ были близко расположены. За 20-30 минут я мог добраться из одной точки в другую, а из второй - в третью.

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

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

Тогда же мне сделали первое повышение на 200$, и я был полон энтузиазма еще больше вкладываться в работу. Эх, как мало мне тогда было надо, чтобы поднять мотивацию, и как сложно этого добиться сейчас 🙂
Так пролетел целый год и закончился 4 курс в универе.

#my_little_story

Plugin Management in Apache Maven

В Apache Maven в POM файлах реализован механизм наследования по очень похожему принципу, что и наследование классов в Java. Наследуется тоже почти все.
Поэтому очень легко запомнить, проассоциировав это с Java, а класс Object - с Super POM.

Секция pluginManagement не исключение. Более того, она специально создана, чтобы не дублировать версии и настройки плагинов в дереве POM файлов многомодульного проекта, как это мы не хотим делать с зависимостями, используя секцию dependencyManagement.

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

1️⃣ Достаточно сконфигурировать плагин лишь один раз в pluginManagement секции рутовой POM, в остальных модулях - просто переиспользовать, указав плагин в секции plugins

2️⃣ Стандартные плагины, такие как maven-compiler-plugin, maven-deploy-plugin, и другие участвующие в жизненном цикле проекта - и так будут использоваться по умолчанию, ибо они наследуются из SUPER POM. Поэтому не надо их описывать в каждом модуле.

3️⃣ Эти же стандартные плагины могут находиться в pluginManagement секции рутовой POM, чтобы, например, переопределять их версию на более актуальную. Как мы можем переопределять методы при наследовании в Java.

4️⃣ properties тоже наследуются, как и dependencies, plugins, etc (полный список). Поэтому достаточно определить их лишь раз в рутовой POM и далее просто переиспользовать в любых других модулях.

Еще больше про Apache Maven можно узнать на моем курсе

IntelliJ IDEA зависимость

Довольно часто в dmdev чатах и на менторстве вижу вопросы подобного рода:
- IDEA не видит application.properties файл в коде. Что я делаю не так? Мне этот файл нужно не в директории resources держать?
- IDEA не подсказывает модель в jsp/html файлах, хотя все работает, когда запускаю приложение. Как так?
- IDEA пишет, что не вызван callSuper в Lombok аннотации @ToString, хотя я указал это. Почему?
- Я создал файл .gitignore, но когда пытаюсь сделать commit - IDEA все равно не игнорирует директорию build. Почему?

Когда я начинал программировать (а это было почти 15 лет назад), таких вопросов в принципе не возникало у программистов, потому что тогда не было настолько мощных сред разработки. А значит и не было такой сильной зависимости от их функционала, их подсказок и т.д. Если что-то не работало - то ты начинал думать логически и шел искать настоящую проблему в коде, а не задавался вопросом “почему IDEA не…”.

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

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

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

Вопрос 👆 - Ответ 👇

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

1️⃣ Вне зависимости от уровня разработчика, есть всегда человек или даже несколько, кто помогает в твоем онбординге, например, team lead или ключевой специалист на проекте. Они рассказывают про проект в целом, бизнес логику его, краткосрочные/долгосрочные планы проекта, про команду, процессы внутри этой команды и компании. Этот период, а точнее его активная фаза (потому что вопросы с твоей стороны будут и далее), занимает +- 1 месяц.

2️⃣ В отличие от изучения Java или фреймворков как Spring (то, что я описал в своем roadmap), для онбординга я использую обратный подход - от общего к частному. Другими словами говоря, начинаю читать design docs, чтобы представлять себе в голове общую схему и смотрю на все это с высоты птичьего полета. Design docs всегда пишут в хороших компаниях, прежде чем приступить к разработке ПО. Если их нет - то увеличивается первая фаза онбординга, где тебе будет уже кто-то расписывать такие диаграммы и рассказывать про архитектуру приложения.

3️⃣ Приступаю к тому, чтобы установить все необходимое ПО на комп, скачать исходники и собрать проект. После чего можно детальнее разобраться в коде, фреймворках и технологиях в ключевых сервисах и тех, что будут входить в твою зону ответственности. Эта фаза может проходить в параллели с первыми двумя, если позволяет время и уже имеется весь необходимый доступ (обычно его сразу нет и выдается постепенно).

4️⃣ Беру из backlog НЕ приоритетные задачи. Обычно это баги или мелкие улучшения, чтобы не блокировать команду. Ибо процент того, что пойдет что-то не так у новенького на проекте гораздо выше (и времени на их реализацию уходит больше). Эти небольшие задачи уже помогают на практике закрепить все то, что я получил в теории из предыдущих пунктов. Только так можно разобраться в проекте и технологиях, что ты встречаешь впервые.

#dmdev_qa