Как войти в айти, часть 2: полезные материалы

В среду я выставляла опрос про java курсы и их эффективность. Большинство ответивших устроились на работу сразу после курсов.

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

В основном это те, кто проходил интенсивные курсы: job4j, JavaMentor. Ребята учились по 20-40 часов в неделю несколько месяцев, часто с неравнодушным ментором.

Три человека прошли все уровни JavaRush со стажировкой и написали, что этого хватило.

Меня больше интересовали курсы типа скиллбокс, где обещают обучить с нуля до сеньора за 3 месяца. Мне написали несколько ребят, которые получили оффер джуниора после такого обучения. Что им помогло:

🔸 Инженерный или математический бэкграунд, высокий интерес к компьютерам и IT
🔸 Дисциплина и самостоятельность. Ребята сами углубляли темы с курсов - читали книги, статьи, смотрели видео с конференций
🔸 Скромность - готовность работать на старте за 30к, а не требовать сразу 100

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

Итак, как войти в айти за 6 шагов:

Шаг 1. Начать писать java код

Вариант А: если вы никогда не писали код

Курс на степике - бесплатный
JavaRush - 1800 рублей в месяц, огромное количество заданий для тренировки
Книга Head First Java как дополнение

Вариант Б: вы уже писали код

Знаете питон, ходили в кружок программирования в школе и тд. Этот курс на степик поможет привыкнуть к синтаксису java.

Шаг 2. Углубляемся в ООП и библиотеки
Многие хвалят трек Java Backend Developer в Jet Brains Academy

Шаг 3. Изучаем важное

▫️ Git: Теория, тренажёр на русском, тренажёр на английском
▫️Что такое системы сборки
▫️ Spring: посмотрите видео, например, такое по темам Spring Core, Spring MVC, Spring Boot, Spring Data
▫️Паттерны GoF
▫️SQL: учебник-тренажёр 1, учебник-тренажер 2
▫️Курс по алгоритмам

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

Шаг 4: Шлифуем теорию и готовимся к собеседованиям

Списков миллион, можно для начала пройтись по этому, к нему прилагается телеграм бот с вопросами @DevInterviewBot

Бонусный шаг: найти ментора и сделать сервис, где будет Spring, базы данных, JUnit и HTTP-запросы. Выложить проект на гитхаб и прикрепить ссылку к резюме.

Шаг 5: прокачиваем навык собеседований

Идем по циклу:
🔸 Сходить на собеседование
🔸 Проработать вопросы, на которые не ответили

Повторяем, пока не найдём работу🙂

Два полезных телеграм канала

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

Сегодня расскажу про два полезных телеграм канала.

1️⃣ Для начинающих - канал Code Review

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

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

Как всё проходит:
▫️ С понедельника по среду подаются заявки на ревью
▫️ С четверга по воскресенье собирается фидбэк

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

2️⃣ Для продолжающих - канал Хороший разработчик знает

Канал ведёт Павел - разработчик с 15-летним опытом, сейчас работает в Германии. Пишет посты с уклоном в soft skills, менеджмент и верхнеуровневый инжиниринг:

🔹 Как я стал principal engineer - часть 1, часть 2
🔹 Как выбрать процессор в облаке
🔹 Как рассчитать расходы на инфраструктуру

Чем выше по карьерной лестнице, тем важнее эти темы.

У обоих каналов пока немного подписчиков, но ребята делают очень хорошее дело. Давайте их поддержим!

Ментор: зачем нужен и как договориться

Работа с ментором - очень удобный способ прокачать свои навыки. Подойдёт для карьерных подвигов любого уровня:
🔸 Войти в айти
🔸 Джуниор → мидл
🔸 Мидл → сеньор
🔸 Сеньор → тимлид/архитектор/проджект/продакт

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

❓ Что делает ментор?

❌ НЕ берёт ответственность за вас
❌ НЕ читает лекции
❌ НЕ контролирует каждый шаг

✅ Помогает составить план развития
✅ Даёт оценку вашим навыкам со стороны
✅ Подсказывает материалы для изучения

