Личная победа #2 🏆

Ровно год прошел, как я пробежал свои первые 10.000 метров. Сегодня я покорил эту дистанцию во второй раз.

Все те же тезисы, что и год назад я написал, до сих пор очень актуальны. Хотел бы только чуть подкорректировать некоторые из них:

1️⃣ Если за 2 месяца постоянного труда можно добиться хороших результатов в чем-либо, то за год эти результаты будут просто колоссальны.

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

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

И немного статистики, чего мне стоило улучшение результата за год с 53:01 до 40:34
👇
2031.2 км (в среднем 39.1 км в неделю) или
197:23:53 времени (в среднем 3:47:46 в неделю)

#13 Мой путь

Вот и настал заключительный 5-ый курс университета. Я учился на бюджете, поэтому нужно было либо подписывать договор со своей компанией IBA на 2 года распределения после учебы, либо выбирать компании из предложенного факультетом списка, который мягко говоря был не очень. Ограничивать себя и связывать на столько времени с одной компанией конечно не хотелось мне, но другого варианта не было. Более того, текущий проект на работе разрастался, и меня попросили найти трех толковых ребят к себе в помощь. Другими словами говоря, я стану лидом, что меня очень воодушевляло, т.к. позволяло прокачаться в отличном от написания кода направлении.

Так собственно и произошло - я подписал договор на 2 года о распределении с компанией IBA (кстати, мне почему-то как раз в это время опять повысили зарплату… совпадение?), и привел на собеседование троих ребят, двое из которых были на том же потоке моего факультета. Все трое успешно прошли собеседование, после чего мы вместе стали работать над одним проектом.

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

Экзаменов было меньше в этом семестре, и сдавали мы их на несколько недель раньше - в декабре 2013 года, чтобы поскорее начать писать дипломный проект. В качестве его темы я решил выбрать “Автоматизированная система управления ресторанами”. Времени было достаточно и для работы, и для написания дипломного проекта, потому что на заключительном семестре как таковых пар и нет. Нужно просто время от времени показывать проделанную работу и посещать преподавателей по охране труда, экономике и т.д., потому что твой дипломный проект должен быть “экономически обоснованным” и соблюдать “охрану труда”. Хотя по факту, я больше времени потратил не на написание кода приложения, а на форматирование уже готового дипломного проекта, ибо невероятно тяжело соблюдать все ГОСТы, на которые больше всего и обращали внимание преподаватели (кто захочет ревьювить код сотен студентов?).

Потом еще выяснилось, что большинство пятикурсников выгоняют из общежитий в связи с проведением чемпионата мира по хоккею в Минске в мае 2014 года. Спрос на квартиры в то время был невероятен. Каждое утро я просыпался и первым делом шел смотреть на сайты арендного жилья, ибо времени оставалось совсем немного, а любые варианты уходили как горячие пирожки. По какой-то случайности я смог найти себе комнату в трехкомнатной убитой квартире недалеко от офиса за 250$, чему еще и был невероятно рад! Как сейчас помню выражение своей мамы, которая как-то раз приехала в гости и увидела то, где я живу. Еще и наглый рыжий кот вместе с его хозяином, которые оба тырили приготовленную мной еду.

Как хорошо, что долго я в этой квартире не задержался, а в общежитиях я больше не жил…

#my_little_story

Проблемы с перформансом приложения

Когда речь заходит о производительности приложения и поиск проблемных по перформансу мест, то любые приложения можно разбить на два основных аспекта:
- CPU, т.е. алгоритм и логика работы
- IO, т.е. операции ввода-вывода, к которым можно отнести запросы к СУБД, работу с файлами, общение с другими сервисами по различным протоколам (HTTP, gRPC, Thrift, etc)

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

Более того, мы пытаемся максимально оптимизировать код и думаем об ошибках перформанса ВО ВРЕМЯ разработки - тоже в CPU. Хотя подавляющее большинство backend приложений на Java не содержат очень сложной логики, а более 90% проблем связаны именно с операциями IO.

Поэтому, как я писал в посте “Баланс в принятии решений программиста” - нужно сконцентрировать свое внимание на оптимизации кода в более вероятностных местах, например, таких как:

