✍️ Почерк программиста

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

1️⃣ Во-первых, у каждого программиста он свой.
Сейчас на проекте у меня 4 backend разработчика, и я могу практически безошибочно сказать, кто написал тот или иной функционал, не глядя в git.

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

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

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

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

Сафари для жизни

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

Поэтому хотел бы поделиться несколькими интересными моментами из нее, что я отметил для себя:

1. Не нужно быть первопроходцем. Достаточно найти того, КТО уже сделал то, чего хочешь ты, либо очень похожее сделал. Человек по своей природе - универсальная копировальная машина

2. Постоянно искать своих КТО. Постоянно учиться чему-то новому

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

4. Чтобы понять свои желания, задай себе вопрос:
Чем бы ты занимался, если бы не было никаких ограничений? (деньги, не в той стране/времени родился)

5. У каждого свои испытания и уроки жизни. Не стоит их менять или помочь решить. Человек сам должен пройти через них и все понять

6. Забивать мяч в футбольные ворота, когда никого нет - может и доставит удовольствие, но лишь на несколько попаданий.
Затем - это просто наскучит.
Гораздо интереснее, когда на поле есть и защитник, которого нужно обойти, и вратарь!
То же самое и в жизни - без испытаний, она будет казаться простой, не интересной и скучной

P.S. Книга довольно коротенькая, поэтому за вечер можно спокойно осилить
#dmdev_top_books

Старая поговорка

Cкажи мне, и я забуду. 
Покажи, и я запомню. 
Дай мне сделать, и я пойму.

PS. Оказывается, это давно известно, что даже если помнишь все, что я говорю в своих курсах - этого все равно не достаточно для понимания материала.
Нужно писать код самому!

Не прошло и 20+ лет прежде чем я наконец-то понял суть грамматики английского языка.

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

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

Меня всегда смущали эти Tenses, и почему никто не может сказать точное их количество: 16? 18? 20?
Я был почему-то уверен, что должно быть что-то вроде Java Core, только при изучении не языков программирования, а человеческих.
А эти Tenses не нужны от слова совсем!

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

Как говорится, лучше поздно, чем никогда :)

Ссылка на книгу тут

#dmdev_top_books

В тему изучения языков...
Думаю, тут все знают с чего нужно начинать и продолжать изучения Java? 😁

#dmdev_mems

Визуализация

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

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

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

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

PS. Кстати, для визуализации я использую приложение Lucidchart

P.S. Для тех, кто не в теме, оставляю ссылку на предыдущие выпуски "Code Review"

DMdev Code Review!

Всем спасибо за участие в опросе. Code Review быть!

Когда: 20.08.22 (суббота) в 10:00 по Москве
Где: прямая трансляция в Google Meet
Продолжительность: 1-1.5 часа
Количество человек: до 100

Кто хочет стать участником code review - подготовьте ссылку на github с кодом своего небольшого проекта.
В начале стрима я выберу рандомную ссылку. Из практики успеваю разобрать 2-3 человека.

P.S. Не стесняйтесь, это отличный шанс получить обратную связь по своему коду и помочь улучшить свои навыки!

До встречи в эфире👇

Best practices in Code Review

Ни один merge своего кода в main ветку не обходится без code review.
А значит каждый разработчик с этим сталкивается при ежедневной работе.

Для хорошего code review, нужно придерживаться определенных правил “на что обратить внимание”.
Эти правила не только разительно улучшают качество его проведения,
но и делают процесс действительно полезным для обоих сторон (owner & reviewer).

Тогда code review не будет сводится к принципу “лишь бы оставить комментарий”.
Все комментарии будут только по делу и не тратят впустую время разработчиков.

1. Код хорошо спроектирован
2. Функциональность легко читать, а значит использовать и поддерживать другим разработчикам
3. Код и его форматирование придерживаются общего стиля всего проекта
4. Нет привнесенной сложности. Код не сложнее, чем требует от того задача
5. Важен не только сам код, но и его контекст
6. Код безопасно работает в многопоточности
7. Код качественно покрыт тестами, которые точно также легко читаются
8. Если и есть комментарии, то они полезны и отвечают на вопрос “почему”, а не “как”

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

