#ВашВопрос
👇
Где лучше выбрасывать исключения? На уровне сервисов там где и основная бизнес логика или на уровне контроллеров?

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

1. Начнем с самого простого: ошибки базы данных нет смысла обрабатывать на уровне dao/repository, потому что в таком случае клиент даже не узнает, произошло успешное выполнение запроса и состояние сохранилось в базе или нет.

2. Пункт 1 ведет к тому, что ошибки обрабатываются на уровнях выше: service, controller, http filters, kafka consumers, etc. Поэтому вопрос становится следующий:

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

Если ответ да - обрабатываем и продолжаем выполнять код программы. В противном случае пробрасываем ошибку выше и прерываем выполнение.

3. Если на пункте 2 мы и так находимся на последнем уровене, то нам придется принять решение о том, как обработать ошибку и какой вернуть ответ клиенту/пользователю.

Design Docs - очень мощное оружие!

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

Когда я получал какую-то задачу от своего team lead, я просто сразу принимался за написание кода. Конечно, уровень тех задач были далек от тех, что потом придется выполнять мне в будущем. Тем не менее, если я допускал где-нибудь ошибку, например, в схеме базы данных - то мне приходилось править в очень многих местах вверх по всей цепочке, начиная от sql скрипта и заканчивая сущностями, композиции классов, логики и тестов. Что занимало уйму времени.

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

Архитектурные ошибки обычно заметны не сразу, а с течением времени. Именно поэтому это так неприятно.

Чем на более ранней стадии получится найти ошибку при разработке ПО, тем дешевле обойдется ее решение

И самое эффективное средство здесь - это написание design docs. Т.е. в них мы можем быстро обсудить с другими программистами и решить проблемы еще до того, как была написана даже строчка кода. А значит, само решение занимает считанные часы или даже минуты: надо лишь подправить текст или перерисовать парочку диаграмм.

Так в моей работе сейчас ни одно сложное решение не обходится без написание design doc. Даже если проблема не столь велика, но имеет несколько возможных вариантов решений, из которых тебе не понятно как выбрать и хочется обсудить - то достаточно 1-2 страничного design doc, который мы еще называем 1-pager или 2-pager соотвественно.

#23 Мой путь

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

В то время на слуху у всех в Минске был сравнительно молодой район под названием “Новая Боровая”. Я сел за руль своего Polo и поехал на разведку. К моему удивлению, еще сидя в машине и подъезжая к “Новой Боровой”, я уже обратил внимание, что этот район сильно отличается от всех других: повсюду велосипедные дорожки, дома необычно окрашены, огромный рисунок Леонардо Да Винчи на всю стену, весь район разбит на закрытые небольшие кварталы по 5-6 домов в каждом, внутри которых был двор с беседками, барбекю, площадками для детей и спорта.

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

Когда подошел мой черед, и я начал беседовать с консультантом - пришло довольно досадное понимание. Во-первых, те квартиры, что мне понравились, еще в процессе строительства, которое займет около года. А значит нужно будет ждать их сдачи и продолжать платить за арендное жилье по 350$. Во-вторых, нужны будут деньги на ремонт, т.к. это будет новая пустая квартира без ничего вообще. В-третьих, мне придется отдать все деньги, что я скопил на тот момент. И в-четвертых, следующие 9 месяцев придется платить за ипотеку по 4000$ каждый месяц. На тот момент - это была моя зарплата в компании Synesis. Другими словами говоря, жить я буду только за счет курсов, что я преподавал в it-academy.

Это было довольно рискованным делом, но мое желание было слишком велико. Я сам по себе человек, который обычно быстро принимает решения. Помню, как моя будущая жена, с которой я еще не был знаком на тот момент, всегда удивлялась, как я, например, могу зайти в первый понравившийся магазин за шапкой и купить ее за 5 минут. А я просто не люблю все затягивать и долго размышлять над потенциально другими вариантами, которые могут мне понравится или могут быть лучше. Поэтому в этот раз тоже было не исключение - я согласился прямо в тот же день: выбрал квартал, дом, двухкомнатную квартиру в 59 квадратов на 2 этаже, и косметический ремонт. За все вышло чуть больше 83.000$.

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

#my_little_story

#ВашВопрос
👇
Денис, привет, спасибо большое за все что ты делаешь, развиваюсь благодаря твоим курсам очень сильно. Хотел спросить, как думаешь, через какое время нужно менять проект. Я уже два года на одном проекте, он развивается, все хорошо. Но может нужно какую то насмотренность тоже набирать или это ерунда?

Здесь нет однозначного ответа, когда стоит менять проект или компанию. Но как показывает статистика - это в среднем около 3 лет.

Я бы лучше акцентировал внимание на цели, которые ты приследуешь:

🎯 Если цель - это получить больше зарплату, то да, ты быстрее можешь повысить ее при смене компании (до какого-то порога на рынке или порога твоих профессиональных навыков).

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