❓ Где найти ментора?

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

Мне не пишите, пожалуйста, я все силы отдаю ребятам с курса многопоточки😊

❓ Как договориться о сотрудничестве?

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

Как может выглядеть сообщение:

Здравствуйте, Диана!

Меня зовут Антон, я студент 4 курса по специальности Инженер-технолог. Последние 2 года увлёкся программированием и понял, что хочу развиваться в этом направлении.

(описываем цель)

Моя цель - к концу года пройти собеседование на Junior Java разработчика в Сбере или в другой крупной компании.

(рассказываем текущую ситуацию)

Я прошёл все курсы, которые вы рекомендовали в этом посте и начал делать пет-проджект. С чем мне нужна помощь:

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

(небольшой комплимент и просьба уделить время)

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

Как вы на это смотрите?

Если знаете, что человек уже занимается менторингом, можно попросить об этом напрямую.

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

Встречи могут быть как 2 раза в неделю, так и раз в месяц.

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

JUnit - самая популярная библиотека для юнит-тестов на java. Сейчас в ходу две версии - четвёртая и пятая.

О чём поговорим на этой неделе:
🔸 В первой части опишу основные фичи JUnit 5
🔸 Во второй и третьей расскажу про проблемы JUnit 4, и как они решались в JUnit 5

Я часто пишу, что разобранный в деталях чужой опыт - это почти свой🙂 Таким вот кейсам и посвящена 2 и 3 часть.

JUnit, часть 1: джентельменский набор

Список фич, которые пригодятся для большинства тестов. Если что-то не видели - почитайте, вдруг пригодится. У JUnit чудесная документация, так что подробно расписывать не буду.

1️⃣ Жизненный цикл теста

Каждый тест - это метод с аннотацией @Test.

Через аннотацию @DisplayName задаётся симпатичное имя теста в отчёте.

Чтобы выполнить что-то до или после выполнения теста, используются методы с аннотациями

▫️ @Before, @BeforeAll
▫️ @After, @AfterAll

JUnit создаёт новый экземпляр класса на каждый тестовый метод. Класс ServiceTest с пятью методами @Test во время запуска превратится в 5 экземпляров класса ServiceTest.

Благодаря этому тесты выполняются независимо.

Этим JUnit отличается от TestNG, где создаётся один экземпляр класса на все тестовые методы. Если хочется как в TestNG, добавьте над классом аннотацию @TestInstance(Lifecycle.PER_CLASS)

2️⃣ Проверки

Сердце каждого теста - методы с приставкой assert*:

🔸 assertTrue
🔸 assertEquals
🔸 assertInstanceOf

В самом JUnit мало методов, более удобные ассерты есть в библиотеках Hamсrest и AssertJ. AssertJ, на мой взгляд, более читабельный, но Hamсrest используется чаще.

3️⃣ Группировка тестов

Аннотация @Tag("groupName") объединяет тесты в группы. Работает и для одного теста, и для класса.

Можно указывать тэги в системе сборки и при запуске тестов из IDE.

4️⃣ Отключение тестов

Аннотация @Disabled. Продвинутые варианты для:
▫️ операционной системы

@DisabledOnOs(WINDOWS)

▫️ версии java

@DisabledOnJre(JAVA_9)
@DisabledForJreRange(min = JAVA_9)

▫️ системных переменных:

@DisabledIfSystemProperty(named = "ci-server", matches = "true")
@DisabledIfEnvironmentVariable(named = "ENV", matches = ".*development.*")

5️⃣ Параметризированные тесты

Помогают запустить один тест с разными аргументами. Выглядит так:

@ParameterizedTest
@ValueSource(ints={100,-14})
public void test(int input) {}

Такой тест запустится дважды - с аргументом 100 и -14.

Вместо готового списка можно брать значения
🔸 из CSV файла @CsvSource
🔸 из метода @MethodSource

6️⃣ Проверка таймаута

▫️ Через ассерт

assertTimeout(ofMinutes(2), ()->{});

▫️ Через аннотацию