#dmdev_ликбез

На канале уже опубликовано первое видео нового курса Bash!

В первом уроке:
- Что нужно знать для прохождения курса
- GUI & CLI
- Командная оболочка shell
- Командная оболочка bash & zsh
- Что будет разбираться в курсе
- Зачем знать bash

Готов подружиться с Bash?
Переходи по ссылке, заваривай чашечку горячего чая и приятного просмотра 😊

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

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

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

2. Торопиться жить - это как брать в долг. Если не угадал с темпом в начале дистанции, то вторую половину придётся идти пешком.

Оба пункта на самом деле далеко не только про бег…

В связи с тем, что я заболел Covid, решил перенести Code Review на неделю вперед.
Так мы сможем провести его более продуктивно для всех участников, ибо сейчас я не в своей лучшей форме 😁

Новое когда: 27.08.22 (суббота) в 10:00 по Москве

PS. Ссылка на митинг остается та же самая (кнопка в верхнем правом углу чата)

#dmdev_code_review
Недавно наткнулся на примерно вот такой код.
Здесь происходит сериализация Java объекта в xml (обычная строка) с помощью библиотеки jaxb.

Как думаешь, что не так с методом serialize? Или все так?
PS. Предположения/идеи пиши в комментариях

1. Параметр marshaller изменяется внутри метода.
Best practices:
- clean code (всегда есть доступ к исходным параметрам функции)
- pure function/immutable (не изменяешь входные параметры, а значит безопасно вызывать такие функции извне)

2. Объект класса Marshaller - не потокобезопасный. Как и говорил в посте по code review выше - нужно всегда обращать внимание на работу кода в многопоточности. Поэтому лучше сделать вместо параметра - локальную переменную через jaxbContext (локальные переменные и jaxbContext точно потокобезопасны).

3. Многие писали про закрытие потока StringWriter. Но это не обязательно для данной реализации Writer, потому он что содержит внутри обычный объект типа StringBuffer.

4. <T extends Serializable> - тоже не следует делать для объекта сериализации, ибо ограничений у jaxb библиотеки на реализацию этого интерфейса тоже нет.

5. На null все параметры проверять и пробрасывать исключение тоже не имеет смысла - все методы будут громоздкие и неуклюжие. Используй Optional или обычные @NonNull аннотации, которые генерируют подобные проверки автоматически согласно fail fast principle

#dmdev_code_review

Code Review gentle reminder

Завтра 27.08.22 (суббота) в 10:00 по Москве

PS. Ссылка в закрепленном сообщении

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

Как и сейчас при подготовке очередного видео по курсу Bash я пытался схематично показать разницу между soft и hard links в Unix operating systems, и сам понял, как это работает на самом деле 😅

Как же я люблю визуализировать!

А ты знал про inode number, который дополнительно хранится с именем любого файла, и для чего он нужен?

Как и обещал, выложил вчерашний уже третий выпуск live code review, где были разобраны 2 проекта, написанные на стандартном стэке технологий: Apache Maven, JUnit 5, Hibernate, Spring.

Также использовалось множество различных дополнительных библиотек:
- lombok для генерации boilerplate кода
- quierydsl для более удобного написания sql запросов с фильтрацией
- testcontainers для поднятия PostgreSQL в docker контейнере в интеграционных тестах
- liquibase для миграции баз данных
И многие другие, что были разобраны и объяснены на курсах dmdev.

Так что кто не смог участвовать, но очень хотел посмотреть - вот ссылка

#dmdev_code_review

Когда спрятал свой баг глубоко в код, и он прошел все тесты 😁

Наверное, это тот самый момент, когда можно сказать: "Это не баг, а фича!".

PS. Что-то все никак не могу успокоиться от этого видоса 😅

#dmdev_mems

Ставишь final над параметрами и локальными переменными?

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

В свою очередь я использую другой подход: по умолчанию нужно воспринимать ВСЕ параметры и локальные переменные как effectively-final (как в замыканиях).

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

#dmdev_ликбез