1️⃣ Работа с СУБД, а особенно наши sql запросы, где понадобится не только хорошо знать как грамотно их писать, но и как оптимизировать их в случае возникновения проблем, анализируя планы выполнения (ибо не надо стараться оптимизировать каждый запрос и тратить на это кучу времени). Также обращать внимание на более правильную работу с ORM фреймворками, которые непосредственно связаны с СУБД, а значит могут негативно сказаться на перформансе.

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

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

А с какими ты ошибками перфоманса сталкивался на своих проектах?

Для получения весомого результата нужно время

В беге - невозможно взять и моментально улучшить темп с 4:00 до 3:40 мин/км за пару тренировок. Все потому, что нужны изменения на клеточном уровне в организме человека. Чтобы образовались новые волокна в мышцах, укрепились связки и сухожилия, появились новые митохондрии и прокачалась сердечно-сосудистая система.

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

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

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

Так что нужно запастись терпением и добавить немного постоянства - тогда результат точно придет!

У меня все выветривается из головы

В Java есть большая и очень важная тема - IO (Input and Output streams). Input stream - это считывание, получение данных В приложение. Output stream - наоборот, передача данных ИЗ приложения. После получения данных (Input) - мы обязательно должны обработать их в программе. Например:
- сохранить в базу данных
- передать в другое приложение
- вернуть пользователю ответ на его http запрос
- преобразовать в другой тип данных и записать в файл

А все это уже самый настоящий Output. Т.е. и Input, и Output streams очень взаимосвязаны друг с другом. В противном случае - все данные исчезнут.

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

Поэтому если мы все-таки намерены усвоить какой-то материал - нужно ОСТАНАВЛИВАТЬСЯ и ОСМЫСЛИВАТЬ его, как это мы бы делали в приложении. Другими словами говоря, подключать Output stream.

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

Мой Output Stream

В продолжении к предыдущему посту...

...оглядываясь назад я могу вспомнить два очень важных момента, которые невероятно сильно повлияли на мои навыки в программировании (и не только в нем конечно же, ибо все взаимосвязано). Это как два огромных “спайка” на графике моего прогресса:

Первое - это когда я начал преподавать в it-academy.
Второе - это когда я начал создавать видео на YouTube.

Оба варианта - это самый настоящий Output stream. Причем крупнокалиберный, действеннее способа которого вряд ли можно придумать.

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

А вообще, чем больше СЕНСОРНЫХ, МОТОРНЫХ и УМСТВЕННЫХ трудов уходит на какое-то действие - тем сильнее закрепляется результат. Но это уже отдельная тема для следующего поста)

#14 Мой путь

Июнь 2014 - защита дипломного проекта, которая заняла буквально 5 минут. Так обычно и происходит в жизни, когда мы к чему-то очень долго и кропотливо готовимся, волнуемся, а это все оказывается мимолетным и заканчивается невероятно быстро. После чего возникают одни и те же мысли: и стоило ради этого так переживать! 30 июня было назначено вручение дипломов, но к этому времени нужно было успеть пройти обходной лист, без которого собственно диплом ты не получишь.

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

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

Служба в резерве предполагала сборы на 1-2 месяца 3 раза в течение 2-х лет, что в общей сложности получалось 4.5 месяца армии вместо 1 года, который полагался для всех ребят с высшим образованием. Естественно я выбрал резервную службу, потому что такой проект не вечен, где я бы смог получать отсрочки до 27 лет. А отслужить в армии не увольняясь из компании, да и еще во время обязательного двухлетнего распределения - звучало очень здорово. Осталось только ждать осени, ибо пока этот вопрос был решен.

Тем временем уже наступило 30 июня. Декан факультета торжественно вручил всем выпускникам дипломы, после чего мы своей группой оккупировали аудиторию в 4 корпусе БГУИР, чтобы тихонечко отпраздновать и выпить шампанское. Почему-то очень хорошо запомнился этот момент.

Далее последовал выпускной… и все, 5 лет прошло, и теперь спокойно можно выдохнуть. Начинается новый этап в жизни, который я также отметил переездом в новую двухкомнатную съемную квартиру, воспользовавшись моментом небольшого летнего спада спроса на них (чемпионат по хоккею закончился, да и студенты разъехались). Только в этот раз действительно достойную, с хорошим ремонтом, кухней и мебелью за 550$ в месяц, а не подобие сталинской коммуналки из 5 человек и рыжего кота. Правда, оплачивать одному всю стоимость было пока еще довольно накладно по бюджету, поэтому жил я с другом, вдвоем.