@Timeout(value=42,unit=SECONDS)

7️⃣ Полезные библиотеки

▫️ Hamсrest, AssertJ - расширенные библиотеки методов-ассертов
▫️ Mockito для заглушек. Добавляете библиотеку в pom.xml или build.gradle, а в тест - аннотацию @ExtendWith(MockitoExtension.class)
▫️ Testcontainers для запуска внешних компонентов в докере. Добавляем библиотеку, аннотацию @Testcontainers над классом и @Container над компонентом
▫️ Java Faker - генератор данных для тестов

JUnit, часть 2: зачем всё менять?

В JUnit сложилась странная ситуация.

JUnit 4 - топовый java фреймворк для тестов, который используется более чем в 100 тысячах проектов.

JUnit 5 вышел спустя 10 лет и обещает много нового. Но нельзя просто взять и перейти на 5 версию:
▪️ Аннотации вообще другие
▪️ Зависимостей стало больше
▪️ Для совместимости с JUnit 4 надо подключать какой-то винтаж.

Обратная совместимость - обычное дело для java приложений. В новой версии всё работает как раньше. Постепенно добавляешь новые фичи.

Почему JUnit не пошёл по этому пути?

Чтобы ответить на вопрос, нужно копнуть в архитектуру и кейсы использования.

JUnit создавался как удобная библиотека для написания тестов. Для разработчика есть API - аннотации @Test, @Before, методы assertEquals и тд. Здесь всё классно.

Дальше эти тесты запускает IDE или система сборки.

И вот им приходится тяжело. В JUnit 4 API для запуска и анализа тестов очень ограниченный, поэтому IDE и сборщики используют рефлекшн и другие обходные пути.

Чем плох такой подход - понятно. Любое изменение внутренней реализации ломает логику внутри IDE/системы сборки.

JUnit 5 учёл эту проблему и содержит три отдельных артефакта:
🔸 Jupiter - апи для разработчиков
🔸 Platform - апи для запуска и анализа тестов. Целевая аудитория - IDE, плагины и системы сборки. Теперь каждый из них может использовать библиотеку, а не писать свой велосипед
🔸 Vintage - для запуска JUnit 4 тестов на новой платформе

Почему у JUnit 4 и 5 разные аннотации?

У JUnit 5 абсолютно другая кодовая база. Для совместимости с 4 версией пришлось бы наворотить много кода. Гораздо практичнее вынести все адаптеры в отдельный компонент.

Тогда
▫️ Старые тесты будут работать
▫️ Чётко видно, где старые тесты, а где новые. А значит есть шанс, что со временем кодовая база с тестами перейдёт на новую версию.

Что здесь особенного?

В целом выглядит как обычный рефакторинг. Продукт развивается, мир меняется, монолит делится на составные части.

Но в этой истории есть две важные детали.

1️⃣ На страничке принципов разработки команды JUnit есть такие строки:

▫️ JUnit has never tried to be a swiss army knife
▫️ Third party developers move more quickly than we do

Отсюда видна ещё одна мотивация: поощрение развития других библиотек и фреймворков.

Другие разработчики тестовых библиотек теперь могут использовать JUnit платформу и автоматически получать поддержку библиотек во всех IDE и системах сборки.

2️⃣ Вторая инициатива команды JUnit - проект Open Test Alliance for the JVM.

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

Идея проекта - создать общую спецификацию для тестовых библиотек. Проект поддержали TestNG, Spock, Hamcrest, AssertJ, Eclipse, IntelliJ, Gradle, Maven и Allure.

Неизвестно, закончится ли эта история удачно, но идея классная.

Здорово, когда компания делает не только хороший продукт, но и способствует развитию отрасли в целом😇

JUnit, часть 3: модели кастомизации

Изменение архитектуры - не всё, чем JUnit 5 отличается от предыдущей версии. Второе отличие касается модели кастомизации.

В этом посте поговорим, зачем это нужно в тестовом фреймворке, и про разницу между 4 и 5 версией.

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

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

