👀 О чем этот канал и кто находится по ту сторону экрана?

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

Начать знакомство с Java и DMdev можно с бесплатного курса на YouTube💻

Кто я такой и почему мне можно доверять?

Меня зовут Денис Матвеенко - и в первую очередь я не блогер, не предприниматель, а Software Engineer в Google. (именно поэтому, да простите меня подписчики, контент здесь не по расписанию, а по вдохновению и свободному времени😅)

Еще пару фактов обо мне:
- 10+ лет практического опыта в качестве Java разработчика
- работал в 7 различных компаниях: как аутсорсинговых, так и продуктовых
- 5+ лет преподаю Java: для начинающих и не только

#my_little_story - по этому хештегу рассказываю подробно свою историю с момента зарождения мысли "хочу стать программистом"

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

Моя суперспособность: умею декомпозировать и структурировать информацию + объяснять сложное человеческим языком

Моя слабость: у меня не очень хорошая память (а информации в программировании много), поэтому я предпочитаю ПОНИМАТЬ, а не ЗАПОМИНАТЬ

🗝 Секрет моего карьерного роста: любовь к программированию и ничего более

👉 Кстати, в этом посте поделился, как росла моя зп с самого начала карьеры

И еще несколько интересных постов для тебя:

1️⃣ Почему я предпочитаю инженерный подход в программировании?

2️⃣ Cдвиги парадигм, которые происходят у изучающих Java

3️⃣ Почему логирование ошибки и сразу ее пробрасывание дальше - является антипаттерном?

4️⃣ Best practices in code review

#dmdev_code_review - ищем ошибки в коде и разбираемся, как их исправить
#dmdev_qa - отвечаю на ваши вопросы

Задать анонимный вопрос можно тут:
https://forms.gle/FLHEHQ7GcSNjmtku5

В качестве подарка - забирай дорожную карту джависта - Java Roadmap с нуля до Senior🎁

Часто мне задают вопросы такого плана - когда не понятно как реализовать или упростить уже существующий функционал.

Как раз реальная задача, которая требует действительно гибкого решения, ибо время показало, что этот код меняется часто, а значит требует рефакторинга.

Как можно было бы изменить код, чтобы автоматически при добавлении нового обработчика для определенного типа - не требовалось менять основную логику с добавлением еще одного if-else?

Можно словами в комментариях, можно прям скринами с кодом.

Если наберем несколько интересных вариантов, то я напишу свои мысли по этому поводу 😎
#dmdev_qa

Общими усилиями в комментариях мы пришли к гибкому решению!
Его я отобразил на картинке.

Единственное что я изменил - это тип процесса, сделав его Class<T> вместо enum для демонстрации альтернативного подхода.
В этом есть свои плюсы и минусы, как и в любом решении.

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

Минусы:
- без enum не виден весь список возможных процессов
- не напишешь хороший тест, что на каждый процесс есть свой обработчик
- пришлось в ProcessService сделать явное приведение типов, потому что метод getClass в классе Object возвращает Class<?>

Что бы ты выбрал все-таки: enum vs Class<T>?
#dmdev_qa

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

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

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

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

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

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

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

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

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

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

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

#dmdev_qa

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

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

Давайте разбираться…

Что самое важное в любом приложении? Конечно же это логика его работы.

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

Теперь самое интересное: математика целиком и полностью построена на логике. Это как следующий уровень после логики. Математика развивает мышление, учит анализировать и систематизировать знания, учит мыслить абстрактно и конечно же ЛОГИЧЕСКИ!

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

Надо понять одну простую истину:

знание не бывает в вакууме, оно обязательно цепляет другие сферы, которые жизненно необходимы для усвоения этого нового знания

И в случае программирования - это в первую очередь логика.

❓Поэтому, отвечая на вопрос нужно ли знать программисту математику?
Ответ нет. Программирование не строится на ней.

❓Хорошо бы знать программисту математику?
Ответ да. Ибо транзитивно математика прокачает ключевые навыки для программиста.

#dmdev_qa