🎯Если хочешь развивать свои навыки и не стоять на месте, то тут лучше прислушиваться к себе и чувству комфорта.

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

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

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

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

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

PS. В моем случае, я нахожусь на одном проекте уже 2.5 года.

☝️Полный комплект из 13 курсов, которые будут участвовать в праздничной распродаже 18 марта

P.S. Среди участников будет разыграно одно место на менторство DMdev 1 ступени и две часовых консультации со мной

#ВашВопрос
👇
Подробный гайд или road map для senior java developer. Вот прям подробный, и который позволит не только пройти собеседование, но и выполнять задачи. К примеру знание Jackson библиотеки, sdkman, liquibase. Либо описание конкретных задач, разбитые на под шаги.

Тут хотелось бы подчеркнуть, что когда речь идет о позиции Senior Developer и про собеседования для него, то вопросы подобного рода про знание библиотек и фреймворков отходят далеко на задний план, потому что ты уже прошел огромный путь через огромное количество таких инструментов. И чтобы разобраться в чем-то новом, тебе не составляет большого труда.

Senior Developer решает вопросы другого рода:

- как представить задачу бизнеса в виде технической дизайн доки

- как дизайн доку декомпозировать на подзадачи, и по возможности делегировать их другим разработчикам

- предоставить оценки по времени реализации задач или всего проекта в целом (это самый ходовой вопрос у бизнеса, ибо их не интересуют твои фреймворки)

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

- сделать так, чтобы траблшутинг был простым, т.е. весь проект должен быть покрыт оптимально достаточным количеством метрик и логов

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

- брать на себя самые сложные/интересные задачи и реализовать их просто

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

Как можно заметить, довольно сложно провести собеседование на позицию Senior Developer и убедиться, что кандидат вам подходит.

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

Суммируя все вышесказанное, на собеседовании есть смысл:

- спрашивать об опыте на других проектах и чем занимался/что реализовавыл/с какими проблемами сталкивался

- попросить представить схематично как бы спроектировал бизнес задачу, и какие проблемные/узкие места видит здесь

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

- попросить написать не тривиальный sql запрос и увидеть, что кандидат работал тесно с данными, анализировал их, занимался траблшутингом

#ВашВопрос
👇
Как относишься к гексагональной архитектуре организации кода? Слой сервисов работает исключительно с классами-доменами, что усложняет работу с БД, из-за закрытия сессии на уровне портов.

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

Сама идея вокруг гексагональной архитектуры очевидна и понятна: мы хотим разъединить/отвязать части целого приложения, чтобы иметь возможность разрабатывать и менять эти части независимо друг от друга. И эти идеи не новы, они есть и в других архитектурах, например, той же классической n-tier архитектуре, о которой я рассказываю на протяжении многих моих курсов.

Например, на своем проекте я по достоинству оценил лишь отделение интерфейса взаимодействия с приложением, где я пишу код абстрагируясь от протоколов - будь то это HTTP, gRPC, Stubby, и т.д. Все это на себя берут "адаптеры".

Когда же дело доходит до "downstream" зависимостей, которые будут использоваться в бизнес логике (например, базы данных, message brokers), то почти всегда приходится спускаться до нюансов работы инструмента, чтобы работало именно так, как надо, а не так, как получится.

Что касается вопроса - я не вижу большого смысла в усложнении работы с базами данных, потому что:

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

- идея про возможность заменить СУБД на лету только звучит круто, на практике никто этого делать не будет за редким исключением (что только подтвреждает правило).
Данные - это самое важное в приложении, на основании чего потом и рассчитывается перфоманс приложения, и аналитика будет строиться, и LLM обучаться, и т.д.

- нет нормальной возможности управлять транзакциями, и тем более сам механизм транзакций очень сильно отличается в реляционных и нереляционных хранилищах, что уже делают невозможным делать замену базы "на лету". А некоторые СУБД вообще строятся на основании бизнес логики, потому что не так просто в последующем считать эти данные

У нас в команде есть очень хорошая практика - оставлять коментарии к своим же пул реквестам.

Обычно это относится к тем вещам, в которых ты не уверен, есть сомнения/несколько альтернативных вариантов, и хочешь уточнить у других.

Это также очень сильно улучшает концентрацию вниманию тех, кто будет ревьювать твой пул реквест.

Обычно у ревьюверов фокус размазан по всем измененным классам и файлам. А здесь же он будет направлен именно сюда, в место твоего комментария!

Что думаете по поводу этого?)
Может кто-то также использует?

🥳 Тот самый день: мне 33 года и старт праздничной распродажи DMdev

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

«Do what you love. Love what you do»

Мне нравится делать то, что я делаю. Я чувствую свое признание в программировании.

И в честь своего 33-летия я сделал для вас подарок: только сегодня, 18 марта все мои 13 курсов по Java за 33% от полной стоимости!