Для одного класса это несложно - просто добавляем методы с аннотациями @Before и @After.

А как посчитать время для всех классов? Здесь варианта два:

🔸 Вынести общий код в отдельный класс, в каждый класс-тест добавить методы Before и After. Решение рабочее, но придётся копипастить методы в каждый класс.

🔸 Внедрить логику где-то на верхнем уровне и включать/выключать её через настройки или аннотации.

Это и есть кастомизация - предусмотренные библиотекой места "встраивания" новой логики. JUnit 4 и 5 используют для этого разные механизмы. Давайте кратко их обсудим.

JUnit 4 Runner

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

Примеры:
▫️ @RunWith(Parameterized.class) запускает параметризованные тесты
▫️ @RunWith(Suite.class) запускает наборы тестов
▫️ @RunWith(SpringJUnit4ClassRunner.class) добавляет спринговые активности до и после запуска теста
▫️ @RunWith(MockitoJUnitRunner.class) позволяет использовать заглушки

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

JUnit 4 Rule

Переопределяем интерфейс TestRule и задаём действие до и после выполнения теста. В тестах выглядит как просто поле:

@Rule
public Timeout globalTimeout = Timeout.seconds(10);

В JUnit 4 есть несколько готовых правил:
▪️ TemporaryFolder - создать временную папку для теста
▪️ ExternalResource - открыть и закрыть внешний ресурс(файл, сокет, БД)

Плюсы-минусы:

✅ Можно использовать несколько rule в одном классе
❌ Работает в рамках одного метода и по сути похож на before/after.

JUnit 5 Extension

Жизненный цикл теста разбивается на 10+ фаз. К каждой из них можно присоединиться, если переопределить нужный интерфейс:
▫️BeforeAllCallback - действие перед всеми тестами
▫️ParameterResolver - передача параметров в тест

Реализуем нужные интерфейсы, регистрируем класс и готово. Похожий механизм используется в Spring.

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

В JUnit 5 полностью убрали поддержку Runner и Rule, всё переписано на Extension API. Кодовые базы стали несовместимы между собой, поэтому и нужна библиотека Vintage с адаптерами.
______

Разбирать чужие кейсы полезно, но не всегда увлекательно. Поэтому вот интересный факт про разработку JUnit.

JUnit - опенсорсный проект, где никто никому не платил за работу.

Но рефакторинг назревал много лет. Однажды ребята решили, что такие грандиозные планы требуют фулл тайм и объявили краудфандинг на JUnit 5.

Сумма требовалась небольшая - 25 тысяч евро, меньше двух миллионов рублей. В итоге собрали в 2 раза больше, и уже через 6 недель был готов первый прототип.

Меня это очень впечатляет, особенно в сравнении со стоимостью и скоростью разработки в энтерпрайзе🙈

Статистика по микросервисам

К концу года появляется много отчётов и статистики о состоянии JVM экосистемы. В целом ситуация не сильно отличается от прошлого года:

🔸 Самая популярная версия java до сих пор 8, используется на 69% проектов. Java 11 встречается на 36% проектов, а 12 и выше - на 16%.

🔸 Самый популярный фреймворк - Spring Boot: 65% проектов. На втором месте Spring MVC: 40% проектов.

🔸 Самая популярная IDE - Intellij IDEA, система сборки - Maven.

🔸 Трендовые GraalVM, Quarkus и Micronaut нашли применение где-то на 4% проектов, цифра примерно как в прошлом году.

Поэтому в этом посте поделюсь статистикой не по джаве, а по всему, что связано с микросервисами. Данные взяла из JRebel Java Developer Productivity Report 2021 и JetBrains The State of Developer Ecosystem 2021.

Демография: Россия - 3% участников, в основном ответы из США, Китая и Европы.

Итак,

49% проектов используют микросервисы
42% сидят с монолитом
10% применяют serverless архитектуру

На чём пишут микросервисы:
41% Java
37% JavaScript
25% Python

Сколько микросервисов на проекте:
34% Меньше пяти
36% 5-10
14% 10-20
16% 20 и больше

