Самое длинное Code Review уже на YouTube

В этот раз Code Review был сделан для довольно большого проекта. Поэтому вместо использования стандартного инструмента пул реквестов в GitHub - было решено выкачать код локально и сделать Code Review через среду разработки IntelliJ IDEA.

Причем сам процесс начался с уровня контроллеров, т.е. сверху вниз. Хотя обычно, если пул реквесты небольшие (как и должны быть на практике!), то лучше выполнять Code Review снизу вверх, начиная с анализа базы данных, сущностей, и поднимаясь все выше по n-tier архитектуре.

На протяжении всего видео я использовал best practices, которые получил на основании своего многолетнего опыта, а также опыта, пота и крови сотен и даже тысяч других программистов. Поэтому будет очень здорово, если эти best practices будет использовать каждый Java разработчик у себя на проекте.

Тем самым поднимая качество и средний уровень разработки программного обеспечения в принципе.

Приятного просмотра 🤗

#18 Мой путь

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

Неделя в Лондоне прошла весьма быстро, и по возвращению назад в Минск я решил поговорить с менеджером о смене проекта, потому что теперь меня не сдерживала гипотетическая командировка или еще что-то. Я хотел нормально программировать на Java, а не писать хранимые процедуры 90% своего рабочего времени. Но, к сожалению, так и не дождавшись ответа и слышав очередное “скоро все будет, подожди” - начал ходить по собеседованиям.

Получив несколько офферов, я пришел вновь к руководству, но уже с другой более уверенной просьбой - уволиться (ох, как хорошо работают эти офферы в твоих руках). И в этот раз мне предложили наконец-то не только нормальный проект, но и неплохо увеличили зарплату. А на проекте большая часть была действительно на языке программирования Java, как я того и хотел! Но было небольшое условие: я еще 3-4 месяца должен поработать дополнительно на полставки на тот старый проект, потому что есть определенные договоренности с заказчиком.

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

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

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

#my_little_story

Беседы с Богом

Начал читать вместе с женой новую книгу. И чем дальше читаю, тем больше она начинает мне нравится.

Особенно эта фраза:

Слова могут помочь тебе понять что-либо. Опыт позволяет тебе знать это.

Ничего не напоминает, если переносить на программирование? 🙂

#dmdev_top_books

Мое первое интервью

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

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

Надеюсь, вам понравится 😎
https://t.iss.one/iamdilettante/257

Как понять время раз и навсегда?

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

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

Именно поэтому я хотел бы раз и навсегда рассказать про самые основы дат и времени, что такое Physical TIme c его Instants и Durations, что такое Civil Time с его Datetime и Periods, а также что такое Time zones, которые помогают соединить все предыдущее вместе.

В заключении посмотрим как время представлено в Java, хотя сами основы применимы для любого языка программирования!

Желаю приятного просмотра 🚀

#1 Backwards compatibility

Когда backend приложение выставляет API для своих клиентов, и этим API уже начинают активно пользоваться в production, то рано или поздно настает момент внесения каких-то изменений в этот API.

Ведь нет таких приложений, которые останавливаются полностью от добавления нового функционала, или улучшения/внесения правок в уже существующий (нет приложений без багов!).

И тут есть два пути:
1️⃣ либо вносить правки в тот же самый API (/v1/users)
2️⃣ либо создать новую версию того же самого API (например, /v1/users -> /v2/users)

В каждом из вариантов есть свои плюсы ➕ минусы ➖

Очевидные минусы первого:
- велик шанс поломать что-то на стороне клиента

Очевидные минусы второго:
- клиентам нужно мигрировать на новый API
- новый API влечет за собой дополнительные расходы на его создание/тестирование/release
- backend нужно сравнительно долгое время поддерживать обе версии API

❓Какой вариант выбираешь ты (пиши в комментариях)?

#2 Backwards compatibility

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

Более того, для клиентов переход на новый API становится огромной незапланированной проблемой, ведь обычно работы и так очень много, и совсем не хочется еще думать о том, что какой-то backend принудительно заставляет смигрировать (исключением, пожалуй, является тот случай, когда и backend и клиент разрабатывает одна и те же команда). И на практике этот переход для всех клиентов может занимать несколько лет!

❗️Но есть одно важное правило:

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

Есть 3 основных вида "совместимости" после правок в API:

1️⃣ Source compatibility - когда код клиента продолжает компилироваться. Особенно важно для протоколов вроде thrift, gRPC, где общая модель часто шарится между клиентом и сервером, хотя и для HTTP тоже вполне встречается.

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