А это:
- 661 лекция
- 115 часов видео
за 4.999 rub с доступом на 1 год [по желанию есть опция добавить бессрочный доступ]

Каждый в подарок получит приглашение на участие в первом закрытом вебинаре «Микросервисы», который состоится 4 мая 🎁

Но и это еще не все: также среди участников будет разыграно одно место на менторство DMdev и две личных консультации со мной по вашему запросу.

Время не стоит на месте, переходи по ссылке, пока все подарки не превратились в тыкву 🎃

❗️P.S. При оформлении заказа обязательно нужно указать верную действительную почту, так как именно на нее придет ссылка с доступом❗️

Последний шанс!
Всего один час до завершения праздничной распродажи – не упустите возможность!
Забираю 🤚

#ВашВопрос
👇
Что думаешь насчёт JOOQ?

Впервые я с ним столкнулся в 2019 году, когда работал в компании Synesis. И выбор был сделан в пользу него по одной простой причине: ребята избегали сложностей Hibernate.

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

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

Я ничего не имею против JOOQ, Jdbi и так далее. Они действительно просты в использовании, но кода мне приходилось писать с ними значительно больше, чем с Hibernate.

🏆 Победители розыгрыша праздничной распродажи:
1. Антон Соловьев - менторство DMdev 1 ступени
2. Вадим Кузьмич - часовая консультация со мной
3. Мария - часовая консультация со мной

P.S. всем написал смс на GetCourse, ловите письмо и жду ваш ответ!
Поздравляю 🥳

И еще небольшой спойлер для всех остальных - уже сел писать вебинар «Микросервисы», на основании которого решил создать в дальнейшем полноценный практический курс по микросервисам 😱🤩😍

#ВашВопрос
👇
Какие лучшие практики для получается коллекций сущностей со связанными коллекциями с пагинацией? Например у Поста есть Комментарии и Лайки, и нам нужно достать определенные посты с лайками и комментами, 1 страницу. В туториалах пишут обычно как бороться с n + 1, но это порождает другую проблему - пагинацию в памяти. Есть варианты - @BatchSize (по мне, так себе), либо найти айдишки постов первым запросом, следующими - выгрузить эти сущности, чтобы хибер их смаппил в памяти, либо уже сделать джоин фетч запрос. Как правильнее?

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

Первый - это сам запрос с пагинацией, который достанет id сущностей, которые нужно вернуть пользователю на текущей странице.
Второй - запрос на получение полностью всех полей сущностей WHERE id IN (результат первого запроса) вместе с комментариями, т.е. будет делаться LEFT JOIN.

Такой подход работает очень быстро даже на очень больших объемах данных. А главное - он также и прост в реализации.

Также хочу напомнить про два варианта пагинации, о которых я рассказывал на своем курсе Spring: offset-based and keyset-based. И что нужно склоняться в сторону keyset-based, который является предпочтительнее, ибо гораздо эффективнее на больших объемах данных.

Но как и любое решение, keyset-based кроме своих очевидных достоинств имеет и некоторые недостатки - он чуть сложнее в понимании и реализации, нежели привычный offset-based.

Вебинар "Микросервисы" уже через 12 дней!

Всем участникам праздничной распродажи DMDev в качестве подарка я обещал пригласить на свой первый закрытый вебинар "Микросервисы", который состоится 4 мая в 11:00 МСК.

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

Я подготовил 60+ слайдов с топовой информацией, нарисовал полсотни схем и диаграмм и готов поделиться этим с вами!

P.S. Ссылку на подключение пришлю за два дня до начала, а также в день самого вебинара.

P.S.S. Кто не сможет присоединиться, запись вебинара будет доступна через некоторая время на платформе GetCourse.

P.S.S. Кто не участвовал в акции, тот сможет отдельно приобрести запись вебинара на платформе GetCourse.

Уже завтра закрытый Вебинар "Микросервисы"!

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

Мы затронем (и постараемся как следует разобрать) такие темы как:

- Вертикальное и горизонтальное масштабирование
- Load balancers
- Service registry & service discovery
- Аутентификация & авторизация
- Logging & Metrics
- Проблемы "монолитов"
- Работа с базами данных в микросервисах
- Механизмы общения между сервисами (sync & async)
- Самые распространенные паттерны микросервисов и зачем они нужны (Transactional outbox, Strangler application, API Gateway, Distributed tracing, Saga, etc)
- и многое другое
Вебинар будет очень насыщенным, так что запаситесь чаем и печеньками, чтобы обсорбировать столько полезной, а главное нужной и актуальной информации!

P.S. Вчера всем участникам должны были прийти приглашения на email, который указывался при покупке курсов на GetCourse во время праздничной распродажи. Сегодня придет еще одно.

P.P.S. Если кто-то еще желает принять участие в вебинаре завтра или посмотреть в записи, то его можно приобрести по ссылке с доступом на 6 месяцев.