Как микросервисы общаются между собой?
83% HTTP-вызовы
47% Месседж брокер
25% WebSocket
20% RPC

С чем возникает много проблем:
30% Общение между сервисами
26% Масштабирование и производительность
24% Развернуть что-нибудь локально 🥲
14% Проблемы в коде микросервисов

Популярные performance проблемы:
54% Долгий Response Time
39% High CPU Usage
35% Утечки памяти
26% Много открытых соединений

Сколько времени занимает поднятие окружения на удалённой машине:
42% Меньше трёх минут
38% 3-10 минут
21% Дольше 10 минут

Только 20% разработчиков во время деплоя переключаются на другие рабочие задачи. Остальные 80% ходят за чаем, общаются с семьёй и листают соцсети🙂

Intellij IDEA: редактирование кода

Несколько простых приёмов для быстрой работы.

Легендарные комбинации

Ctrl + C
Ctrl + V
Ctrl + X

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

Удалить всю строку:

Ctrl + Y

Дублировать строку:

Ctrl + D

Выделить часть кода:

Ctrl + W

При каждом нажатии W захватывается всё большая область.

Переместить выделенный код:
Ctrl + Shift + ⬆️
Ctrl + Shift + ⬇️

L is for Liskov

— SOLID принципы знаете?

Думаю, нет разработчика, который не слышал на собеседовании такой вопрос.

Расшифровку знают многие. А вот практические знания часто ограничиваются Single Responsibility и Interface Segregation.

Как применять остальные буквы в ежедневной работе — не всегда понятно. Больше всего вопросов возникает насчёт L — Liskov Substitution Principle. О нём и будет сегодняшний пост.

Полное определение звучит так:

Пусть q(x) является свойством верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.

По-простому: если заменить класс А на подкласс B, то система будет работать корректно и без неожиданных сайд-эффектов.

A service1 = new A();
A service2 = new B();

Для наблюдателя service1 и service2 ведут себя совершенно одинаково. Класс-наследник дополняет поведение родителя, а не замещает его. В результате система работает более предсказуемо.

Как это выглядит на практике:

1️⃣ Выходной тип метода в наследнике такой же как у родителя или расширенный

Базовый класс: Info getInfo()

Наследник:

✅ BigInfo getInfo()
❌ Object getInfo()

2️⃣ Подклассы не бросают дополнительных исключений, но могут уменьшить их список

Базовый класс: void save() throws FileNotFoundException

Наследник:

✅ void save()
❌ void save() throws FileNotFoundEx, InterruptedEx

Java — типизированный язык, поэтому пункты 1 и 2 контролируются компилятором.

3️⃣ Типы входных параметров те же или менее строгие. Пункт для общего понимания, тк для Java это неприменимо

Базовый класс: void add(Account acc)

Наследник:

✅ void add(Object acc)
❌ void add(AdminAccount acc)

Следующие пункты компилятор уже не проверит, это целиком ответственность программиста.

4️⃣ Метод подкласса делает то же, что и метод базового класса

Базовый класс: метод countVisitors считает пользователей

Наследник:
✅ Считает пользователей чуть по-другому
❌ Считает пользователей, обновляет статистику, сохраняет результат в БД

5️⃣ Метод наследника взаимодействует с теми же сущностями:
▪️ Метод родителя увеличивает счётчик - подкласс тоже увеличивает
▪️ Метод родителя не меняет поле - подкласс тоже не меняет
▪️ Метод родителя вызывает другие методы в определённом порядке - подкласс делает то же самое

А что можно вообще?

Если в подклассе объявлены новые поля, то методы подкласса могут делать с ними что угодно. На этом всё🙂

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

Нарушения принципа подстановки — повод пересмотреть иерархию наследования или совсем от неё отказаться.

Чем отличаются Dependency injection, Dependency invertion и Inversion of Control

Прошлый пост про Liskov, как говорится, "взорвал мой директ", поэтому на этой неделе расскажу про ещё два популярных принципа.