#my_little_story

Почему конспекты не работают

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

Как я уже писал в предыдущем посте, для закрепления информации нужно подключать как можно больше СЕНСОРНЫХ, МОТОРНЫХ и УМСТВЕННЫХ трудов.
Начнем по порядку.

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

Моторика - это произвольные движения нашего тела, для которых необходимо использовать сразу несколько систем: нервную, костную и мышечную. В нашем примере с конспектами - используются ТОЧНЫЕ движения ручкой. Эта уже даже мелкая моторика, которая подключает отделы нашего головного мозга еще эффективнее (потому так полезна для детей).

Это наш природный Output Stream. И как можно догадаться, он разительно менее эффективен, чем InputStream: все-таки получать информацию мы научились в гораздо больших объемах, нежели выводить ее из себя.

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

И именно этой третьей части мне всегда не хватало на лекциях, когда я писал конспекты. Потому что времени на осмысливание информации попросту не было. Я пытался законспектировать услышанное и все. Т.е. преобразовывал Input Stream полученный из слуховой системы (СЕНСОРИКА) - напрямую в записи в тетради (МОТОРИКА) с минимально обработкой, чтобы этого было достаточно для конспектирования.

Именно по этой причине мне никогда не нравились занятия в группах и посещения лекций в универе, я всегда любил заниматься самостоятельно. Для этого я могу использовать, например, видео уроки - их всегда можно пересмотреть с нужного тебе момента, если ты не успел ОСМЫСЛИТЬ услышанное.

Поэтому если правильно использовать это оружие конспекты - то можно получить неплохую пользу 🙂

Мое наблюдение о преподавании Java онлайн и оффлайн

В январе 2018 года, когда я только начал преподавать - я очень тщательно готовился перед каждой лекцией, чтобы понятно и доходчиво объяснить тему. А главное - ничего важного не упустить.
Конечно же я использовал для этого конспекты: память человека всегда может подвести, а вот то, что записал на листок (а значит сохранил на внешний носитель) - нет. И мне такой подход действительно очень нравился поначалу.

Как-то раз, уже во второй половине курса, одна беременная ученица не смогла прийти на мои лекции в виду того, что родился малыш. И попросила методистов it-academy записывать видео.

💭 Я еще тогда подумал: “хм, прикольно, можно же записывать лекции, чтобы даже в таких ситуациях можно было ничего не пропустить и пересмотреть”. Но на этом мысль и закончилась и никуда дальше не продвинулась.

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

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

Следующие группы с первой же лекции начинали снимать меня и выкладывать видео на YouTube. Более того, все записанные видео бывало пересматривал и я, т.к. было познавательно смотреть на себя со стороны и подмечать моменты, которые мог исправить или улучшить в будущем. Это как взгляд со стороны, обратная связь самому себе. Более того, я мог поделиться ссылкой на записанный playlist с теми, кто самостоятельно изучал Java.

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

🎥 В принципе, тогда, 30 мая 2020 года, и зародился канал dmdev на YouTube и его самое первое видео.

Из очевидных плюсов записанных видео:
- возможность смотреть видео в удобнее тебе время. Не надо ехать куда-то сразу после работы, экономя время на логистику
- возможность останавливать, проматывать, пересматривать видео сколько угодно раз, чтобы ОСМЫСЛИТЬ информацию
- лектор запишет точно все, что хотел сказать, и ничего не забудет

Из минусов:
- нет возможности задать уточняющие вопросы лектору сразу по ходу видео
- нет обратной связи

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

Присоединиться на менторство DMdev, оставив заявку по ссылке:
👉Первая ступень менторства
👉Вторая ступень менторства

Старт: конец января 2024г.
P.S. Количество мест ограничено, группы по 10-12 человек.

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

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

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

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

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

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

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

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

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

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

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

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

#dmdev_qa

🎄 Как насчет ежедневных best practices вплоть до Нового Года?

С завтрашнего дня в рубрике "DMDEV ADVENT CALENDAR"

Новый день = новая возможность сделать твой код чуточку лучше!
Включай уведомления и зови друзей!

Не будь излишне терпим к null

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

Например, когда сравниваешь объекты

object.equals(CONSTANT)

- тебе необходимо учитывать, что object может быть null.

Yoda notation

CONSTANT.equals(object)

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

