🔴 Завтра тестовое собеседование с Java-разработчиком

11 февраля(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика.

Как это будет:
📂 Сергей Чамкин, старший разработчик из Uzum, ex-WildBerries, будет задавать реальные вопросы и задачи разработчику-добровольцу
📂 Cергей будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью
📂 В конце можно будет задать любой вопрос Сергею

Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.

Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot

Реклама.
О рекламодателе.

🏗 Структурные паттерны: Адаптер, Декоратор, Прокси

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

🔌 1. Adapter (Адаптер)

Суть: Делает несовместимые интерфейсы совместимыми.
Это как переходник для розетки. У вас вилка американская, а розетка европейская. Адаптер позволяет им работать вместе.

Где нужен: Когда есть старый класс (Legacy), который нельзя менять, но его нужно использовать в новом коде.

Пример: У нас есть система, которая понимает только KM/H (километры), а внешняя библиотека выдает скорость в MPH (мили).

// 1. Наш интерфейс (чего мы ждем)
interface Movable { double getSpeed(); } // км/ч

// 2. Чужой класс (что есть)
class Bugatti { 
    double getSpeedMph() { return 268; } 
}

// 3. Адаптер (Переводчик)
class MovableAdapter implements Movable {
    private Bugatti bugatti;

    public MovableAdapter(Bugatti bugatti) {
        this.bugatti = bugatti;
    }

    @Override
    public double getSpeed() {
        return convertMphToKmph(bugatti.getSpeedMph());
    }
}

🎁 2. Decorator (Декоратор/Обертка)

Суть: Динамически добавляет объекту новые обязанности (функционал).
Это альтернатива наследованию. Вместо того чтобы создавать CoffeeWithMilkAndSugar, мы берем Coffee и заворачиваем его в Milk, а потом в Sugar.

Принцип: Матрешка. Каждый декоратор делает свою работу и вызывает следующий.

Пример:

// Базовый кофе
Coffee coffee = new SimpleCoffee(); 
System.out.println(coffee.getCost()); // 10$

// Добавили молоко (Обернули)
coffee = new MilkDecorator(coffee); 
System.out.println(coffee.getCost()); // 12$

// Добавили сахар (Обернули еще раз)
coffee = new SugarDecorator(coffee); 
System.out.println(coffee.getCost()); // 13$

Важно: В java.io это используется повсюду: new BufferedReader(new FileReader(file)).


🛡️ 3. Proxy (Заместитель)

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

Зачем?

1. Ленивая загрузка (Lazy Loading): Не грузить тяжелую картинку/БД, пока ее реально не попросят.

2. Безопасность: Проверить права доступа перед выполнением метода.

3. Логирование: Записать "Метод вызван" и передать вызов дальше.

Пример:

interface Image { void display(); }

class RealImage implements Image {
    public RealImage(String file) { loadFromDisk(file); } // Долгая операция!
    public void display() { System.out.println("Displaying..."); }
}

class ProxyImage implements Image {
    private RealImage realImage;
    private String file;

    public ProxyImage(String file) { this.file = file; }

    @Override
    public void display() {
        if (realImage == null) {
            realImage = new RealImage(file); // Грузим только сейчас!
        }
        realImage.display();
    }
}

Spring Magic: Весь Spring держится на Прокси! Когда вы ставите @Transactional, Spring создает прокси вокруг вашего сервиса, открывает транзакцию, вызывает ваш метод, а потом закрывает транзакцию.


🔥 Итог

🔴Adapter - меняет интерфейс объекта (чтобы подошел).

🔴Decorator - меняет поведение объекта (добавляет фичи), не меняя интерфейс.

🔴Proxy - контролирует доступ к объекту (ленивость, защита).

#DesignPatterns #Adapter #Decorator #Proxy #Architecture

📲 Мы в MAX

👉@BookJava

🎥 Открытый урок «Class Data Sharing и его перспективы».

🗓 17 февраля в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «Java Developer. Advanced».

Быстрый, лёгкий старт Java-сервисов — конкурентное преимущество. Разберём, чем поможет Class Data Sharing и где он уместен.

Что будет на вебинаре:
✔️ Назначение Class Data Sharing.
✔️ Поддержка и использование в Spring Boot.
✔️ Разница с Native Image для GraalVM.

В результате вебинара:
Сможете запустить Spring Boot-приложение с использованием CDS и понять базовую настройку. Получите представление, чем CDS отличается от Native Image (GraalVM).

Кому будет интересно:
Подойдёт Java-разработчикам и инженерам, которым важно ускорить старт сервисов и оптимизировать время запуска в проде.

🔗 Ссылка на регистрацию: https://vk.cc/cUiTYA

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🧠 Поведенческие паттерны: Стратегия, Наблюдатель, Цепочка

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

🗺 1. Strategy (Стратегия)

Суть: Позволяет менять алгоритм поведения объекта прямо "на лету", во время выполнения программы.
Это убийца бесконечных if (type == "CARD") { ... } else if (type == "PAYPAL") { ... }.

Аналогия: Навигатор. Вы строите маршрут из точки А в точку Б. Стратегия - это способ передвижения:

🔴Пешком (один алгоритм).
🔴На машине (другой алгоритм).
🔴На автобусе (третий алгоритм).
Цель одна, пути реализации разные.

Код:

// Общий интерфейс
interface RouteStrategy {
    void buildRoute(String a, String b);
}

// Конкретные стратегии
class RoadStrategy implements RouteStrategy { ... }
class WalkingStrategy implements RouteStrategy { ... }

// Контекст (Навигатор)
class Navigator {
    private RouteStrategy strategy;

    public void setStrategy(RouteStrategy strategy) {
        this.strategy = strategy; // Меняем на лету!
    }

    public void buildRoute(String a, String b) {
        strategy.buildRoute(a, b);
    }
}

👀 2. Observer (Наблюдатель / Listener)

Суть: Один объект (Subject) меняет свое состояние, и все зависимые от него объекты (Observers) тут же узнают об этом.

Аналогия: YouTube-канал.

🔴Блогер (Subject) выпускает видео.
🔴Подписчики (Observers) получают уведомление.
🔴Если вы отписались - уведомления приходить перестанут.

Код: Это основа всех UI-фреймворков (кнопка нажата -> слушатель сработал) и даже архитектуры Kafka.

class NewsAgency {
    private List<Channel> channels = new ArrayList<>();

    public void subscribe(Channel channel) {
        channels.add(channel);
    }

    public void broadcast(String news) {
        for (Channel channel : channels) {
            channel.update(news); // Уведомляем всех!
        }
    }
}

🔗 3. Chain of Responsibility (Цепочка обязанностей)

Суть: Запрос передается по цепочке обработчиков. Каждый обработчик решает: обработать запрос самому или передать следующему.

Аналогия: Техподдержка.

1. Сначала отвечает Чат-бот (Уровень 1). Не справился? -> Передает дальше.

2. Оператор колл-центра (Уровень 2). Не справился? -> Передает дальше.

3. Инженер (Уровень 3). Решает проблему.

Пример в Spring:
Spring Security работает именно так! Ваш HTTP-запрос проходит через цепочку фильтров:

🔴CorsFilter (проверяет домен) -> JwtFilter (проверяет токен) -> UsernamePasswordFilter (проверяет логин).
Если хоть один фильтр скажет "Нет", запрос дальше не пойдет.

Код:

abstract class SupportHandler {
    protected SupportHandler next;

    public void setNext(SupportHandler next) { this.next = next; }

    public void handleRequest(String issue) {
        if (canHandle(issue)) {
            solve();
        } else if (next != null) {
            next.handleRequest(issue); // Передаем следующему
        }
    }
}

🔥 Итог

🔴Strategy - Выбираем алгоритм действия (Платим картой или кэшем?).
🔴Observer - Слушаем изменения (Вышло видео -> пришло уведомление).
🔴Chain of Responsibility - Передаем эстафету (Фильтр 1 -> Фильтр 2 -> Контроллер).

#DesignPatterns #Behavioral #Strategy #Observer #ChainOfResponsibility

📲 Мы в MAX

👉@BookJava

🧅 Архитектура: От Слоев к Луковице

❌ Проблема Слоенки (Database Driven Design)

В классическом Spring-приложении зависимости идут сверху вниз:

1. Контроллер зависит от Сервиса.
2. Сервис зависит от Репозитория (Базы данных).

В чем подвох?
Ваша бизнес-логика (Сервис) намертво привязана к деталям хранения данных (БД).

🔴Хотите поменять SQL на NoSQL? Переписывайте сервис.

🔴Хотите протестировать логику? Придется мокать базу данных.

🔴Главный грех: База данных диктует, как писать бизнес-логику. А должно быть наоборот!


✅ Решение: Clean / Hexagonal / Onion

Дядя Боб, Алистер Кокберн и другие умные дядьки придумали, как перевернуть игру.
Главная идея: Зависимости должны быть направлены ТОЛЬКО внутрь, к центру.

Представьте приложение как Луковицу.

1. Ядро (Core / Domain) - Центр Вселенной

Здесь живет ваша Бизнес-логика.

🔴Сущности (User, Order).

🔴Правила (User не может быть моложе 18 лет).

🔴Правило: Здесь НЕТ фреймворков. Никакого Spring, никакого Hibernate, никакого SQL. Только чистая Java.

🔴Этот слой ничего не знает о внешнем мире.

2. Порты (Ports / Use Cases) - Граница

Ядро определяет интерфейсы (Порты), которые ему нужны для работы.

🔴Например: interface UserRepository (найти пользователя, сохранить пользователя).

🔴Заметьте: интерфейс лежит внутри домена!

3. Адаптеры (Adapters / Infrastructure) - Внешний мир

Здесь живут детали реализации.

🔴PostgresUserRepository реализует интерфейс UserRepository.

🔴RestController вызывает методы Ядра.

🔴Здесь подключается Spring, Hibernate, Kafka и всё остальное.

🔄 Инверсия Зависимостей (DIP)

Следите за руками:

1. В слоеной архитектуре: Service зависит от PostgresDao.
2. В чистой архитектуре: Service зависит от Интерфейса. А PostgresDao зависит от Интерфейса.

Оба зависят от абстракции. БД стала просто плагином. Вы можете выкинуть Postgres и поставить заглушку (In-Memory Map) - и бизнес-логика даже не заметит подмены!

⚖️ Когда что использовать?

1. Layered (Controller-Service-Repo)

• ✅ Простые CRUD-приложения.
• ✅ Админки, прототипы.
• ✅ Когда логики почти нет, просто перекладываем данные.

2. Hexagonal (Ports & Adapters)

• ✅ Сложная бизнес-логика (Банкинг, Финтех, Логистика).
• ✅ Приложение живет долго (5+ лет).
• ✅ Нужно писать много Unit-тестов для ядра, не поднимая контекст Spring.

🔥 Итог

🔴Layered: Быстро писать, сложно поддерживать. БД - главная.
🔴Clean: Дольше писать (много маппингов DTO <-> Entity), легко поддерживать. Логика - главная.

#Architecture #CleanArchitecture #Hexagonal #Spring #Java

📲 Мы в MAX

👉@BookJava

🧠 Domain Driven Design: Программируем на языке бизнеса

Главная проблема IT: Разработчики говорят на языке таблиц (INSERT, Foreign Key, DTO), а бизнес на языке денег и процессов («Провести проводку», «Списать остаток»).

DDD (Предметно-ориентированное проектирование) - это попытка убрать переводчика.


🗣 1. Ubiquitous Language (Единый язык)

Это фундамент. Код должен звучать так же, как речь эксперта.

🔴Плохо (CRUD-мышление):
• Бизнес: "Клиент сменил адрес доставки".
• Код: user.setAddress("New York"); userRepo.save(user);


🔴Хорошо (DDD):
• Код: user.relocateTo(new Address("New York"));

Методы должны называться глаголами бизнеса, а не сеттерами.


📦 2. Bounded Context (Ограниченный контекст)

Самая большая ошибка новичка - создать один класс Product на всё приложение.

🔴Для Продаж: Товар - это цена, описание, картинки.
🔴Для Склада: Товар - это вес, габариты, номер полки.
🔴Для Бухгалтерии: Товар - это актив, амортизация, инвентарный номер.

В DDD мы не делаем монстра. Мы создаем разные модели для разных контекстов.

🔴SalesContext.Product
🔴WarehouseContext.StockItem

Эти модели могут даже иметь разные ID и общаться друг с другом только через события (Kafka).


🏗 3. Tactical DDD (Строительные блоки)

Как писать код внутри контекста?

A. Entity (Сущность)

Объект, у которого есть Identity (ID).
Если у двух людей одинаковое имя, это все равно два разных человека (разные ID).

🔴Пример: User, Order.
🔴Они живут долго, меняют свое состояние, но остаются собой.

B. Value Object (Объект-значение)

Объект, который определяется только своими данными. У него нет ID. Он неизменяем (Immutable).

🔴Пример: Money, Address, Color.
🔴Если у меня есть 100 рублей и у вас 100 рублей - это одни и те же 100 рублей. Нам не важно, какая именно это купюра.
🔴Правило: Не используйте примитивы! Вместо String email используйте класс EmailAddress. Там можно спрятать валидацию.

C. Aggregate (Агрегат)

Это кластер объектов, которые живут и умирают вместе.

🔴Пример: Заказ (Order) + Позиции заказа (OrderItems).
🔴Aggregate Root (Корень): Это главный объект (Order).
🔴Правило: Извне можно обращаться только к Корню. Нельзя получить ссылку на OrderItem и изменить его цену напрямую. Вы должны сказать: order.changeItemPrice(...). Это гарантирует целостность данных.


🩸 Anemic vs Rich Model (Анемичная vs Богатая модель)

❌ Анемичная (Стандартный Spring):
Класс — это просто мешок с геттерами и сеттерами. Вся логика лежит в Service.

// Service
public void completeOrder(Long id) {
    Order order = repo.findById(id);
    if (order.getStatus() != PAID) throw ...
    order.setStatus(COMPLETED); // Кто угодно может поменять статус!
    repo.save(order);
}

✅ Богатая (DDD):
Логика и валидация живут внутри Сущности. Сервис просто координирует работу.

// Entity
public void complete() {
    if (this.status != PAID) throw new DomainException("Не оплачено!");
    this.status = COMPLETED;
    // Можно даже вернуть событие OrderCompletedEvent
}

// Service
public void completeOrder(Long id) {
    Order order = repo.findById(id);
    order.complete(); // Вся бизнес-логика внутри
    repo.save(order);
}

🔥 Итог

DDD - это сложно, но необходимо для больших проектов.

1. Говорите на языке бизнеса (Ubiquitous Language).
2. Разделяйте модели (Bounded Contexts).
3. Используйте Value Objects вместо примитивов.
4. Прячьте логику внутрь Rich Domain Model.

#Architecture #DDD #DomainDrivenDesign #Java #Microservices

📲 Мы в MAX

👉@BookJava

❗️Микросервисы часто обещают масштабируемость, но на практике превращаются в сложную и хрупкую систему.

Причина почти всегда одна — неверная декомпозиция. Слишком мелкие сервисы, плотные связи, распределённые транзакции и постоянные проблемы с данными.

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

📌 Встречаемся 18 февраля в преддверии старта курса «Highload Architect».

Зарегистрируйтесь, чтобы не пропустить: https://vk.cc/cUudMf

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🧹 Гигиена кода: Рефакторинг и Технический долг

Почему проекты умирают? Не из-за плохой идеи, а из-за того, что стоимость добавления новой фичи становится выше, чем прибыль от неё.
Разработчики тратят 90% времени на чтение и распутывание старого кода, и только 10% - на написание нового.

💳 1. Technical Debt (Технический долг)

Это метафора, придуманная Уордом Каннингемом.

🔴Суть: Вы берете "кредит" у качества кода, чтобы выпустить фичу быстрее ("Сделаем костыль, потом поправим").

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

🔴Банкротство: Момент, когда код настолько запутан, что проще всё переписать с нуля, чем добавить кнопку.

Главное правило: Долги надо возвращать. Выделяйте 20% времени в спринте на рефакторинг.

2. Code Smells (Запахи кода)

Как понять, что код "тухнет"? По запаху.
Это не баги (код работает), это признаки плохого дизайна.

Топ-5 самых вонючих мест:

1. God Object (Божественный объект): Класс Manager или Utils, который знает всё и делает всё. Нарушает SRP (Single Responsibility Principle).

2. Long Method (Длинный метод): Если метод не помещается на один экран монитора - это запах.

3. Magic Numbers (Магические числа):
• Плохо: if (status == 7) ... (Что такое 7? Счастливое число?)
• Хорошо: if (status == STATUS_ACTIVE) ...


4. Duplicated Code (Дублирование): Copy-Paste это зло. Если вы нашли ошибку в одном месте, вам придется искать её копии по всему проекту. Принцип DRY (Don't Repeat Yourself).

5. Feature Envy (Зависть к чужим данным): Метод класса А постоянно обращается к полям класса Б. Скорее всего, этот метод должен жить в классе Б.

🛠 3. Refactoring (Рефакторинг)

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

Золотое правило Бойскаута:

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

Зашли в файл поправить баг? Поправьте заодно название переменной или вынесите метод. Маленькие улучшения каждый день спасают проект.

💻 До и После

🤢 Было (Smelly Code):

public void process(Order o) {
    // Magic Number + Long Method + Feature Envy
    if (o.getItems().size() > 0 && o.getStatus() == 1) {
        double total = 0;
        for (Item i : o.getItems()) {
            total += i.getPrice() * 1.2; // Что такое 1.2? НДС? Наценка?
        }
        System.out.println("Total: " + total); // Hardcoded output
    }
}

😎 Стало (Clean Code):

private static final double TAX_RATE = 1.2;
private static final int STATUS_ACTIVE = 1;

public void printOrderTotal(Order order) {
    if (isEligibleForProcessing(order)) {
        double total = calculateTotal(order);
        outputResult(total);
    }
}

private boolean isEligibleForProcessing(Order order) {
    return !order.isEmpty() && order.getStatus() == STATUS_ACTIVE;
}

private double calculateTotal(Order order) {
    return order.getItems().stream()
           .mapToDouble(item -> item.getPrice() * TAX_RATE)
           .sum();
}

Код стал читаемым, как книга.

🔥 Итог

1. Технический долг неизбежен, но его нужно гасить.
2. Запахи кода (магические числа, дубликаты) подсказывают, где рефакторить.
3. Рефакторинг делаем только при наличии Тестов (иначе вы просто ломаете рабочий код).

#Refactoring #CleanCode #TechnicalDebt #CodeSmells #Java

📲 Мы в MAX

👉@BookJava

🚀 CI/CD: Роботы делают рутину за вас

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

🛠 1. CI (Continuous Integration / Непрерывная интеграция)

Суть: Разработчики постоянно (несколько раз в день) сливают свой код в общую ветку (например, main или develop).
Каждый раз, когда вы делаете git push, специальный сервер (GitLab CI, GitHub Actions, Jenkins) автоматически:

1. Скачивает ваш свежий код.
2. Собирает проект (mvn clean compile).
3. Запускает все Unit и Integration тесты.

Если хоть один тест упал - сборка помечается красным крестиком (Build Failed). Код не пройдет дальше.
Итог: Ваша главная ветка в Git всегда находится в рабочем состоянии.

📦 2. CD (Continuous Delivery & Deployment)

Здесь две буквы "D", и они немного отличаются:

🔴Continuous Delivery (Доставка): Код автоматически собирается в готовый артефакт (например, Docker-образ) и кладется в хранилище. Нажать кнопку "Опубликовать на Production" должен человек (например, тимлид).

🔴Continuous Deployment (Развертывание): Полная автоматизация. Прошли тесты? Собрался образ? Он сразу же автоматически загружается на боевой сервер и заменяет старую версию. (Так делает Amazon, выкатывая обновления тысячи раз в день).

⚙️ Анатомия Пайплайна (Pipeline)

Пайплайн - это скрипт, состоящий из шагов (Stages), которые выполняются строго друг за другом. Упал предыдущий - следующий не запустится.

Типичный пайплайн для Spring Boot + Docker:

1. Lint (Проверка стиля кода, нет ли неиспользуемых импортов).
2. Test (Запуск JUnit тестов).
3. Build (Сборка `app.jar`).
4. Dockerize (Сборка Docker-образа и отправка его в Docker Registry).
5. Deploy (Команда серверу: "Скачай новый образ и перезапустись").

💻 Как это выглядит в коде? (GitHub Actions)

Вам не нужно кликать мышкой в интерфейсах. Пайплайн описывается кодом (YAML) и лежит прямо в вашем репозитории (подход Infrastructure as Code).

Вот пример простого .github/workflows/build.yml для Java-проекта:

name: Spring Boot CI/CD

on:
  push:
    branches: [ "main" ] # Запускать только при пуше в main

jobs:
  build-and-test:
    runs-on: ubuntu-latest # Выделяем виртуальную машину Linux
    
    steps:
    - uses: actions/checkout@v3 # 1. Скачиваем код из Git
    
    - name: Установка Java 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
        
    - name: Сборка и Тесты (Maven) # 2. Запускаем тесты и сборку
      run: ./mvnw clean package
      
    # Дальше могут быть шаги для сборки Docker и деплоя...

Стоит вам сделать git push, и GitHub сам поднимет сервер, выполнит эти команды и пришлет вам письмо, если что-то сломалось.

🆚 Что выбрать?

🔴Jenkins: "Дед" в мире CI/CD. Мощный, гибкий, но сложный в настройке (нужно поднимать свой сервер). Написан на Java.

🔴GitLab CI: Стандарт индустрии корпоративного сектора. Очень удобен, так как встроен прямо в репозиторий кода.

🔴GitHub Actions: Современный, быстрый, идеален для Open Source и проектов, уже живущих в GitHub.

🔥 Итог

CI/CD убивает фактор "человеческой ошибки". Вы перестаете бояться релизов. Деплой новой фичи превращается из стрессового события в пятницу вечером в скучную рутину: сделал пуш подождал 5 минут фича на проде.

#DevOps #CICD #Java #SpringBoot #GitHubActions

📲 Мы в MAX

👉@BookJava