Сегодня про букву D из SOLID — Dependency Inversion. Что это, и чем отличается от Dependency injection и Inversion of Control. Понимание пригодится на собеседованиях, при чтении статей по дизайну и архитектуре.

Будем разбираться на простом примере: класс Service записывает логи в файл через класс FileLogger:

class FileLogger {…}
class Service {
  FileLogger logger=new FileLogger();
}

Сделаем код чуть лучше с помощью разных принципов:

1️⃣ Dependency injection
— компоненты создаются не внутри класса, а где-то в другом месте.

Как реализовать: перенести инициализацию логгера в конструктор или сеттер:

class Service {
  FileLogger logger;
  Service (FileLogger logger) {
    this.logger=logger;
  }
}

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

⚔️Историческая справка
Когда Spring ещё не был популярен, в проектах использовался паттерн Service Locator.

Суть: компоненты создаются в классе ServiceLocator, а другие классы получают к ним доступ через статические методы:

class ServiceLocator {
  static Logger logger = …
  static Logger getLogger() {
     return logger;
  }
}

class Service {
  Logger logger=ServiceLocator.getLogger();
}

2️⃣ Dependency invertion (D из SOLID)
▫️Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций
▫️Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракции

Как реализовать: использовать интерфейс логгера, а не конкретный класс

interface Logger {…}
class FileLogger implements Logger {…}

class Service {
   Logger logger=new FileLogger();
}

✅ Интерфейс проще использовать, так как методов меньше
✅ Реализацию легко заменить
✅ Оба класса проще тестировать

Термин "абстракция" используется, потому что SOLID не привязан только к джаве. Группу методов можно выделить в интерфейс, в абстрактный класс и даже в обычный класс. Но интерфейс — наилучший вариант

3️⃣ IoC - Inversion of Control
В маленьких программах жизнь начинается в методе main. Программист создаёт объекты и вызывает их методы, все шаги явно прописаны.

Inversion of Control — это когда ход выполнения программы задаёт фреймворк. Например, Spring создаёт объекты, принимает запросы и не даёт программе завершиться.

Как реализовать: использовать аннотации фреймворка

@Component class FileLogger {…}
@Component class Service {
  @Autowired
  FileLogger logger;
}

✅ Меньше скучного кода
✅ Низкая связность — код легко читать, менять и тестировать

Резюме:
🔸Dependency injection — класс не создаёт компоненты напрямую, они передаются через конструктор или сеттер
🔸Dependency invertion — класс работает с другими компонентами через интерфейс
🔸Inversion of Control — ход программы задаёт фреймворк

❗️Ответ на вопрос перед постом:
Это словоблудие относится к Dependency injection

DRY для джуниора и сеньора

Раз уж пошли по базовым принципам, то сегодня разберём DRY: Don't Repeat Yourself.

Такой популярный и такой обманчиво простой.

Отношение к DRY эволюционирует по мере роста разработчика и проходит через четыре этапа:

🔸 Этап 1. Стажёр

Боготворит DRY, считает дублирование кода ужасным грехом. Действительно, зачем писать несколько раз одно и то же?

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

🔸 Этап 2. Джуниор

Любит DRY, но понимает, что любить — значит страдать.

Проект становится больше, а бизнес-логика — сложнее. Добавить в метод ещё один if уже не так просто. Сложно разбираться в коде, сложно писать тесты, но чего не сделаешь ради хорошего кода. А хороший код на этом этапе — это максимально сжатый код🙂

🔸 Этап 3. Мидл

Всё ещё любит DRY, но более возвышенно — на уровне иерархий и паттернов. Когда приходится дублировать код, то грустит, что на проекте плохая архитектура.

🔸 Этап 4. Сеньор

Распилил монолит на сервисы, реализовал десятки крупных фич и отдал сердце SOLID.

А теперь по делу

Часто начинающие разработчики считают, что хороший код — это суперконцентрированный код с кучей паттернов и хитрых приёмов.

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

Если бизнес-процессы не пересекаются, то связывать их искусственно с помощью кода — плохая идея.