Поэтому:
- если ты НЕ ожидаешь, что object может быть null, object.equals(CONSTANT) - это отличный вариант написания.

- если ты ожидаешь, что object может быть null, то лучше использовать Objects.equals(object, CONSTANT) - это сделает код более чистым и понятным. Более того, он говорит, что object может принимать null значения.

- для параметров метода, которые не должны быть null, вообще лучше использовать fail-fast принцип Objects.requireNonNull (обычно генерируется автоматически с помощью тех же аннотаций Lombok)

#dmdev_best_practices

Используй @Nullable в своем коде

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

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

consistency превыше всего!

В противном случае, другие программисты будут считать, что если что-то не аннотировано @Nullable - то оно не может быть null.

Подытожим:
- используй @Nullable везде, если это возможно
- если не можешь поддерживать consistency во всем коде - то лучше избегай @Nullable (или везде, или нигде!)
- если используешь @Nullable, то смысла в @NotNull аннотации нет - ибо все и так по умолчанию будет восприниматься not null

#dmdev_best_practices

Предпочитай кастомные аннотации, нежели использование @Named

Аннотации @Named и @Qualifier (Spring annotation) - очень мощный инструмент, позволяющий определять и использовать несколько бинов одного и того же типа. Вообще, спецификация JSR 330 Dependency Inject предоставляет два варианта: использование стандартных аннотаций вроде @Named, либо создавать свои кастомные. И именно второй вариант должен быть предпочтительным.

Основной недостаток стандартных аннотаций - это использование строкового значения в качестве идентификатора бина @Qualifier("primaryHttpClient")

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

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

@Documented
@Retention(RUNTIME)
@Qualifier
@interface PrimaryHttpClient {}

#dmdev_best_practices

Когда использовать Stream API

Императивный цикл for конечно же намного мощнее, чем обычная цепочка вызовов в Stream API.

Ты можешь:
- вернуться из цикла любой вложенности в любой момент времени
- изменять данные как угодно и где угодно (а не только affectively final)
- создавать несколько выходных результатов из цикла (а не только один)
- гибко обрабатывать и пробрасывать исключения
- использовать if, else и как угодно еще изменять ход выполнения программы

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

Такие ограничения означают, что практически невозможно написать сложный алгоритм, используя Stream API. Либо этот алгоритм будет выглядить очень громоздко, что его проще будет переписать на императивный цикл for.

С другой стороны, благодаря таким ограничениям более простые алгоритмы читаются намного лучше и приятнее программистами.

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

Поэтому правила просты:

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

P.S. А вот как представить многие задачи в виде последовательной цепочки шагов - еще надо научиться!

#dmdev_best_practices

Когда избегать Stream API

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

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

Но как обычно это и бывает - правда где-то по середине. Другими словами говоря,

сила в балансе между двумя подходами и умении их комбинировать. Какие-то задачи лучше решить через Stream API, какие-то в императивном стиле.

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

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

#dmdev_best_practices

Создавай короткие lambda выражения
Когда ты используешь Stream API или Optional с его приятными методами map(), filter(), etc - избегай длинных и сложных lambda выражений в них.
Их не только становится сложно читать, но такой подход убивает всю суть стримов: их компактность и быстрое понимание общей логики кода. Благодаря компактности у программиста появляется возможность смотреть на код с высоты птичьего полета. А если нужны более подробные детали - то уже опускаешься глубже в каждый конкретный метод map(), filter(), etc.

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

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

 .flatMap(
       it -> {
         try {
           return readFile(it.getId()).stream();
         } catch (IOException e) {
           return Stream.empty();
         }
       })

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

 .flatMap(fileDescriptor -> readFileAsByteStream(fileDescriptor.getId()))

Здесь мне каждая деталь помогает понять логику
- и название fileDescriptor
- и что я буду считывать файл на основании id из fileDescriptor
- и даже результат этого чтения: стрим байт

P.S. Заметил, что с каждым постом реакций все меньше.
Дай огня, если хочешь продолжение этого адвента.

#dmdev_best_practices

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

1️⃣ Если нет лайков под постом, то процент того, что человек поставит под ним свой - меньше, ибо нужно совершить больше действий (целых два клика! вместо одного)
2️⃣ Если не попросить реакции/комментариев, то их будет просто в разы меньше

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

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

Думаю, это малая цена за создаваемый полезный контент 🙂