3️⃣ Semantic compatibility - когда семантика (смысл новой версии API, его полей, структуры модели) - вполне понятна и очевидна разработчикам на стороне клиента.

❓А теперь вопрос (пиши в комментариях):
- какие именно изменения в API можно делать, чтобы соблюдалась обратная совместимость?

#3 Backwards compatibility

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

Backwards compatible changes:
- Добавление новых полей, методов, интерфейсов, enums.

Но есть пару нюансов:
1️⃣ Нельзя добавлять новых required полей (поэтому в принципе best practice - это все поля optional за редким исключением)

2️⃣ Все поля должны заполняться точно также, как и в старой версии API. Даже если это поле уже redundant в новой версии.

3️⃣ В случае, если enums используются в качестве response - то тут следует быть аккуратным уже на стороне клиента, т.к. можно написать какой-нибудь неправильно работающий switch. В случае изменения enums в request - тут нет таких проблем.

4️⃣ Не стоит создавать на стороне клиента свои mock/proxy классы на основании интерфейсов API, т.к. в этом случае добавление нового метода в этот интерфейс вызовет ошибку компиляции

Backwards incompatible changes:
1️⃣ Удаление или переименование полей. Потому что переименование - это то же самое, что добавить новое поле (backwards compatible change) и удаление старое (backwards incompatible change)

2️⃣ Изменение типа уже существующего поля.

3️⃣ Добавление пагинации в API, которое возвращает список чего-то (поэтому пагинацию лучше добавлять сразу же).

4️⃣ Изменять default значения полей, особенно enums.

5️⃣ Перемещение
компонентов/классов между файлами и пакетами (потому что пакет - это часть полного имени)

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

PS. Если никак не избежать backwards incompatible changes, то придется создавать новую версию API /v1/users -> /v2/users, потому что ломать клиентов ни в коем случае нельзя!

#19 Мой путь

Спустя 4 месяца, закончился второй проект, и нас перевезли в новый офис около станции метро “Молодежная” в Минске. Я решил подыскать квартиру получше, побольше и поближе к новому офису. Что, собственно, и сделал. У меня снова появилось свободное время, которое я решил посвятить самореализации и чтению книг по саморазвитию. Я читал их просто запоем, начиная от “Самый богатый человек Вавилона“ и заканчивая “7 навыков высокоэффективных людей”.

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

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

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

Точно также и с машинами было: как только я купил себе Volkswagen Polo, то тут же начал замечать их повсюду на дорогах! Та же история повторялась и с другими машинами, что я покупал или хотел приобрести. В последующим я понял, что эта “фича” с твоим вниманием работает во всем, стоит только начать думать в каком-то направлении. Без этого - все проходит сквозь тебя как белый шум (и это правильно, это хорошо, так работает наш мозг!).

Добравшись до своего рабочего компьютера, я сразу начал гуглить, что там за здание такое и как там обучают IT. Сразу нашел их веб сайт, где довольно подробно было расписано, по каким языкам программирования идет обучение и по каким профессиям/специальностям человек может после окончания искать работу. А чуть ниже увидел номера телефонов и надпись: "Ищем менторов по следующим дисциплинам: Java, C#, JavaScript…”.

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

#my_little_story

Микроменеджмент

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

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

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

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

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

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

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

PS. Остается лишь надеяться, что сотрудники датчики хорошие :)

Speculative retry

Одной из очень полезных настроек, которую мы часто используем для своих gRPC клиентов - это speculative retries. Суть ее в том, чтобы не дожидаясь ответа от первого запроса - отправлять через какое-то время второй ТОЧНО ТАКОЙ ЖЕ запрос. Какой ответ был получен первым из двух запросов - тот и используется дальше клиентом, второй же запрос просто отменяется.

Особенно ценны speculative retries при использовании в микросервисной архитектуре, когда один из instance сервера медленно обрабатывает запросы, близок к OOM, и т.д. Но ее можно использовать для клиентов разных протоколов, включая привычные нам http и даже запросы к СУБД.

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

Поэтому как минимум очень рекомендую попробовать внедрить speculative retries в своих проектах и посмотреть как поведет себя система в целом, потому что у нас на проектах они показывают статистически значимый прирост производительности!

Заключительный день моего трёхнедельного отпуска

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

Мне почему-то все время казалось, что это невероятно длинный отпуск. Складывалось ощущение, что прошел как минимум месяц, а то и больше.

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

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

Так что теперь буду стараться продлить свою жизнь не только количественно, но и качественно 🙂