🙁 Класс User c 20 полями. 10 полей используются в 1 сервисе, другие 10 - в другом, половина объекта всегда пустая
🙁 Универсальный метод с 7 параметрами под разные случаи
🙁 Сложная иерархия с кучей шаблонных методов

Единственный плюс — меньше кода. Зато
❌ Плохая читаемость
❌ Сложно писать тесты
❌ Сильная связность. Функцию тяжело поменять или вынести в другой модуль

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

Что такое Serverless. Часть 1: предыстория

По статистике 2021 года около 10% проектов уже используют архитектуру Serverless.

Новые технологии — это классно, но важно понять, в чём вообще проблема и как она УЖЕ решается текущими средствами. И зачем решать её по-новому. Нужен чёткий ответ:

— Зачем переходить с микросервисов на Serverless? Что мы от этого получим?

Для ответа немного углубимся в историю инфраструктуры.

1️⃣ Всё своё

До 2006 года в каждой IT компании была особая комната — серверная. Системные администраторы настраивали сервера, следили за обновлениями, безопасностью, блоками питания и решали тысячу других вопросов.

❌ Много расходов на оборудование и персонал
❌ Железки надо закупать, подключать и нельзя сдать обратно. Сложно наращивать мощности или оптимизировать нагрузку

2️⃣ IasS — Infrastructure as a Service

В 2006 появился Amazon EC2 и начался тренд на IaaS: код запускается не на собственных серверах, а на арендованных.

Это самый простой вариант облачной инфраструктуры. Сейчас подобную услугу предлагают AWS, Google, DigitalOcean, Microsoft, IBM, SAP, для патриотов есть Яндекс и Сбер.

✅ Легко добавлять и сокращать ресурсы
✅ Меньше расходы на персонал
✅ Не надо беспокоиться об отключении электроэнергии и потопах

Инфраструктура всё ещё требует внимания — на арендованной виртуалке надо установить ОС, JVM, все службы и обновления, настроить компоненты и развернуть сервисы.

Большая часть этих операций почти у всех одинакова. Так что дальше расходимся на две ветки:

🅰️ PaaS — Platform as a Service

PaaS = IaaS + ОС + базовый мониторинг + легко подключаемые компоненты

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

Примеры PaaS: Heroku, AWS Elastic Beanstalk и тд

✅ Много готовых компонентов — можно быстро настроить работающую систему
❌ Набор компонентов большой, но всё же ограниченный. Если использовать что-то непопулярное, то придётся искать обходные пути
❌ Сильная привязка к вендору. Выбрал PaaS от амазона — скорее всего файловое хранилище, очереди и БД тоже будут амазон.

🅱️ Докер

Популярная альтернатива PaaS — докер-контейнеры в предоставленных виртуалках. В каждом контейнере свой runtime и все нужные для сервиса файлы.

Для управления контейнерами есть куча инструментов — Kubernetes, Mesos, Google Container Engine. Amazon ECR и Google CR помогают с хранением докер-образов, AWS Fargate — с масштабированием.

✅ Супер гибкость. Можно собрать любые компоненты с любыми настройками и связать их как угодно
❌ Cложно выбирать и долго настраивать

Заметили, что не было ни единого слова про архитектуру? PaaS и Docker только упрощают сборку инфраструктуры. Пока что нет разницы, что запускать внутри — гигантский монолит или сервис из трёх файлов.

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

Что такое Serverless, часть 2

В прошлом посте рассмотрели, как инфраструктура понемногу переходила на аутсорс. Serverless — следующий этап такого перехода.

AWS Lambda — самая первая и популярная платформа для Serverless, поэтому дальше буду говорить про неё.

Важно! Есть ещё термин Lambda Architecture — это вообще про другое.

Итак, в чём суть.

Любое приложение — это набор функций. Допустим, в интернет-магазине три функции:
▫️ Добавить товары
▫️ Сделать заказ
▫️ Вывести список текущих заказов

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

Serverless абстрагируется от этой проблемы. Мы не распределяем функциональность по артефактам и работаем просто с функциями. Проектируем не сборник фич, а отдельные маленькие компоненты.

Поэтому Serverless считается архитектурой. Или отдельной моделью проектирования, если термин "архитектура" кажется вам неподходящим.

Платформы, на которых запускаются Serverless приложения, называют FaaS — Functions as a Service.

В Петербурге Serverless используют около 10 компаний, что не очень много. Но тренд растёт, даже Сбер уже сделал свою FaaS платформу.

Как это работает?

Каждая функция состоит из:
▫️ Исполняемого кода
▫️ Списка зависимостей
▫️ Списка событий-триггеров
▫️ Конфигурации — количество памяти, необходимые права, время жизни функции и тд

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

Станет ли код проще?

Точно нет. Проектировать систему с изолированными функциями гораздо сложнее, чем слепить всё в монолит или десяток сервисов🙂

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

Зачем переходить на Serverless?

Если микросервисы в PaaS или докере нормально справляются, то должна быть веская причина что-то менять. Таких причин может быть две:

1️⃣ Функции развёртываются по необходимости. Облака это удобно, но иногда очень дорого. FaaS модель неплохо снижает стоимость при переменной нагрузке.

2️⃣ Масштабирование по умолчанию. В AWS Lambda автоматически масштабируются и сервисы, и остальные компоненты, например, БД. В докере и PaaS для этого нужно прилагать немало усилий.

Сколько стоит?

Допустим бэкенд мобильного приложения принимает за месяц 3 миллиона запросов, среднее время — 120мс. Выделим для одной функции 1536 МБ и процессор х86.
Плата за месяц в таком случае будет 2,7 доллара.

Это только AWS Lambda, остальные компоненты оплачиваются отдельно.

Что ещё

✅ Никаких Ansible, Docker, bash скриптов
✅ Базовый мониторинг и аналитика из коробки
✅ Spring Cloud и плагин IDEA AWS Toolkit сильно облегчают разработку

😐 Нужны отличные навыки проектирования
😐 Своеобразное тестирование

❌ Сложно адаптировать уже существующие приложения
❌ Больше задержек, response time может увеличиться

В целом Serverless — очевидный тренд, который набирает обороты. Жду в ближайшие два года тонну докладов на конференциях на эту тему, как когда-то было про микросервисы и реактивное программирование🙂

​Сколько объектов Number[] будет создано в этом коде?

Enum и метод values

Если вы новичок и мало знаете про enum, то лучше начать с этого лонгрида. Сегодня обсудим итерацию через метод values и как его оптимизировать.

Итак, enums — это синтаксический сахар, который при компиляции превращается в обычный класс. Класс из примера выше превратится в

public final class Number extends Enum<Number

>

Элементы енума станут статическими полями:

public static final Number ONE;
public static final Number TWO;
public static final Number THREE;

Внутри нового класса появится массив:

Number[] VALUES = { ONE, TWO, THREE};

И его копия будет возвращаться в методе values:

return VALUES.clone();

При каждом вызове values возвращается новая копия массива. Дело в том, что массивы — это изменяемый объект. Если возвращать ссылку на VALUES напрямую, любой желающий сможет поменять исходный массив:

Number.values()[2] = ONE;

Это небезопасно, поэтому каждый раз возвращается копия.

Если цикл с values используется в высоконагруженном коде, то разумно сохранить массив в отдельную переменную и переиспользовать её:

static Number[] numbers = Number.values();

for (Number n : numbers) {…}

Если код вызывается редко, то смысла в отдельной переменной нет.

Пример из жизни

В Spring Web 5.2 в классе HttpStatus есть такой код:

for (HttpStatus status : values()) {
  if (status.value == statusCode) {
    return status;
  }
}

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

Теперь код выглядит так:

private static final HttpStatus[] VALUES;

static {
  VALUES = values();
}

for (HttpStatus status : VALUES) {
  if (status.value == statusCode) {
    return status;
  }
}

Ответ на вопрос перед постом

Будет создано 3 массива: один внутри класса Number и два клона при вызове values()