Между тем у этой задачи есть три принципиально разных уровня решения, и выбор уровня определяется не языком, а требованиями к задержке. Разбираем все три: блокирующую очередь на Java, каналы и горутины в Go и очередь без блокировок на Rust.

Producer-Consumer — это схема, в которой производители и потребители работают независимо, обмениваясь данными через общий буфер конечной ёмкости. Ёмкость здесь работает главным механизмом защиты: именно она не даёт быстрым производителям завалить медленных потребителей.

Ручная координация через wait() и notifyAll() в блоках синхронизации даёт гонки и ложные пробуждения, а активное ожидание в цикле впустую жжёт процессор.

Готовая блокирующая очередь решает задачу целиком: при переполнении она сама останавливает производителя, обеспечивая обратное давление вместо переполнения памяти.

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

Три гарантии прогресса различаются строго: obstruction-free требует отсутствия помех, lock-free гарантирует прогресс системы в целом, wait-free — завершение каждой операции за ограниченное число шагов.

Отсутствие блокировок и использование атомарных операций сами по себе не дают wait-free: цикл повторных попыток без верхней границы — это lock-free, как бы его ни называли в описании библиотеки.

Уровень первый: блокирующая очередь Producer-Consumer

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

• Писать собственную логику блокировок через wait() и notifyAll() внутри синхронизированных блоков. Это приносит тонкие гонки и баги ложного пробуждения, когда поток просыпается без всякого уведомления.
• Крутить активное ожидание в бесконечном цикле поверх коллекции, не рассчитанной на многопоточность. Процессор загружен постоянной проверкой размера очереди, а корректности всё равно нет.
• Не предусмотреть обратного давления. Когда производители быстрее потребителей, буфер растёт, пока приложение не упрётся в нехватку памяти.

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

В Java всё это уже реализовано в стандартной библиотеке:

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

Уровень второй: передача сообщений вместо общей памяти

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

Ключевое слово go перед вызовом запускает функцию конкурентно. Правда, у примера выше есть подвох: когда main завершается, программа выходит целиком, и горутина может не успеть отработать. Дожидаться её нужно явно:

Где здесь, собственно, очередь

Горутины сами по себе задачу производителя и потребителя не решают: WaitGroup лишь дожидается завершения, буфера и обратного давления в нём нет. Роль ограниченной очереди в Go играет буферизированный канал, и это прямой аналог кухонной раздачи из предыдущего раздела:

Поведение совпадает с блокирующей очередью один в один: отправка встаёт при переполнении, приём встаёт на пустом канале. Разница в акценте. В Java вы защищаете общий буфер, в Go передаёте значение из одной горутины в другую, и владение данными переходит вместе с ним.

Почему это не просто потоки с коротким именем

Горутина не является потоком операционной системы. Это лёгкая единица конкурентного исполнения, которой управляет рантайм языка: он раскладывает горутины по небольшому набору системных потоков сам. Отсюда и практическое следствие — можно оперировать очень большим числом конкурентных задач, не создавая и не сопровождая отдельный системный поток под каждую.

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

Уровень третий: очередь без блокировок

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

Три гарантии прогресса

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

Lock-free. Гарантирует прогресс системы в целом: даже если один поток застрял, какой-то другой обязательно завершит свою операцию. Отдельный поток при этом может голодать сколь угодно долго, но система не встаёт целиком.

Wait-free. Каждая операция завершается за ограниченное число шагов независимо от того, что делают остальные потоки. Ключевая формулировка здесь именно «ограниченное число шагов», а не «обычно быстро», «не использует блокировок» или «работает на атомарных операциях». Это формальное свойство, а не характеристика скорости.

Два неравенства, которые стоит запомнить:
Отсутствие блокировок не равно wait-free. Использование атомарных операций тоже не равно wait-free.

Почему мьютекса недостаточно

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

Атомарность и упорядочивание — разные вещи

Процессор гарантирует, что атомарная операция неделима. Этого мало: нужно ещё, чтобы потребитель увидел записи, сделанные производителем до публикации флага. За это отвечает модель упорядочивания памяти.

Пара «освобождение и захват» создаёт отношение синхронизации: если потребитель увидел освобождающую запись, он гарантированно видит и все предшествовавшие ей записи. Это одна из центральных идей программирования без блокировок, и именно её упускают, заменяя мьютекс на атомарную операцию без всего остального.

Кольцевой буфер и номера последовательности

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

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

Тип UnsafeCell здесь означает ровно то, что написано на упаковке: обращаться к значению можно только из блока unsafe, компилятор проверку прекращает, и инвариант «в конкретный момент со слотом работает один поток» держится на номере последовательности, а не на системе типов.

Тип MaybeUninit здесь не для красоты: при ёмкости в 1024 элемента нужны 1024 места под значения, а не 1024 сконструированных объекта. Производитель получает уникальную позицию одним атомарным инкрементом, и никакого соревнования за неё не возникает:

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

Где заканчивается честность в названиях

Неприятная правда, которую стоит знать до выбора библиотеки: многое из того, что продаётся как wait-free очередь, на деле является lock-free. Причина в устройстве ядра алгоритма:

Операция обычно завершается быстро, но верхней границы на число неудачных попыток здесь нет, а именно она и определяет wait-free. И да, ровно такой цикл вы только что видели в нашей собственной очереди: строго говоря, на этом шаге она тоже lock-free, а не wait-free, и автор исходного разбора это прямо оговаривает. Строгая реализация требует ограниченной стратегии резервирования или механизма помощи: когда поток B встречает незавершённую операцию потока A, он не ждёт возвращения A, а доводит его операцию до конца сам. Так прогресс перестаёт зависеть от того, что планировщик сделал с конкретным потоком.

Какой уровень выбрать

Правило простое и почти всегда работает от обратного.

• Блокирующая очередь из стандартной библиотеки закрывает подавляющее большинство задач. Начинайте с неё и не пишите координацию потоков вручную.
• Модель с передачей сообщений выигрывает, когда конкурентных задач много, а связи между ними хочется описать явно, а не через набор общих структур под блокировками.
• Алгоритмы без блокировок берутся, когда есть измеренное требование к задержке, которое блокировка нарушает: не «хочется быстрее», а конкретная цифра в бюджете. И в продакшене их берут готовыми из библиотек вроде crossbeam, а разбирают по косточкам ради понимания механики.

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

Что забрать с собой

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

Материалы разбора: задача о ресторанной кухне на Java, введение в горутины и модель конкурентности Go и построение wait-free очереди на Rust.

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

LangChain4j — это Java-фреймворк для приложений на базе больших языковых моделей, аналог LangChain из мира Python. Его модуль langchain4j-agentic позволяет описывать агентные системы декларативно: прямо в Java-интерфейсах, через аннотации. Эксперимент Дюбуа и Фуско проверял две вещи сразу: достаточно ли «читаем» API фреймворка, чтобы модель использовала его без подсказок, и как ведут себя два главных паттерна агентных систем — supervisor и workflow — на одной и той же задаче отладки кода.

ИИ-ассистент по документации LangChain4j сам спроектировал и реализовал мультиагентного кодера — клона самого себя: супервизор плюс четыре субагента.

Собранная система починила все баги в тестовом классе Calculator: 11 тестов из 11 зелёные, сборка Maven успешна.

Модель gpt-4o провалила задачу, уйдя в цикл вызовов инструментов (сработал лимит в 100 вызовов), а более свежая gpt-5-mini справилась.

Жёсткий workflow-паттерн выполнил ту же задачу за 2 минуты против 6+ минут у supervisor-паттерна: автономная координация через LLM стоит дорого.

Новый интерфейс MonitoredAgent (langchain4j-agentic 1.12.2-beta22) показывает топологию системы и трейс вызовов агентов.

Вайбкодинг агента: промпт, который собрал агента

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

Через несколько минут размышлений ассистент выбрал supervisor-паттерн: главный агент-координатор, который сам решает, какого субагента вызвать и с какими аргументами. Архитектура получилась такой — обратите внимание, вся система описывается одним аннотированным интерфейсом:

Ассистент спроектировал и написал четырёх субагентов, а также инструменты для каждого из них. Если вы пользовались «взрослыми» код-ассистентами, схема покажется знакомой — это ровно те четыре роли, которые такие инструменты исполняют внутри:

• ExplorerAgent — изучает кодовую базу (получил инструмент обхода файловой системы);
• PlannerAgent — составляет план изменений;
• ImplementerAgent — пишет и правит код (получил редактор кода);
• ExecutorAgent — компилирует и запускает результат.

Отдельно интересно, что модель воспроизвела собственное внутреннее устройство «сходу», без объяснений: похоже, современные LLM действительно имеют высокоуровневое представление о том, как устроены они сами, и умеют переводить его в рабочий дизайн агентной системы.

Проверка боем: агент чинит баги в Calculator

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

• в методе sum() выход за границу списка: цикл до i <= size();
• в average() целочисленное деление вместо дробного;
• в max() стартовое значение 0 — ломается на списке из отрицательных чисел;
• в factorial() цикл до i < n — факториал недосчитан на один множитель.

Дальше ассистент сгенерировал интеграционный тест: скопировать проект с багами во временную папку и натравить на него агентного кодера:

Первая попытка: gpt-4o уходит в цикл

Первый прогон делали на gpt-4o — это модель по умолчанию в LangChain4j, и она поддерживает вызов инструментов. Результат: через несколько минут система упала с ошибкой. LLM застряла в цикле вызовов инструментов, и фреймворк прервал её на лимите в 100 последовательных вызовов:

Полезно знать: лимит в 100 вызовов инструментов подряд — дефолт LangChain4j. Он настраивается методом maxToolCallingRoundTrips() в AiServices, но дефолт вполне разумный: здоровому агенту столько вызовов не нужно, а беззащитный цикл сожжёт бюджет на токены.

Вторая попытка: gpt-5-mini чинит всё

Авторы уже сталкивались с таким поведением у старых моделей, поэтому просто заменили модель на gpt-5-mini — и тот же самый агентный дизайн отработал чисто. Система нашла все четыре бага, переписала методы (for-each вместо индексного цикла, приведение к (double) в среднем, инициализация максимума первым элементом, включительная граница в факториале) и отчиталась:

• mvn package — BUILD SUCCESS;
• mvn test — 11 тестов, 0 падений, 0 ошибок;
• финальный вердикт агента: «All tests in CalculatorTest.java pass (11/11)».

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

Смотрим под капот: MonitoredAgent

Когда один ИИ собирает другого ИИ, вопрос «а что там внутри происходит» перестаёт быть риторическим. В версии 1.12.2-beta22 модуля langchain4j-agentic появился интерфейс MonitoredAgent: достаточно унаследовать от него корневой интерфейс системы, и фреймворк сам зарегистрирует монитор — можно распечатать отчёт о вызовах агентов и топологию системы:

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

Supervisor против workflow: автономия или скорость

Автономность супервизора имеет скрытую цену: каждый шаг координации — это дополнительный вызов LLM, который «придумывает», кого вызвать дальше и с какими аргументами. Чтобы измерить эту цену, авторы попросили ассистента перепроектировать систему в детерминированном виде — только на workflow-паттернах LangChain4j.

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

Цикл исполнения устроен как связка «исполнитель → оценщик → рефактор»: итерации продолжаются, пока оценка качества не достигнет 0.8, но не дольше 5 итераций — защита от бесконечного сжигания токенов:

Та же задача с багами в Calculator — тот же результат: все тесты зелёные, финальная оценка качества 0.8. Но по времени картина разительно другая: две минуты у workflow против более чем шести у supervisor. Втрое быстрее — при большем числе агентов в системе. Вся разница — устранение координационных вызовов LLM: в workflow каждый следующий шаг известен заранее и «мнения» модели на этот счёт не требуется.

Это не означает, что supervisor не нужен. Выбор зависит от природы задачи:

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

Что это значит на практике

Эксперимент Дюбуа и Фуско красиво подтверждает рекомендации, которые Anthropic сформулировала в гайде по эффективным агентам: начинайте с простейшего детерминированного пайплайна и добавляйте автономность только там, где без неё никак. Каждый «свободный» шаг координации — это лишний вызов модели: и по деньгам, и по латентности, и по шансу уйти в цикл. Замер в статье (3x на одной тривиальной задаче) — хорошая иллюстрация того, во что это превращается в проде.

Второй урок — про «вайбкодинг» агентных систем. То, что LLM собрала рабочую мультиагентную систему по документации, говорит больше о качестве API LangChain4j, чем о магии моделей: аннотации @SupervisorAgent, @SequenceAgent и @LoopAgent читаются как обычный декларативный дизайн, и модели это по зубам. Для Java-команд это практический повод присмотреться к фреймворку: порог входа в агентные системы здесь заметно ниже, чем кажется.

И третье: отлаживайте агентов как распределённую систему. Трейс вызовов и топология из MonitoredAgent — это тот же распределённый трейсинг, к которому вы привыкли в микросервисах, только спаны здесь — вызовы LLM. Без него вы не узнаете, что система половину бюджета потратила на «размышления» супервизора.

Выводы

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

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

Источники: оригинальная статья — The Self-Building Agent: A LangChain4j Experiment (InfoQ); код эксперимента — репозиторий langchain4j-agentic-coder; документация — Agentic Systems в LangChain4j.

Если строите агентные системы на Java — возьмите репозиторий, прогоните тест на своей модели и сравните supervisor с workflow на своих задачах. Цифры могут удивить.

Потом проект вырос, в команду пришли ещё люди, и стало понятно: этот красивый монолит пора разделять.

Это было взвешенное решение. В какой-то момент общий фреймворк превратился в поле мерж-конфликтов, где ты уже не тесты пишешь, а разбираешься, кто чей page object сломал и почему Android отвалился после правки для iOS.

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

Как говорил один мой коллега, перефразируя классическое “вам шашечки или ехать”:

Ты сюда страдать пришёл или тесты писать?

После этого решение разделить Android и iOS на два проекта стало очевидным.

Сейчас у меня два отдельных проекта: mb-android-tests и mb-ios-tests. И знаете что? Это лучшее архитектурное решение за всё время на этом проекте. Серьёзно.

Контекст: что за проект и почему это важно

Финтех. Нативное приложение. Отдельные кодовые базы, Kotlin на Android, Swift на iOS. И UI там не «три кнопки и список», формы с десятками полей, кастомные контролы, WebView-вставки, платежи, валютные операции, бюджетные переводы. Ну вы поняли.

Стек: Java 21, TestNG, Appium 2.x, Selenide, Allure, Maven. CI на GitLab, крутится на Mac Mini. 5 Android-эмуляторов, 4 iOS-симулятора, 9 Appium-серверов — по одному на устройство.

Но это сейчас. А начиналось всё с одного жирного монолита.

Старый проект: 8 модулей и конструктор-монстр

Идея была «как в книжке»: один репозиторий, модульная структура, переиспользование. DRY во все поля. Ну а чё, красиво же.

8 модулей. Один mvn clean install. Все зависят от mobile-automation-framework, в котором живут DriverFactory, BaseTest, общие Page Objects и слой Steps.

А DriverFactory принимал 11 параметров. Одиннадцать, Карл.

Половина нужна только Android, другая только iOS. Но метод один. Потому что так более по программистцки, как написано в каждой второй статье про архитектуру автотестов.

Когда я работал один, было норм. Ты сам знаешь, от куда что идет.

А потом пришли люди.

Почему с людьми всё навернулось

Мерж-конфликты каждый божий день

Вот конкретная ситуация. Один человек правит LoginPage в общем фреймворке, добавляет метод для iOS, меняет локатор. Второй в тот же момент рефакторит этот же LoginPage под новую версию Android-приложения.

Мерж. Конфликт.

И тут начинается самое весёлое: какой локатор правильный? Для Android? Для iOS? Для обоих? Кто будет разбираться? Тот, кто мёрджит? А он вообще контекст понимает?

Это не единичный случай. Это было каждый день. Потому что mobile-automation-framework получился общим модулем, от которого зависят все. И все туда лезут. Постоянно.

Обновление одной библиотеки = блокировка всех

Решил обновить java-client с 7.x на 8.x. Нормальное желание — API поменялся, MobileElement удалили, capabilities переехали на типизированные Options.

Вот что произошло в реальности:

1. Меняю версию в parent pom.xml
2. MobileElement удалён → compilation error в DriverFactory, во всех DriverManager’ах
3. DesiredCapabilities → UiAutomator2Options / XCUITestOptions → переписываю все менеджеры
4. selenide-appium 1.x несовместим с java-client 8.x → обновляю до 2.x
5. selenide-appium 2.x требует Selenide 6.x → обновляю Selenide
6. Selenide 6.x ломает API page objects → переписываю page objects во всех модулях
7. А Selenide 6.x ещё и Java 8 не поддерживает → обновляю Java

Одна библиотека.

Задача «обновить одну библиотеку» превратилась в 50+ файлов, 4-5 каскадных обновлений, 2-3 недели работы. И всё это время develop нестабилен. Все заблокированы. Тесты не запускаются.

Две недели.

Из-за одной строчки в pom.xml.

Page Objects с if/else — это два page object в одном файле

Общие Page Objects звучат красиво на бумаге: пишем один раз, используем для обеих платформ. А на практике…

Это не page object. Это два page objects, запиханных в один файл через if/else. И так в каждом методе.

А сверху ещё слой Steps. Обёртки над page objects «для читаемости». И в steps тоже if (platform), потому что логика взаимодействия разная. На Android ты скроллишь через UiScrollable семантически, «прокрути до элемента с текстом X». На iOS координатами, «двигай палец из точки A в точку B». Один метод в steps, а внутри два разных мира.

В какой-то момент ловишь себя на мысли: я же не тесты пишу. Я подгоняю pages и steps под две платформы, чтобы фреймворк не развалился. Это уже не автоматизация тестирования, это поддержка фреймворка ради поддержки фреймворка.

Каждый работает в своём темпе и все друг другу мешают

У одного задача покрыть тестами новый экран на Android. У второго пофиксить падающие тесты на iOS. У третьего добавить тестовые данные.

Все трое лезут в mobile-automation-framework. Все трое меняют pom.xml, BaseTest, page objects. Каждый в своей ветке.

А потом мёрдж.

Технические причины, которые добили окончательно

Ладно, человеческий фактор. Но были и чисто технические штуки, которые окончательно убедили меня, что кроссплатформа тут бессмысленна.

Локаторы: работай с тем, что дают

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

В теории есть AccessibilityID единый локатор для обеих платформ. Звучит хорошо. А на практике? Попробуй попросить мобильных разработчиков расставить одинаковые accessibility-идентификаторы на сотнях экранов. На Kotlin и Swift. Одновременно. Они тебя вежливо пошлют, но скорее всего не вежливо. И будут правы, у них свои спринты, свои дедлайны, и твои автотесты в их приоритетах где-то между «поправить тень у кнопки» и «никогда».

Так что реальный выбор:

XPath - работает, но на iOS может быть тормозным. На Android через UiSelector быстро, нативно, надёжно. На iOS через NSPredicate тоже ок. А «универсальные» XPath типа //*[@text='Войти' or @label='Войти'] это путь к боли, потому что Page Source на двух платформах два совершенно разных XML-дерева.

Координаты - костыль? Да. Но иногда единственный вариант. Когда у тебя кастомный контрол без accessibility-свойств, а разработчик говорит «это декоративный элемент», ты либо тыкаешь по координатам, либо не тестируешь.

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

Суть в том, что «напиши один локатор и работай на двух платформах» это миф. Page Source на Android это android.widget.Button с resource-id. На iOS XCUIElementTypeButton с name и label. Разные типы элементов, разные атрибуты, разная глубина вложенности. Разные миры.

StaleElementReferenceException — «подарок» от iOS

Android рендерит UI через Choreographer синхронно с VSYNC. Элемент появился → стабилен → кликаем.

iOS рендерит через CoreAnimation с неявными анимациями. Элемент есть в дереве, но ещё анимируется. Формально кликабелен, фактически хрен.

Стандартный WebDriverWait с elementToBeClickable это не ловит. Элемент «кликабелен» по мнению Appium wait завершается. А потом click() падает, потому что DOM изменился между вызовами.

На Android этой проблемы нет вообще. Тот же тест, тот же wait, тот же код зелёный на Android, красный на iOS. Один и тот же метод, два разных результата. И это не баг это фундаментальное различие платформ.

Кастомные wait-стратегии для iOS отличаются от Android принципиально. Пихать их в один фреймворк строить leaky abstraction, которая протекает на каждом шаге.

Жесты — два разных мира

Свайп вниз на Android:

Свайп вниз на iOS:

Чувствуете разницу? И даже длительность свайпа важна: на Android 200мс это нормальный скролл. На iOS 200мс это fling, и элемент улетает за экран.

«Кроссплатформенная» обёртка для скролла функция на 40 строк с двумя ветками if (platform), внутри каждой и ещё if для performSwipeDown() vs performSwipeUp(). На 50+ экранах таких обёрток, которых десятки.

И каждая место для бага.

Решение: разделяй и властвуй

Решение было болезненным. Я реально откладывал, потому что казалось, что это шаг назад. Дублирование кода, нарушение DRY, всё такое. Мозг сопротивлялся.

А потом я просто сел и разделил.

Никаких общих page objects. Никаких общих steps. Никакого общего DriverFactory с 11 параметрами. Каждый проект со своим pom.xml, свои зависимости, свой BaseTest, свои локаторы.

Что осталось общего: подход к структуре (Maven + TestNG + Allure), CI-шаблоны, принципы организации. Но не код. Код полностью раздельный.

Что поменялось на практике

В Android-проекте DriverManager типизирован под AndroidDriver. В iOS под IOSDriver. Не AppiumDriver<MobileElement> с кастами и проверками, а конкретный тип для конкретной платформы. IDE подсказывает только релевантные методы. Компилятор ловит ошибки на этапе сборки, а не в рантайме.

BaseTest принимает ровно те параметры, которые нужны. Android: deviceName, platformVersion, udid, appPackage, appActivity, systemPort, serverUrl, appPath — 8 штук, все релевантные. iOS: deviceName, platformVersion, udid, appPath, serverUrl, wdaLocalPort — 6. Никаких @Optional("systemPort") со строкой “systemPort” в качестве дефолта.

А мерж-конфликты?

Когда один человек работает в mb-android-tests, а второй в mb-ios-tests то они вообще не пересекаются. Разные репозитории. Конфликт невозможен физически.

Обновление java-client в Android-проекте не затрагивает iOS. Хочешь обновить, обновляй. iOS продолжает работать на старой версии.

Добавить новый параметр для iOS? Меняешь BaseTest и testng.xml в iOS-проекте. Android даже не узнает.

Это прям кайф.

А как же дублирование кода?!

Конечно, конечно. Первый вопрос, который задают: «Но ведь ты пишешь тесты дважды!»

Нет.

Я пишу каждый тест один раз и без костылей. Без if (platform) в каждом методе. Да, для одного и того же экрана есть два теста, один для Android, один для iOS. Но каждый из них чистый, понятный, заточенный под свою платформу.

В старом варианте я тоже «писал один раз», а потом тратил столько же времени на поддержку if/else, мерж-конфликты и каскадные обновления. «Экономия» на создании оборачивалась переплатой на поддержке. С процентами.

Когда кроссплатформа всё-таки ок

Я не топлю за то, что кроссплатформенный фреймворк абсолютное зло. Есть ситуации, где он работает:

Приложение простое, пара экранов, стандартные контролы, минимум кастомного UI.

UI реально идентичен на обеих платформах. Бывает, наверное.

Команда из одиного человека. Сам пишешь, сам мёрджишь, сам разруливаешь. Голова справляется.

Минимум жестов. Нет сложных свайпов, drag-and-drop, pinch-to-zoom.

Если у тебя финтех, банк, enterprise-приложение с сотнями экранов, кастомными контролами и тремя+ QA, то два проекта дешевле. Не в строках кода, а во времени. В нервах. В часах, потраченных на мерж-конфликты вместо написания тестов.

Итого

Два проекта это не шаг назад и не двойная работа. Со стороны может выглядеть именно так, но на практике ты пишешь каждый тест один раз, под конкретную платформу, без лишних компромиссов. Потом поддерживаешь его без постоянных мерж конфликтов, каскадных обновлений и if/else в каждом втором методе.

Кроссплатформенный фреймворк на Appium для сложного нативного приложения часто оказывается иллюзией экономии.

В следующей статье покажу, как у нас устроена инфраструктура для 9 параллельных устройств на одном Mac Mini: порты, bash скрипты, Appium серверы и workaround’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

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

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

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

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

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

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

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

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

Во-вторых, команда не написала характеристических тестов. Поведение «как есть» нигде не было зафиксировано, и расхождения находились только в продакшене после переключения.

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

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

Например, в системе расчета налогов может быть правило: для контрактов, заключенных до 2018 года, НДС округляется в меньшую сторону до целого рубля, а для всех остальных — по математическим правилам. Новый разработчик может решить, что это ошибка, и «исправить» округление. Но потом выяснится, что часть крупных клиентов держит это поведение в своих сверках, а смена правила приведет к расхождениям в актах и претензиям.

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

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

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

Важно, что фича-флаг — это не просто if в коде. Для серьезной миграции нужны правила: кто может включать флаг, как быстро его можно отключить, какие метрики отслеживаются, когда флаг должен быть удален.

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

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

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

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

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

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

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

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

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

Откатить миграцию, в которой ещё не было записи в БД, легко: достаточно переключить фича-флаг, и трафик снова идёт через старую реализацию. Откатить миграцию, в которой новая система уже неделю писала данные в новые таблицы, — отдельный, гораздо более тяжёлый разговор.

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

Базовое правило: ни один шаг миграции не должен уходить в продакшен, если у команды нет письменного ответа на вопрос «как мы откатываемся в случае проблемы». Иначе при инциденте откатываться будут на ходу — и не факт, что успешно.

Пример: как тот же сервис мигрировали со второй попытки

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

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

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

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

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

Четвертая ошибка — не договариваться с бизнесом. Модернизация не должна быть невидимой «инженерной активностью в стол». Её нужно встраивать в roadmap, объяснять эффект и договариваться о приоритетах. Если бизнес не понимает, зачем команда тратит время на миграцию, работа будет постоянно проигрывать новым фичам.

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

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

Компромиссы, к которым нужно быть готовыми

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

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

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

Когда Strangler Fig особенно оправдан

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

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

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

Когда модернизацию лучше не делать

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

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

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

Простой тест: если на вопрос «какой бизнес-сценарий мы откроем после миграции» нет внятного ответа — модернизацию имеет смысл отложить и заняться чем-то другим.

Что получает команда

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

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

Потому что цель модернизации — не написать красивую новую систему. Цель — сделать так, чтобы продукт продолжал развиваться, команда могла безопасно вносить изменения, а пользователи не становились участниками инженерного эксперимента.

Agent2Agent — это протокол, управляемый Linux Foundation (изначально представленный Google), который позволяет агентам на разных фреймворках и языках находить друг друга, делегировать задачи и обмениваться результатами. Для Java-экосистемы выпуск SDK версии 1.0.0 означает переход от экспериментальных сборок к инструменту, готовому к промышленной эксплуатации.

Релиз 1.0.0 появился на прошлой неделе, как сообщает InfoQ в очередном выпуске Java News Roundup. В него вошли исправления ошибок, обновление зависимостей и несколько новых возможностей: интеграционный тестовый набор на базе Quarkus для проверки совместимости разных SDK, а также расширение интерфейса A2AHttpResponse и класса A2AClientHTTPError для доступа к HTTP-заголовкам ответов.

• A2A Java SDK 1.0.0 вышел в GA — первая стабильная версия для Java.
• Реализует протокол Agent2Agent для взаимодействия ИИ-агентов.
• Появился интеграционный тестовый набор на базе Quarkus.
• Доступен в Maven Central: org.a2aproject.sdk.
• Параллельно вышел A2A Jakarta 1.0.0.CR1 для Jakarta EE серверов.

Что вошло в релиз A2A Java SDK 1.0.0

• Новый интеграционный тестовый набор (ITK) на базе Quarkus для проверки кросс-SDK совместимости.
• Возможность получать HTTP-заголовки ответов через интерфейс A2AHttpResponse и класс A2AClientHTTPError.
• Исправления ошибок и обновление зависимостей.
• Готовность к использованию в production вместе с A2A Protocol Specification 1.0.

I am pleased to announce the release of A2A Java SDK 1.0.0.Final — our first GA release. The A2A Java SDK is the official Java implementation of the Agent2Agent (A2A) Protocol, an open standard that enables AI agents to communicate and collaborate regardless of underlying framework, language, or vendor.

Параллельно команда выпустила первый релиз-кандидат A2A Jakarta 1.0.0.CR1. Эта интеграция помогает запускать A2A-агентов внутри Jakarta EE серверов, таких как WildFly. В CR1 переименованы пакеты и артефакты, обновлён набор TCK для работы с A2A Java SDK 1.0.0 и настроен запуск CI на Windows.

Зачем это Java-разработчикам

SDK позволяет строить агентные приложения на Java без привязки к Python-стеку. Агенты могут общаться с агентами на Google ADK, LangGraph, CrewAI и других фреймворках через единый протокол. Это особенно важно для команд, где основная инфраструктура уже написана на Java. Рядом с A2A развивается протокол MCP: если MCP соединяет агента с инструментами, то A2A — агента с агентом.

A2A Java SDK 1.0.0 делает Java полноценной платформой для агентных приложений: теперь можно подключить SDK из Maven Central и начать строить агентов, которые работают в одной экосистеме с Python- и TypeScript-решениями.

Источник: InfoQ — Java News Roundup: A2A Java SDK 1.0, Jakarta EE 12, JNoSQL, GraalVM, Micrometer, OpenXava, Gradle.

Попытка №1. Путь в лоб: Классы и интерфейсы

Самый очевидный способ - создать родительский класс с переменными, а языки сделать его наследниками. Но это просто… фиаско. Даже если не писать from/toJson, процесс выглядит так:

1. Объявил переменную в родителе.
2. Прописал её в конструкторе.
3. Повторил то же самое для всех дочерних классов (всех языков).

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

Попытка №2. Стандарт (ARB/JSON)

Я поплевался, но решил попробовать - «стандарт» всё-таки. Мало ли, может чего поменялось за годы. Вроде всё завелось, но сам процесс… это боль. Бегать по разным файлам, чтобы добавить одну строчку - так себе удовольствие.

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

Попытка №3. Таблицы и костыли

Подумал: «Окей, почему бы не подтянуть старый добрый CSV или вообще закинуть всё в табличку?». И тут официальный пакет локализации сказал: «Извини, мужик, тут наши полномочия всё».

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

1. Добавляю строку в таблицу.
2. Запускаю генератор.
3. Он лепит «родительский» файл.
4. После Freezed генерит toJson, fromJson…

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

Красный флаг для программиста

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

Что происходит на практике? Когда ты пишешь код и тебе нужно добавить одну несчастную строку, тебе лень (читать: нехочется выходить из потока творения) запускать весь этот цикл с генерацией. Ты просто её хардкодишь в надежде «потом скопом всё добавлю одним махом». А «потом» наступает тогда, когда уже весь проект завален хардкодом, и вычищать его - то еще удовольствие. Даже нейросетки с такими запросами помогают не с первого раза, и с сомнительной эффективностью.

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

Эволюция лени: почему Enum победил интерфейсы

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

Моя философия проста: строку захардкодить - моментально. Добавление даже одной строки в другом файле требует доп. действий. НО, если действий минимум, то кодер поймет, что выигрыш во времени сейчас мизерный против больших потерь в будущем, и исправно добавит строку в правильное место. Этого не произойдет, если для добавления строки нужно «отчитаться» в десяти местах.

Попытка №4. Рекорды (Records)

Присматривался к рекордам. С ними удобно: не нужно писать конструкторы. Но есть подвох: как только ты добавил переменную в один язык, компилятор тут же сходит с ума и требует добавить её во все остальные прямо сейчас. Никакой гибкости и возможности оставить «на потом».

Идеальный костыль: Enum

В итоге я пришел к самому, казалось бы, «неправильному» способу, который оказался идеальным. Enum. Само название намекает на перечисления и цифры, но оказалось, что хранить в нем буквы и целые фразы - это лучший путь для локализации.

Знаете, мне моё решение так понравилось, что я пошел к нейросетям и проверил его со всех сторон. Все модели остались в полном восторге. Под это дело я даже подготовил монументальную «нейро-статью» на полтора часа внимательного чтения, со всеми графиками, бенчмарками и анализом производительности.

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

А здесь мы будем говорить по делу.

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

Реализация

Принцип разделения:

• enum Strings → типизированный контракт (что существует).
• translator → источник данных (откуда берётся текст).

Структура файлов - минимальная. Никаких внешних зависимостей:

Ядро - strings.dart

Весь контракт локализации в одном enum. Два режима - хардкод switch и серверный кеш - за одним и тем же

. Даже сообщения об ошибках локализации — сами локализованы:

Список языков - languages_enum.dart

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

Хотите грузить с сервера? Одна строка + loader. И

- тоже одна строка, потому что

уже является registry:

Переводчик - i18n/russian.dart

Как это выглядит в жизни (и почему я перестал хардкодить) Я намеренно не привожу здесь код оберток виджетов или конкретных стейт-менеджеров. Всё это - чистая «вкусовщина». Для работы системы нужен лишь элементарный вещатель событий (Notifier), повешенный на метод смены языка.

Но главное - это мой ежедневный флоу. Сейчас, чтобы добавить строку в UI, я просто вызываю нужный мне ключ: Strings.someKey(). Без контекста, везде.

А если ключа еще нет? Я тупо иду в Strings и добавляю одну строчку в Enum. Всё.

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

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

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

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

В нашей системе две базы данных:

- Остатки по счетам - текущий остаток по каждому счёту

- Остатки по клиентам - агрегированный баланс клиента по всем его счетам.

При каждом изменении остатка по счёту нужно обновить Остатки по счетам и уведомить Остатки по клиентам через Kafka. Логика простая. Но в какой-то момент клиент звонит в поддержку: его баланс в приложении не совпадает с реальным. Вы смотрите в обе базы — данные разошлись. Когда именно это произошло — непонятно.

Причина почти всегда одна и та же:

Транзакция закоммичена, событие не ушло. Базы разошлись. Никто не узнал.

Почему очевидные решения не работают

Первая реакция разработчика — обернуть отправку в try-catch и повторить при ошибке:

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

Вторая идея — отправить событие до коммита:

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

Третья идея — двухфазный коммит (2PC). Это протокол, который координирует атомарный коммит сразу в нескольких системах. Звучит как решение, но на практике Kafka его не поддерживает в классическом смысле, а реализации 2PC с брокерами сообщений крайне сложны в эксплуатации и плохо переносят сбои координатора.

Все три пути упираются в одну проблему: **невозможно атомарно закоммитить транзакцию в базе и отправить сообщение в Kafka** — это две разные системы без общего менеджера транзакций.

Принцип решения

Раз нельзя сделать две операции атомарными, нужно свести их к одной. Именно это делает паттерн **Transactional Outbox**.

Вместо того чтобы отправлять событие в Kafka напрямую, мы записываем его в таблицу `outbox` — в той же базе, в той же транзакции, что и изменение остатка. Одна транзакция, одна база, полная атомарность за счёт ACID.

Доставкой события из `outbox` в Kafka занимается отдельный процесс — уже без транзакционных рисков, с возможностью повторных попыток.

Это и есть весь паттерн. Дальше — вопрос реализации.

Два способа реализации

Есть два принципиально разных подхода к тому, как читать `outbox` и доставлять события в Kafka. Выбор между ними определяет операционную сложность и задержку доставки.

Способ 1: Polling Relay

Фоновый воркер периодически опрашивает 'outbox' и отправляет неотправленные события в Kafka.

Структура таблицы outbox:

Бизнес-транзакция:

Relay-процесс:

При нескольких экземплярах ретранслятора важно, чтобы одно событие забирал только один из них. Используем `FOR UPDATE SKIP LOCKED`:

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

Способ 2: CDC через Debezium

CDC (Change Data Capture) — подход, при котором события читаются не опросом таблицы, а напрямую из журнала транзакций базы данных (WAL в PostgreSQL). [Debezium](https://debezium.io/) подключается к PostgreSQL как репликационный слот и стримит каждое изменение в `outbox` в Kafka в реальном времени.

Relay-процесс при этом не нужен вообще.

Бизнес-транзакция остаётся той же — пишем в `accounts` и `outbox` атомарно. Debezium сам следит за WAL и публикует новые записи в Kafka с минимальной задержкой.

Когда выбирать: нужна задержка доставки в миллисекунды, команда готова к Debezium + Kafka Connect в инфраструктуре.

Что выбрать для синхронизации остатков

Для большинства задач с остатками по счетам polling relay достаточен. CDC имеет смысл, если бизнес требует обновления клиентского баланса быстрее чем за секунду.

Получатель: защита от дублей

Оба способа доставляют события как минимум один раз — при повторных попытках одно событие может прийти дважды. На стороне Остатков по клиентам нужна защита.

Самый надёжный способ — inbox-таблица с уникальным constraint:

>Почему не `existsById` перед вставкой? При параллельной обработке два консюмера могут одновременно получить `false` и оба начать обработку. Уникальный constraint на уровне БД закрывает эту гонку.

Что сломается при небрежной реализации

Relay внутри API-сервиса. Если ретранслятор живёт в том же процессе, что и API, горизонтальное масштабирование до 10–30 реплик создаёт столько же потоков, опрашивающих `outbox`. База тратит CPU не на запросы, а на управление блокировками. Relay — отдельный деплоймент, который масштабируется по объёму событий, а не по HTTP-трафику.

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

Отсутствие мониторинга outbox. Outbox — скрытая очередь внутри базы. Если relay начнёт отставать, вы узнаете об этом от клиентов, а не от алертов. Следите за количеством и возрастом необработанных событий — это главные сигналы проблемы.

Итог

Проблема потери событий при синхронизации баз — не баг конкретной реализации. Это фундаментальное ограничение: нельзя атомарно закоммитить транзакцию в базе и отправить сообщение в Kafka.

Transactional Outbox обходит это ограничение, сводя две операции к одной: событие пишется в `outbox` в той же транзакции, что и основные данные. Дальше — дело техники: polling relay, если нужна простота, CDC, если нужна скорость.

Остатки по счетам и клиентам будут согласованы — даже если между сервисами что-то пойдёт не так.

Structured Concurrency появилась в JDK 19 как инкубатор и прошла два инкубаторных раунда и несколько preview, постепенно сближая модель многопоточности с принципами структурного программирования: подзадачи живут строго внутри своей области видимости, отмена распространяется надёжно, а иерархии потоков отображаются в инструментах наблюдаемости.

• FailedException заменён на ExecutionException: стандартные joiners теперь бросают ExecutionException вместо preview-специфичного FailedException — тот же тип, что и Future.get().
• Третий тип-параметр R_X: Joiner<T, R, R_X> выносит тип исключения join() в сигнатуру — контракт становится частью типа.
• Новый open-оверлоад: StructuredTaskScope.open(UnaryOperator<Configuration>) позволяет задать таймаут и имя без явной передачи Joiner.
• Ранние access-сборки JDK 27 доступны с флагом --enable-preview.
• Форма API, заложенная в preview 5, сохраняется — дизайн сходится к финализации.

FailedException уходит — приходит ExecutionException

Главное изменение preview 7: joiners Joiner.allSuccessfulOrThrow(), anySuccessfulOrThrow() и awaitAllSuccessfulOrThrow() теперь бросают java.util.concurrent.ExecutionException вместо preview-специфичного FailedException. Причина исключения доступна через getCause() — так же, как в Future.get() со времён Java 5.

Смена типа сокращает разрыв между классическим и структурированным кодом. Привычный паттерн catch-switch переносится напрямую:

Команды, которые использовали FailedException в preview 5–6, должны заменить этот тип на ExecutionException при переходе на JDK 27.

Третий тип-параметр: исключение становится частью типа

StructuredTaskScope и интерфейс Joiner получают третий тип-параметр R_X, описывающий тип исключения, которое может бросить join(). Старая сигнатура Joiner<T, R> становится Joiner<T, R, R_X>.

Для прикладного кода, который использует стандартные joiners через open(), компилятор выводит все три параметра автоматически — исходный код выглядит так же, как раньше. Разница принципиальна для авторов кастомных joiners: предложение throws теперь становится частью типа, а не деталью реализации. Вызывающий код получает точный checked-exception контракт на join().

Новый open-оверлоад: конфигурация без лишнего Joiner

До preview 7 установить таймаут или имя области при политике по умолчанию (ждать всех, завершить со сбоем при первом падении подзадачи) требовало передачи явного Joiner рядом с оператором конфигурации. Теперь появился перегруженный StructuredTaskScope.open(UnaryOperator<Configuration>), который принимает только оператор конфигурации:

Оверлоад принимает UnaryOperator<Configuration> — то же более строгое типирование, которое было введено в preview 6. Политика join по умолчанию (ждать успеха всех или провала хотя бы одной подзадачи) сохраняется.

Что осталось без изменений

Структурные гарантии API остаются прежними: подзадачи наследуют привязки ScopedValue (JEP 506), JSON thread dump продолжает отображать иерархии областей для инструментов профилирования, StructureViolationException по-прежнему срабатывает при использовании области вне try-with-resources или форке из чужого потока.

Одно изменение JEP 533, выходящее за рамки трёх основных: метод onTimeout() интерфейса Joiner удалён и заменён на timeout(). Новый метод либо возвращает результат, либо при тайм-ауте бросает исключение с CancelledByTimeoutException как причиной. Авторам кастомных Joiner-реализаций потребуется переименовать метод и скорректировать логику обработки тайм-аута.

Preview 7 не является редизайном. Форма API, заложенная в preview 5, сохраняется. Изменения сосредоточены на эргономике и типизации, а не на структуре. Сужающийся охват каждого preview — разумный индикатор того, что дизайн сходится. JEP 533 не указывает сроков финализации, но Structured Concurrency прошла два инкубаторных раунда и шесть preview — это значительный путь.

Как попробовать

Предложение доступно в ранних access-сборках JDK 27 с флагом --enable-preview. Обратная связь принимается через mailing-листы OpenJDK и продолжает влиять на API.

• Скачать early-access сборку JDK 27 с jdk.java.net/27
• Добавить --enable-preview при компиляции и запуске
• Заменить FailedException на ExecutionException в catch-блоках
• Обновить сигнатуры кастомных Joiner-реализаций до трёх тип-параметров

Выводы

Preview 7 не меняет форму API — он делает её честной. Тип исключения теперь в сигнатуре, а не в документации.

Три изменения в JEP 533 — замена FailedException, третий тип-параметр и новый оверлоад open() — продолжают линию на сближение Structured Concurrency с идиомами стандартной библиотеки. Дизайн, по всем признакам, сходится: если вы следите за эволюцией Java-конкурентности, это хороший момент попробовать JDK 27 early-access и отправить обратную связь в OpenJDK.

Подробности — в тексте JEP 533 и на страницах InfoQ.

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

Kotlin 2.4.0-Beta2. Ранний обзор будущей мажорной версии: изменения в языке, stdlib, JVM-бэкенде, Kotlin/Native и компиляторе.

Kotlin 2.3.21. Параллельный патч в стабильную ветку 2.3 — оптимизация производительности и баг-фиксы.

KotlinConf 2026. 20–22 мая в Мюнхене, ожидается 2000+ разработчиков. Онлайн-трансляция — на YouTube-канале Kotlin для тех, кто не сможет приехать.

Golden Kodee. Финалисты главной комьюнити-награды объявлены — top 3 в каждой категории получат приглашения в Мюнхен, победителей выберут на конференции.

Tooling. IntelliJ IDEA 2026.1, Amper 0.10.0 (автопровижн JDK, Maven-to-Amper конвертер), Ktor 3.4.3, Dokka 2.2.0, Exposed 1.0+ с поддержкой PostgreSQL array.

Kotlin 2.4.0-Beta2 и 2.3.21

JetBrains выложила первую Beta2 следующей мажорной версии — 2.4.0-Beta2. Это «предварительный взгляд» на то, что попадёт в стабильный релиз 2.4: изменения распределены сразу по нескольким слоям — самому языку, стандартной библиотеке, JVM-бэкенду, Kotlin/Native и компилятору. Если поддерживаете крупный проект — самое время прогнать его на бете и зарепортить регрессии до до заморозки кода.

Параллельно вышел 2.3.21 в стабильной ветке: фокус на производительности и багфиксах. Если вы пока не готовы переезжать на 2.4 — это безопасный апдейт минор-версии, без сюрпризов.

KotlinConf 2026 и Golden Kodee

Главное событие года для Kotlin-сообщества — KotlinConf 2026. Пройдёт 20–22 мая в Мюнхене, ожидается более 2000 разработчиков из разных стран. Если поехать не получается, JetBrains обещает livestream на YouTube-канале Kotlin — основные кейноты и анонсы можно будет посмотреть в прямом эфире.

К конференции приурочена ежегодная награда Golden Kodee для самых заметных людей сообщества — тех, кто организует мероприятия, делится знаниями, помогает новичкам. Финалисты в каждой категории объявлены: топ-3 в каждой категории приглашают в Мюнхен, победителей объявляют на конференции.

Из спикеров — стоит обратить внимание на keynote второго дня от Лены Райнхард: она будет говорить про карьеру в IT, лидерство, неопределённость на рынке и что значит «продуктивность» в эпоху ИИ.

Инструменты: IntelliJ, Amper, Koog, Ktor

Главные инструментальные апдейты апреля:

• IntelliJ IDEA 2026.1. Общая оптимизация производительности + улучшенная поддержка языков и фреймворков. Это значимый апдейт IDE, на который стоит переехать всем Kotlin-разработчикам.
• Amper 0.10.0. Инструмент сборки от JetBrains получил автоматический provisioning JDK (больше не нужно вручную ставить нужную версию), Maven-to-Amper конвертер (полезно для миграции проектов с легаси-кодом), поддержку кастомных Kotlin плагины компилятора и общее улучшение IDE-опыта.
• Koog для JVM-экосистемы. Koog — фреймворк JetBrains для построения AI-агентов на JVM. Появился идиоматичный Java API — теперь Java-команды могут строить пайплайны агентов без переписывания на Kotlin. Кроме того, Koog интегрировался со Spring AI — для Kotlin/Spring проектов это знакомый стек для работы с агентами.
• Ktor 3.4.3. Очередной патч асинхронного фреймворка для серверов и клиентов на Kotlin.
• Dokka 2.2.0. Стандартный документ-генератор для Kotlin-проектов.
• Exposed 1.0+. SQL-фреймворк теперь поддерживает array-типы PostgreSQL «из коробки» — раньше для этого нужны были custom-расширения.

Бэкенд, мультиплатформа и WebAssembly

Несколько практических материалов для тех, кто работает с Kotlin на бэкенде или в мультиплатформенных проектах:

• Spring Data JPA с Kotlin. Гайд про entities, repositories, custom queries и DTO — полезно для команд, уже сидящих на Spring и думающих про переход с Java на Kotlin.
• Spring guide: Uploading Files на Kotlin и Java. Параллельное сравнение помогает увидеть, как Kotlin вписывается в существующие бэкенд-процессы.
• Kotlin + WebAssembly с примером wasi:http (стандарт WebAssembly System Interface для HTTP-серверов) — минимальный HTTP-сервер на Kotlin/Wasm. Не production-ready, но ясно показывает, в каком направлении движется WebAssembly у Kotlin.
• KMP-аргументы для бизнеса. Гостевой пост от Touchlab про то, как объяснять руководству ценность Kotlin Multiplatform: ускорение поставки, снижение рисков, долгосрочная продуктовая стратегия. На tproger у нас был базовый туториал по созданию первого KMP-приложения для тех, кто хочет потрогать руками.

Обучение и развлечение

Если хочется прокачать или закрепить Kotlin — два полезных ресурса:

• Kotlin Professional Certificate by JetBrains на LinkedIn Learning. Четыре курса, финальный экзамен, сертификат на профиль. Заявленная длительность — менее 12 часов общего материала.
• Coroutines Races Guesser Game от kt.academy. Интерактивная игра: предсказываете, как поведут себя корутины в разных ситуациях. Хороший способ проверить интуицию по асинхронной логике, особенно если давно не работали со Structured Concurrency.

Выводы

Апрель в Kotlin-экосистеме оказался плотным: одновременно вышли беты будущей мажорной версии, патчи стабильной ветки, обновления IDE, инструментов сборки и фреймворков. Параллельно сообщество готовится к KotlinConf и финалу Golden Kodee. Если вы поддерживаете Kotlin-проект — стоит как минимум обновить IntelliJ до 2026.1 и поставить 2.3.21 в стабильный пайплайн.

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

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

На сервер уходят только публичные части. Приватные ключи сериализуются и хранятся локально в браузере — и никогда не покидают устройство в сеть.

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

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

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

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

Сервер в этот момент видит только публичные ключи и зашифрованный конверт. Он помогает устройствам найти друг друга, но не участвует в вычислении секрета.

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

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

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

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

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

Первый неочевидный момент: в E2EE сообщение адресуется не просто пользователю, а конкретным устройствам пользователя.

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

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

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

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

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

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Кому это будет нужно:

• Платформенным аналитикам — меньше рутинного ревью, больше времени на рабочие задачи.
• Продуктовым аналитикам и разработчикам — быстрая обратная связь, понятные и шаблонные требования для проекта.

Откуда растёт проблема

Прежде чем описывать решение, давайте поймем контекст.

Перед релизом любой фичи команда готовит поставку: у разработчика — code review, у аналитика — ревью документации. Весь процесс идёт по workflow в Jira, и один из обязательных этапов — Docs review.

За этот этап отвечают платформенные аналитики: они дежурят по очереди и проверяют поставки. Их задача — убедиться, что документация написана по стандарту и отражает все новые изменения по продуктам. Хранится всё в едином Confluence-пространстве платформы, и порядок там очень нужен: документацию читают не только аналитики разных команд, но и саппорт.

Звучит адекватно. Но на практике вылезают три проблемы:

1. Задержки. У платформенного аналитика помимо ревью куча других задач. Когда поставок много — Docs review начинает тормозить весь процесс подготовки к релизу.
2. Усталость ревьювера. Большой поток однотипных проверок выматывает даже самого внимательного, поэтому риск нужно было сократить.
3. Человеческий фактор. Несмотря на наличие стандарта, разные ревьюверы могут расставлять акценты по-разному. Аналитик продуктовой команды никогда не знает наверняка, на что обратят внимание в этот раз.

Всё это бьёт по времени поставки и непонятно растягивает подготовку к релизу — особенно когда релизиться нужно быстро.

Что пробовали раньше

Прежде чем идти в сторону AI, рассмотрели два очевидных варианта.

Вариант 1: убрать ревью совсем.

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

Вариант 2: алгоритмическая автоматизация без AI.

Теоретически можно написать набор проверок на if-else. Но у документации нет синтаксиса, как у кода — каждый аналитик пишет немного по-своему. Поддержка такого алгоритма со временем станет дороже, чем просто делать ревью руками.

Почему AI-агент

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

Вот конкретные факты, которые мы собрали внутри команды:

• LLM умеет понимать суть написанного, а не только искать точные совпадения, если документация написана по-разному — для нейронки это не проблема.
• Когда требования меняются, в большинстве случаев достаточно поправить промпт. Аналитик справится сам, без участия разработчика.
• У агента одна задача — ревью, он делает её сразу, не надо ждать, пока освободится дежурный аналитик.
• Агент интегрируется в существующий Jira-workflow. Для команд ничего не меняется — агент работает в фоне.
• У агента понятный набор инструкций.

Архитектура агента

Desmond — экосистема агентов. Desmond Docs Reviewer — task-oriented AI-агент для автоматизации ревью внутренней документации на платформе Альфа-Онлайн.

Стек:

• Язык: Java 21 + Spring AI
• Инфраструктура: Docker + Kubernetes во внутреннем AI-кластере банка
• Модель: gpt-oss-120b — внутренний продукт банка AlfaGen, развёрнутый локально
• Интеграции: Jira (webhook + REST API + Kafka), Code Review Agent (A2A через MCP), LLM API

Точка входа — webhook из Jira. Задача переходит в нужный статус → триггерится webhook → агент получает событие и начинает работу.

На входе агент имеет три сущности:

• описание изменений (фича)
• ссылку на документацию в Confluence
• ссылку на Pull Request разработчика

Дальше — четыре шага.

Как агент решает задачу пошагово

Посмотрим на работу агента со стороны процесса и распишем детально каждый.

Шаг 1. Нужна ли вообще проверка?

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

Агент анализирует описание задачи и diff PR. Смотрит на примеры из промпта и выдаёт решение: техническая доработка или нет, плюс короткое обоснование — не больше 30 слов.

Типовые технические доработки, которые не требуют проверки: обновление библиотек, рефакторинг тестов, исправление линтера, дизайнерские правки без влияния на UX. Есть и исключения — например, изменение deeplink-параметров или перемещение приложения в новый репозиторий. Всё это прописано в промпте явно.

На реальных задачах получили 89,7% корректных ответов (27 из 30). Для старта приемлемо, но будем улучшать.

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

Общий сценарий в коде выглядит так:

Шаг 2. Есть ли в документации описание фичи?

Если доработка бизнесовая — агент ищет в документации фрагменты, которые описывают конкретную фичу. Задача на этом шаге простая: найдено ли описание, и если да — в каких разделах и что именно написано.

Отдельно проверяется раздел «7. История изменений» — изменение должно быть там зафиксировано.

Проблема с токенами. Документация бывает большой — и она не влезает в контекст целиком. Решение: разбить на чанки и анализировать по частям.

Стратегия нарезки простая — равномерно по количеству символов, семантическое деление по разделам здесь не критично: мы ищем одни и те же фрагменты вне зависимости от их положения в структуре.

Чтобы не терять контекст на границах, используем перекрытие (overlap): к каждому чанку добавляем хвост предыдущего и заголовок его раздела. Размер чанка рассчитывается по формуле с коэффициентом, подобранным эмпирически — с запасом на колебания длины токенов.

Смысл её в том, чтобы заранее рассчитать максимально допустимое количество символов на чанк (C_chunk), включая резерв под перекрытие (C_dup) и заголовок. Коэффициент r был подобран эмпирически — с запасом, чтобы учесть возможные колебания в длине токенов.

После того как все чанки обработаны, агент собирает сводное саммари: в каких разделах нашлось описание фичи, указано ли изменение в истории. Если ничего не найдено — просит проверить формулировку описания в задаче.

Пример ответа, когда описание фичи найдено:

Пример ответа, когда описание фичи не найдено:

Шаг 3. Соответствует ли документация стандарту?

Это самая сложная часть — со звёздочкой. Нужно пройтись по каждому разделу документа и сверить его с требованиями стандарта. Документация структурирована: шапка, основная информация, предусловия, постусловия, сценарии использования, алгоритм, подробное описание, история изменений.

Возьмем кусочек стандарта, описывающий шапку страницы:

Стандарт для LLM — это не то же самое, что стандарт для людей

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

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

Вот типичные вопросы, на которые у стандарта не было ответа:

• Ссылка на команду — это Confluence, Notion или Jira?
• Jira-ссылка — это макрос или обычный URL?
• Как проверить корректность ссылки на репозиторий?
• Всегда ли обязательна эта таблица, или бывают исключения?

Переписали стандарт в LLM-читаемый формат, руководствуясь простыми принципами:

• Каждое требование сформулировано явно и однозначно.
• Для каждого поля приведены примеры правильного и неправильного заполнения.
• Никаких «подразумевается» и «как правило».

Вот как выглядит фрагмент переписанного стандарта для шапки документа:

Кусочек 2

Кросс-раздельные проверки

Часть требований касается не одного раздела, а согласованности между несколькими. Например: все сервисы, упомянутые в колонке Git Middle шапки, должны иметь ссылку на документацию в разделе «Основная информация».

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

Один из примеров кросс-проверок:

Chunking strategy

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

Дано:

• LLM-читаемый формат, разбитый по разделам
• Документация, также структурированная по разделам

Решение:

1. Разделяем на чанки документацию. 1 чанк = 1 раздел.

2. Разделяем на чанки стандарт. 1 чанк = 1 требование.

3. Сопоставляем чанки стандарта и документации между собой:

Проверка оформления:

1 чанк (раздел) документации ~ 1 чанку стандарта (требование к разделу).

Кросс-проверки:

1 чанк кросс-проверки (отдельный раздел с кросс-проверками) ~ n чанкам (разделам) документации.

4. Отправляем в LLM запросы на проверку по каждому соответствию.

5. Собираем в единый отчет.

Примеры:

Проверка оформления

• 1 чанк стандарта

• 1 чанк документации (представлено графически для наглядности. В реальности данные передаются в LLM в HTML-формате)

Кросс-проверка

• 1 чанк стандарта:

• 2 чанка документации:

Чанк 1

Чанк 2

Итоговый промпт:

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

Как выглядит код:

Мы видим, что при использовании чанков LLM перестала пропускать требования, проверки стали стабильнее, ответы — содержательнее.

Пример ответа LLM до чанкования в свободном формате:

Пример ответа LLM после чанкования в JSON-формате. Приведу пример анализа только одного чанка (раздел Алгоритм), т.к. в сумме по чанкам получается тот самый объёмный текст длиной в 200-250 символов.

А что если раздел слишком большой?

В таком случае мы используем chunking strategy из шага 2 и агрегируем результаты с помощью немного сумасшедшего 💊, но работающего промпта.

Агент отправляет запрос на проверку по каждому соответствию, затем собирает всё в нормальный отчёт. Изначально отчёт выходил на 200–250 строк — неудобно читать, мы добавили отдельный шаг финального саммари — сократили до 50 строк без потери содержания.

Технические грабли

Нестабильность ответов LLM

Одна из первых проблем — LLM отвечала в произвольном формате. Иногда JSON, иногда текст, иногда что-то среднее. Решение: Structured Output в Spring AI. Ответ всегда приходит в заданной структуре — никакой самодеятельности.

Лимит токенов

Встречается на обоих шагах, но по-разному. На шаге поиска фичи — документация слишком большая целиком. На шаге проверки стандарту — в контекст не влезают и документ, и стандарт одновременно. В обоих случаях решение — chunking с правильно рассчитанным размером и overlap.

Скрытые элементы Confluence

Confluence отдаёт HTML, и часть контента скрыта в элементах, которые не видны при обычном просмотре страницы. Агент работает напрямую с HTML, в котором остаются только нужные для обработки теги — это позволяет не терять данные, которые визуально не отображаются

Долгое время обработки

Первые версии работали медленно: несколько запросов к LLM шли последовательно. Переключились на Java Virtual Threads — параллельная обработка чанков сократила медианное время ревью с 1:20 до 0:26.

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

Что конкретно упростилось

• Аналитики продуктовых команд стали прогонять документацию через агента ещё до этапа ревью — как самопроверку.
• При повторном ревью после правок не надо ждать человека — достаточно перезапустить агента.
• Проверка корректности ссылок и форматов полностью снята с плеч аналитиков.

Ограничения

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

Что дальше

Идеи в работе и на горизонте:

• Автоматический аппрув документации, если все проверки прошли успешно.
• Подключение проверок документации по микросервисам, не только фронтенд.
• Проверка полноты документации через код — что позволит закрыть ревью почти полностью, за исключением нестандартных кейсов.

Почему Java знают во всем мире

Java — один из самых известных и распространенных языков программирования. Он был создан в середине 1990-х годов компанией Sun Microsystems с четкой целью: получить универсальный и надежный инструмент для разработки программного обеспечения. В отличие от многих языков того времени, которые были привязаны к конкретным типам компьютеров или операционных систем, Java с самого начала задумывался как кроссплатформенный. Это означает, что программу, написанную на Java, можно запустить практически на любом устройстве — от мощного сервера до мобильного телефона или даже бытовой техники, — конечно, при наличии специальной среды выполнения.

В основе этой универсальности лежит принцип: «написано один раз — работает везде». Это стало возможным благодаря технологии JVM (Java Virtual Machine — виртуальная машина Java). Процесс работы выглядит так: разработчик пишет код на Java, который затем компилируется (преобразуется) не в команды для конкретного процессора, а в особый промежуточный код, называемый байт-кодом. Этот байт-код может выполниться на любой платформе, где установлена своя версия JVM. JVM выступает в роли «переводчика» и исполнителя: она читает универсальный байт-код и «объясняет» его конкретному компьютеру на его языке. Именно этот принцип обеспечил Java долголетие и широкое применение.

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

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

Именно эти принципы — универсальность, четкость и широкие возможности — делают Java не просто языком программирования, а отличным образовательным инструментом. Java учит детей не просто писать код, а мыслить структурно, проектировать решения и понимать, как устроены настоящие программы. Если этот подход вам близок и вы видите потенциал в таком обучении, приглашаем вас и вашего юного программиста познакомиться с Java ближе. В Школе программирования для детей «Пиксель» Java — это один из ключевых языков для обучения старшеклассников.

Подробнее о нашем онлайн-курсе «Программирование на Java для детей 14-17 лет» можно узнать здесь.

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

Основы языка Java

Java известен своим относительно простым и понятным синтаксисом (набором правил написания кода) — именно поэтому Java отлично подходит детям. Многие его ключевые слова заимствованы из английского языка, и это облегчает начальное понимание. Такие команды, как if (если), else (иначе), for (для, цикл), class (класс), делают Java интуитивно понятным для детей. Это помогает новичкам сосредоточиться на изучении логики программирования, а не на запоминании сложных и абстрактных символов.

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

• Класс — общее описание сущности. Он определяет, какие данные (свойства) и доступные действия (методы) будут у объектов.
• Объект — это конкретный экземпляр класса.

Простой пример: представьте класс «Смартфон». В его чертеже указаны общие свойства: «модель», «цвет», «объемПамяти». Также указаны возможные действия: «позвонить()», «сделатьФото()».

От этого класса можно создать конкретные объекты:

• Объект «смартфонМаши» со значениями: модель = "iPhone 15", цвет = "синий", объемПамяти = 128.
• Объект «смартфонПети» со значениями: модель = "Android Galaxy", цвет = "черный", объемПамяти = 256.

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

Первая программа на Java для детей — «Hello, World!»

Знакомство детей с Java, как и с любым другим языком программирования, традиционно начинается с программы, которая выводит на экран приветствие миру. Вот как это выглядит на Java:

Разберем код построчно:

public class HelloWorld {

• public — модификатор доступа, означающий, что класс доступен из любого места программы.
• class — ключевое слово для объявления класса.
• HelloWorld — имя класса. Оно должно совпадать с именем файла (HelloWorld.java). Фигурная скобка { обозначает начало тела класса.

public static void main(String[] args) {

• Это объявление главного метода программы. Его имя main — особое, именно с этой точки Java начинает выполнение кода.
• public static void — это обязательная комбинация для главного метода, которую на начальном этапе можно запомнить как формулу.
• (String[] args) — параметры метода, в данном случае возможность передавать программе аргументы командной строки.

System.out.println("Hello, World!");

• Это исполнительная строка, которая выполняет действие.
• System.out — стандартный объект для вывода информации.
• println — его метод, который выводит текст и переводит курсор на новую строку.
• ("Hello, World!") — текст (строка), который нужно вывести. Текст всегда заключается в двойные кавычки-лапки.
• Каждая команда в Java (кроме объявлений) завершается точкой с запятой ;. Это обязательно.

Закрывающие фигурные скобки } обозначают конец метода main и конец класса HelloWorld.

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

Где используют Java? Неожиданные места и большие проекты

Java успешно применяют в самых разных сферах. Его универсальность и надежность не просто сделали его основой для миллионов приложений по всему миру — и взрослые, и дети взаимодействуют с Java-приложениями ежедневно!

Мобильная разработка на платформе Android

Операционная система Android, которая установлена на подавляющем большинстве смартфонов и планшетов в мире, в значительной степени создана на Java. Большинство приложений в Google Play Store также написано на Java или Kotlin (языке, который полностью совместим с Java и работает на той же виртуальной машине). Для детей Java — это язык мобильных игр и приложений на телефоне, которыми они пользуются каждый день.

Серверная часть веб-сайтов и онлайн-сервисов (бэкенд)

Когда пользователь заходит на сайт интернет-банка, социальной сети или крупного магазина, его браузер показывает лишь интерфейс — «лицевую часть» приложения (фронтенд). Обработка данных, расчеты и взаимодействие с базами данных происходят на удаленных серверах. Эта скрытая от глаз, но критически важная серверная часть приложения (бэкенд) очень часто построена на Java — и именно Java в этом случае отвечает за надежную работу функций поиска, оформления заказов, обработки платежей и личных кабинетов.

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

Современные компании и научные организации анализируют колоссальные объемы информации — от финансовых транзакций до данных с различных датчиков. Для обработки таких массивов данных (их обычно называют Big Data) часто используются инструменты, созданные на Java, например, Apache Hadoop и Apache Spark. Кроме того, Java — это традиционный и проверенный язык для сложного корпоративного софта: систем управления предприятиями (ERP), систем автоматизации бизнес-процессов и клиент-серверных приложений в крупных организациях, где в приоритете стабильность и безопасность.

Разработка игр

Еще один пример, близкий детям: на Java была написана первоначальная версия культовой игры Minecraft. Это наглядно демонстрирует возможности языка в создании сложных графических миров. Хотя для высокобюджетных компьютерных игр чаще используются C++ или C#, Java активно применяется для разработки мобильных игр под Android, а также для создания серверных компонентов многопользовательских игр, которые отвечают за логику, учетные записи и взаимодействие игроков в сети.

Устройства «умного» дома и Интернета вещей (IoT)

Java, благодаря своей кроссплатформенности и высокой степени безопасности, применяют и во встраиваемых системах. Его используют в некоторых типах смарт-телевизоров, медиаплееров, системах «умного» дома для программирования работы устройств. Существует специальная оптимизированная версия Java — Java ME (Micro Edition) — предназначенная для программирования маломощных устройств, таких как датчики или бытовая техника с сетевым управлением.

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

Почему Java — отличный выбор для первого «взрослого» языка

Переход от визуальных языков программирования (как Scratch) или простых скриптовых языков к первому серьезному, «взрослому» языку — важный этап. Для детей Java является одним из оптимальных вариантов по нескольким причинам:

Строгая дисциплина и структурированное мышление

Java — язык со статической типизацией и четкой, формальной структурой. Это означает, что программисту нужно заранее объявлять тип каждой переменной (например, int для числа, String для текста), а каждая программа должна быть организована в виде классов и методов.

С Java ребенок не может написать хаотичный код, который «как-нибудь работает». Ему приходится сначала продумать структуру: какие сущности (классы) будут в программе, какие у них будут свойства и действия. Любая опечатка или логическая ошибка приводит к тому, что программа просто не запустится или ее не получится скомпилировать. Это приучает к аккуратности, внимательности к деталям и привычке планировать решение задачи перед тем, как писать код. Такая дисциплина — бесценный навык для любого инженера.

Огромное сообщество и обилие ресурсов

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

На любой вопрос, который может возникнуть у ребенка о программировании на Java, с высокой вероятностью уже есть подробный ответ на таких платформах, как Stack Overflow. Существуют миллионы готовых библиотек — наборов кода для решения типовых задач (работа с графикой, сетью, базами данных). Программируя на Java, ребенок учится не только писать все с нуля, но и правильно использовать готовые инструменты — а это стандартная практика в реальной разработке. Качественная документация и огромное количество учебных материалов облегчают процесс обучения.

Прямой путь к востребованной профессии

Java десятилетиями занимает ведущие позиции в рейтингах самых популярных и востребованных языков программирования:

• Это язык, на котором построена критически важная инфраструктура тысяч крупных компаний в банковском секторе, телекоммуникациях, ритейле. Такие системы обновляются и поддерживаются, но крайне редко полностью переписываются. Это обеспечивает постоянный спрос на Java-разработчиков.
• Знание Java для ребенка — это двери в несколько карьерных направлений сразу: разработка корпоративный софта, создание серверной части высоконагруженных веб-сервисов, мобильная разработка под Android. Это дает возможность выбора и специализации в будущем.

Фундамент для изучения других технологий

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

Java — один из лучших языков для глубокого понимания ООП. Понимание инкапсуляции, наследования и полиморфизма в Java создаст у ребенка прочную базу.

Освоив Java, гораздо проще выучить синтаксически и концептуально похожие языки. Например, C# (основной язык для разработки под Windows и игр на Unity) или Kotlin (официальный язык для Android, который полностью совместим с Java). Даже переход на такие языки, как Python, будет осознанным, потому что ребенок уже будет понимать, какие механизмы Python упрощает, а какие остаются общими.

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

Java для детей: первые проекты

Прежде чем приступить к изучению Java, нужна несложная, но важная подготовка. Первый шаг — установка профессиональной бесплатной среды разработки (Integrated Development Environment, IDE). Оптимальный выбор для Java — IntelliJ IDEA Community Edition. Эта среда, созданная компанией JetBrains, очень удобна и используется разработчиками по всему миру. Она значительно упрощает процесс: подсвечивает синтаксис, автоматически находит ошибки, предлагает варианты завершения кода и имеет удобный интерфейс для управления проектами. Установка проходит стандартно: нужно зайти на официальный сайт JetBrains, скачать дистрибутив для вашей операционной системы (Windows, macOS, Linux) и следовать инструкциям установщика. После первого запуска среда готова к созданию нового проекта.

После настройки инструментов можно приступать к первым проектам:

Текстовый квест или чат-бот в консоли. Для ребенка это отличный способ освоить базовые конструкции Java: переменные, условные операторы (if-else), циклы (while, for) и работу со строковым вводом/выводом. Ребенок может написать программу, которая задает пользователю вопросы, сохраняет ответы в переменных и в зависимости от выбора выводит разные текстовые описания развития сюжета. Такой проект учит алгоритмическому мышлению и построению логических ветвлений.

Простой калькулятор. Этот классический проект помогает понять работу с арифметическими операциями, разными типами данных (например, int для целых чисел и double для дробных) и организацией простейшего пользовательского интерфейса в консоли. Можно начать с программы, которая запрашивает два числа и операцию (+, -, *, /), а затем выводит результат. Затем задачу можно усложнить, добавив обработку ошибок (например, деления на ноль) или цикл, позволяющий производить вычисления без перезапуска программы.

Графическая программа с библиотекой Processing. Для визуального результата, который особенно мотивирует детей, отлично подходит библиотека Processing for Java. Она упрощает создание графики и анимации, предоставляя простые функции для рисования фигур, работы с цветами и обработки событий мыши или клавиатуры. Первым проектом может стать интерактивный рисунок: например, программа, где при клике мышью на холсте появляется круг случайного цвета, или простейшая анимация движущегося объекта. Такая программа наглядно продемонстрирует связь кода и визуального действия, а также познакомит с основами обработки событий — ключевой концепции в программировании.

Программирование на Java: правила эффективной учебы для детей

1. Регулярная практика. Постоянство важнее объема. Лучше писать код по 30-40 минут ежедневно, чем 5 часов раз в неделю. Это помогает лучше запоминать синтаксис и развивать мышечную память.
2. Чтение и анализ чужого кода. Изучение готовых, хорошо написанных небольших программ или фрагментов кода (например, на GitHub) помогает понять разные стили программирования, узнавать новые приемы и видеть, как решаются типовые задачи.
3. Дробление больших задач на маленькие. Любой сложный проект нужно разбивать на простые, последовательные шаги. Сначала — спланировать логику на бумаге или в комментариях, затем — реализовать ядро, потом добавить детали и, наконец, провести тестирование. Этот подход избавляет от ощущения перегруженности и учит системному проектированию.
4. Не бояться ошибок. Ошибки компиляции и логические недочеты — естественная часть процесса обучения. Умение внимательно читать сообщения об ошибках от среды разработки, понимать их причину и исправлять — один из самых важных навыков, который нужно формировать с самого начала.

Частые вопросы о Java для детей и подростков

Со скольки лет можно начинать изучать Java? Не слишком ли это сложно для ребенка?

Java действительно является «взрослым» языком, требующим от ученика определенной зрелости мышления. Наиболее подходящий возраст для начала системного изучения — 12-14 лет. К этому времени у ребенка, как правило, уже сформированы базовые навыки логического и абстрактного мышления, необходимые для понимания таких концепций, как объектно-ориентированное программирование. Важным фактором является и мотивация: если ребенок уже имеет опыт работы в визуальных средах (например, Scratch) или проявил интерес к созданию собственных игр и программ, он готов к более сложным задачам. Сложность Java — это его достоинство. Он не позволяет писать небрежный код, и поэтому с самого начала прививает дисциплину, аккуратность и привычку продумывать архитектуру решения. Для талантливого и увлеченного подростка эта сложность становится не барьером, а интересным вызовом.

Чем Java лучше или хуже, чем Python, для первого языка программирования?

Это два разных подхода с разными целями. Python завоевал популярность благодаря минималистичному синтаксису, который позволяет быстро получить результат, что отлично подходит для младших школьников или для изучения основ алгоритмов. Java, в свою очередь, делает акцент на строгости и структуре. Он заставляет явно объявлять типы переменных, организовывать код в классы, что изначально формирует понимание «правильного» промышленного подхода к разработке. Если Python учит решать задачи, то Java учит строить надежные, масштабируемые системы. Выбор зависит от цели: если нужно быстро и увлекательно познакомить с программированием — можно начать с Python. Если стоит задача заложить максимально прочный фундамент для будущей карьеры в IT, особенно в таких областях, как enterprise-разработка или Android, — Java будет предпочтительнее. Многие педагоги считают, что после освоения основ на одном языке переход на второй дается значительно легче.

Что конкретно должен уметь и знать ребенок, чтобы начать изучение Java?

Глубоких специальных знаний не требуется. Нужна базовая компьютерная грамотность: уверенная работа с файловой системой (создание папок, сохранение файлов), навыки печати, понимание, что такое установка программы. Крайне важно иметь развитое логическое и алгоритмическое мышление. Этому часто способствует увлечение математикой, логическими головоломками или даже стратегическими играми. Опыт программирования в любой форме (Scratch, блочное программирование в Minecraft или простые скрипты) является большим преимуществом, но не строго обязательным. Самое главное — желание и готовность к последовательной, иногда кропотливой работе, где результат достигается не мгновенно, а через анализ и исправление ошибок.

Насколько сложна установка среды разработки и подготовка к первым урокам?

Технический порог входа сегодня минимален. Установка бесплатной среды разработки IntelliJ IDEA Community Edition ничем не отличается от установки любой другой программы и занимает 10-15 минут. Современные среды (IDE) максимально упрощены для новичков: они автоматически определяют настройки, предлагают создать первый проект в пару кликов, а встроенные системы подсказок и проверки кода (автодополнение, подсветка ошибок) служат интерактивным учебным пособием. Технические аспекты не должны пугать; основное внимание с первого же занятия уделяется непосредственно логике и синтаксису языка.

Какие реальные проекты сможет делать ребенок после 3-6 месяцев изучения Java?

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

• Консольные приложения. Разнообразные текстовые квесты с нелинейным сюжетом, программы-шифровальщики, простые имитаторы банкомата или телефонной книги с функциями добавления и поиска.
• Графические приложения (с использованием библиотек, например, Processing). Интерактивные арты, где рисунок реагирует на движения мыши, классические аркады («Змейка» или «Понг»), простые симуляторы (например, падающих снежинок).
• Начало работы с графическим интерфейсом (GUI). Создание оконных приложений с кнопками, текстовыми полями и метками — например, усовершенствованный калькулятор с графическим интерфейсом или программа-напоминалка.Эти проекты не являются строго учебными; они используют те же принципы и подходы, что и в реальной разработке, давая ребенку ощутимый результат своей работы.

Почему в процессе обучения так много внимания уделяется ошибкам (error messages)?

Работа с ошибками — это один из ключевых навыков программиста. Язык и среда разработки Java дают ребенку детальные, часто очень точные описания того, что пошло не так. Умение не пугаться красного текста в консоли, а прочитать, вникнуть в сообщение об ошибке и методично исправить проблему — это фундаментальный мета-навык. Он развивает критическое мышление, терпение и умение самостоятельно искать решение проблем, что гораздо важнее заучивания конкретных конструкций языка. Наставник в этом процессе играет роль проводника, который учит «читать» эти сообщения и применять системный подход к отладке.

Как родитель, не знакомый с программированием, может помочь и поддержать ребенка?

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

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

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

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFJM8gaL

Тогда компании нанимали инженеров с запасом, под давлением цифровизации, дешевых денег и страха «остаться позади». По данным Indeed и FRED, пик вакансий пришелся на середину 2022 года. После чего последовал резкий спад, так и не вернувшись до прежнего уровня.

Почему ИИ — удобный, но не главный виновник

ИИ стал публичным оправданием сокращений. Заявление «мы заменяем людей на ИИ» хорошо смотрится в отчетах и перед инвесторами.

На практике же компании сокращали издержки, выравнивали штат и параллельно активнее нанимали за пределами США и Европы, где инженеры стоят дешевле.

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

Как будет выглядеть рынок в 2026 году

Эксперты сходятся во мнении: 2026 год пройдет в режиме «низкого найма — низких увольнений». Массовых сокращений не ожидается, но и бурного роста вакансий не будет. Так выглядит стабилизация рынка.

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

По прогнозу Бюро статистики труда США, число вакансий для разработчиков продолжит расти примерно на 15%. Это медленнее, чем ожидалось раньше, но все еще быстрее большинства профессий.

Почему джунам повезло меньше всего

Самое слабое место рынка — начальные позиции. Количество вакансий для junior-разработчиков упало примерно на 40% по сравнению с допандемийным уровнем.

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

Но это также создает отложенную проблему — без притока новичков рушится кадровый «конвейер».

Какие навыки реально востребованы

В 2026 году ценятся не языки сами по себе, а связки «язык + область».

Тот же Python чаще всего нужен при работе с ИИ и данными. JavaScript и TypeScript — для фронтенда и fullstack. Go — для бэкенда и инфраструктуры. Java — для enterprise-систем.

Параллельно растет спрос на ИИ- и дата-инженеров, а также специалистов по ИИ-инфраструктуре.

2025 год получился насыщенным для Java: вышел JDK 25, активно развиваются проекты Amber и Valhalla, улучшается производительность сборщиков мусора. Собрали топ-15 самых просматриваемых докладов о Java с конференций этого года. К каждому найдёте короткое описание, чтобы вы могли быстро решить, стоит ли тратить на него время.

1. How Netflix Uses Java - 2025 Edition

Конференция - 272 000 просмотров - 26 апреля 2025 - 47 минут

Netflix управляет более чем 3000 микросервисов на Java. В докладе разбирают, как компания использует Spring Boot, DGS (их GraphQL-фреймворк) и gRPC для взаимодействия между сервисами. Показывают работу с новыми сборщиками мусора, виртуальными потоками (virtual threads) и делятся реальными уроками по управлению зависимостями и созданию native images.

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

2. Java Performance Update

Конференция - 71 000 просмотров - 25 января 2025 - 53 минуты

Доклад представляет пять недавних улучшений производительности в JDK. Разбирают оптимизацию MergeStore JIT, которая ускоряет слияние массивов, изменения в сборщиках мусора и оптимизации стандартной библиотеки. Главный тезис: Java становится быстрее без изменений в вашем коде.

Почему стоит посмотреть: Если у вас есть приложения на Java 8-11 и вы сомневаетесь, стоит ли обновляться, этот доклад покажет конкретные цифры производительности. Объясняют не только что изменилось, но и почему это работает быстрее на уровне JVM.

3. Where is the Java language going?

Конференция - 65 000 просмотров - 20 апреля 2025 - 45 минут

Обзор последних обновлений и планов развития Java. Подробно разбирают новые возможности из Project Amber (улучшения синтаксиса языка) и Project Valhalla (value types и primitive classes), которые формируют будущее языка.

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

4. Java 24 Launch - Live from JavaOne 2025

Конференция - 62 000 просмотров - 19 марта 2025 - 2 часа 47 минут

Официальная презентация Java 24 с конференции JavaOne. Включает вступительный доклад с живыми демонстрациями, разбор улучшений производительности сборщиков мусора, AOT-кеширование (Ahead-Of-Time compilation cache) и stream gatherers — новый API для работы с потоками данных.

Почему стоит посмотреть: Это официальный обзор релиза от команды разработчиков Java. Если нужно понять, что нового в Java 24 и стоит ли переходить, смотрите это. Длинный формат позволяет подробно разобрать все важные фичи.

5. Know Your Java?

Конференция - 56 000 просмотров - 11 мая 2025 - 40 минут

Интерактивная демонстрация странных особенностей поведения Java, которые до сих пор ставят в тупик даже опытных разработчиков. Показывают неочевидные случаи с autoboxing, generics, type erasure и другими особенностями языка. Все с примерами кода, которые можно повторить.

Почему стоит посмотреть: Если вы думаете, что хорошо знаете Java, этот доклад проверит вашу уверенность. Полезно для собеседований и для понимания, почему код иногда ведет себя неожиданно. Формат интерактивный — спикер задает вопросы аудитории, и можно попробовать ответить самостоятельно.

6. Modern Java Deep Dive

Конференция - 40 000 просмотров - 8 февраля 2025 - 2 часа 31 минута

Глубокое погружение в Java 22 и 23. Разбирают множество небольших, но важных изменений: безымянные паттерны (unnamed patterns), примитивные паттерны (primitive patterns), Foreign Function and Memory API (для работы с нативным кодом), импорты модулей, stream gatherers, Markdown в JavaDoc и улучшения в сборщиках мусора.

Почему стоит посмотреть: Доклад объясняет не просто что добавилось, но и что финальное (можно использовать в продакшене), что в preview (экспериментальная фича), и почему это важно для реальных проектов.

7. Java for AI

Конференция - 39 000 просмотров - 3 мая 2025 - 44 минуты

Доклад показывает, как существующие и будущие возможности Java могут сделать язык конкурентоспособным в области искусственного интеллекта. Разбирают Foreign Function and Memory API (для вызова библиотек машинного обучения), Vector API (для SIMD-операций), Project Valhalla (value types для производительности) и Project Babylon (компиляция Java-кода для GPU).

Почему стоит посмотреть: Если интересуетесь машинным обучением и хотите понять, можно ли использовать Java вместо Python, этот доклад дает конкретные идеи для библиотек и инструментов.

8. Real World Lean Java Practices, Patterns, Hacks, and Workarounds

Конференция - 35 000 просмотров - 5 мая 2025 - 51 минута

Практические подходы для Java 21 и выше: как убрать избыточность из кода, структурировать монолиты и микросервисы, улучшить тестирование, использовать data-oriented паттерны (работа с данными вместо объектов), decoupling паттерны (уменьшение связанности), автоматизировать процессы с помощью чистой Java и переосмыслить дизайн кода для работы с LLM-ассистентами вроде GitHub Copilot.

Почему стоит посмотреть: Это не теоретический доклад, а подборка рабочих приемов от опытного разработчика. Полезно для рефакторинга legacy-кода и проектирования новых систем. Много примеров того, как новые возможности Java 21+ упрощают код.

9. A Java Developer's Guide to Navigating the Frontend Landscape

Конференция - 34 000 просмотров - 1 мая 2025 - 46 минут

Практическое руководство для Java-разработчиков по современному фронтенду. Сравнивают Java UI-фреймворки (JavaFX, Vaadin) с популярными JavaScript-фреймворками (React, Angular, Vue). Раскрывают современные техники фронтенд-разработки и компромиссы между разными подходами.

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

10. The New Java Best Practices by Stephen Colebourne

Конференция - 36 000 просмотров - 9 октября 2025 - 48 минут

Лучшие практики Java кардинально изменились со времен Java 8. Stephen Colebourne (создатель Joda-Time и активный участник развития Java) разбирает современные подходы: records versus beans, pattern matching, Optional versus null, data-oriented programming. Дает четкие, аргументированные рекомендации по каждому вопросу.

Почему стоит посмотреть: Если вы пишете на Java по привычкам из эпохи Java 8, этот доклад обновит ваше понимание того, как писать современный Java-код. Спикер немного резкий, но много обоснованных мнений, будет точно полезно.

11. AI/ML Introduction for Java Developers

Конференция - 29 000 просмотров - 2 июня 2025 - 52 минуты

Практическое введение в машинное обучение и генеративный ИИ для Java-разработчиков. Объясняют разницу между GenAI (генеративный ИИ вроде GPT) и PredAI (предиктивный ИИ для прогнозирования), стратегии написания промтов, работу с LLM API через библиотеки вроде Langchain4J, векторные базы данных и RAG (Retrieval-Augmented Generation).

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

12. Growing the Java Language #JVMLS

Конференция - 28 000 просмотров - 21 августа 2025 - 1 час 20 минут

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

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

13. Java 24 - Better Language, Better APIs, Better Runtime

Конференция - 26 000 просмотров - 1 марта 2025 - 51 минута

Обзор Java 24, который фокусируется на практических улучшениях: AOT-загрузка классов (Ahead-Of-Time class loading для ускорения старта), stream gatherers (новый способ обработки потоков данных), class-file API (программный доступ к байткоду) и улучшения в ZGC (сборщик мусора с низкими паузами).

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

14. SQL, JSON, and Java

Конференция - 25 000 просмотров - 14 апреля 2025 - 50 минут

Современные мультимодельные базы данных начинают обходить MongoDB по возможностям, объединяя SQL и JSON в одной системе. Доклад с конференции JavaOne разбирает компромиссы между JSON и реляционными данными, стандарт ISO SQL для работы с JSON, бинарный JSON для низколатентного JDBC, интеграции с Jackson и Jakarta, и как record patterns в Java 21 делают schema-less хранение JSON практичным.

Почему стоит посмотреть: Если работаете с данными в Java и выбираете между реляционными базами и NoSQL, этот доклад показывает современный подход, который объединяет лучшее из обоих миров. Много практических примеров работы с JSON в PostgreSQL, Oracle и других БД.

15. Garbage Collection in Java - The progress since JDK 8

Конференция - 24 000 просмотров - 15 февраля 2025 - 50 минут

Сборка мусора в Java прошла долгий путь с JDK 8. Доклад проходит по разным сборщикам (G1GC, ZGC, Shenandoah), объясняет практические компромиссы между ними и показывает, почему простое обновление JDK может реально ускорить приложения.

Почему стоит посмотреть: Если у вас проблемы с производительностью, долгие GC-паузы или высокое потребление памяти, этот доклад объясняет, какой сборщик мусора выбрать и как его настроить.

Итого вы получили 15 докладов, которые покрывают все актуальные моменты современной Java — от базовых улучшений производительности до работы с ИИ и данными. В следующей части выложим доклады по Rust.

По данным World Economic Forum, 44% профессиональных навыков обновятся к 2027 году. Елена Соколова, Product Owner в Компьютерной Академии ТОП (ранее работала карьерным консультантом в Яндекс Практикуме и Нетологии, реализовывала проекты в Carlsberg Group, Лента, РЖД, Danone), за 850+ часов консультаций помогла специалистам устроиться в Яндекс, EPAM, МТС, Сбер и Ozon. Основная проблема, которую она видит: люди учатся хаотично, не понимая системы.

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

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

Универсальные навыки: фундамент для всех направлений

Рынок требует не десять абсолютно разных скиллов, а три связанных блока компетенций. Первый — универсальные навыки, без которых сложно расти в любом направлении IT.

Когнитивное лидерство

Аналитическое и креативное мышление заняли первое и второе места в рейтинге навыков будущего по версии World Economic Forum 2024. Это способность разбирать сложные задачи на части, находить нестандартные решения и выстраивать логические цепочки. Вдобавок — устойчивость, гибкость и любознательность: качества, которые помогают адаптироваться к меняющимся требованиям рынка и осваивать новые инструменты.

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

Как развивать: решайте задачи на алгоритмы на LeetCode или Codewars, участвуйте в хакатонах, разбирайте чужой код на GitHub и пытайтесь объясняйть логику решений.

Техно-гуманитарная грамотность

IT-специалист в 2026 году необязательно должен быть разработчиком, но должен понимать, как работают технологии и как правильно ставить им задачи. Грамотность в области ИИ и больших данных (AI & Big Data Literacy) заняла седьмое место в рейтинге WEF — это умение сформулировать запрос к нейросети, оценить качество данных, выбрать подходящий инструмент для задачи.

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

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

Как развивать: экспериментируйте с ChatGPT, Claude или Gemini, изучайте основы работы с API, читайте документацию инструментов, которыми пользуетесь ежедневно.

Для тех, кто хочет системно освоить работу с ИИ, существуют специализированные программы — например, «Нейросети для увеличения дохода» и «Искусственный интеллект для жизни» в Академии ТОП учат не просто генерировать контент, а ставить корректные задачи моделям и интегрировать их в рабочие процессы.

Эмоциональный интеллект

Чем больше команд работает удаленно и чем активнее ИИ забирает рутинные задачи, тем выше ценность навыков, которые невозможно автоматизировать. Эмпатия, активное слушание и лидерство социального влияния заняли восьмое и девятое места в рейтинге World Economic Forum. Эти компетенции помогают выстраивать сотрудничество, разрешать конфликты и вести команду к результату.

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

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

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

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

Селф-менеджмент

Мотивация и самосознание заняли четвертое место в рейтинге навыков будущего по версии World Economic Forum. Это способность управлять собственными ресурсами, удерживать фокус в условиях постоянных переключений и не выгорать при плотных дедлайнах.

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

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

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

Специализация: что нужно знать по направлениям

Универсальные навыки — это фундамент, но на рынке труда оценивают конкретные компетенции. Требования различаются в зависимости от направления, но общая тенденция одна: работодатели ждут не просто знания инструментов, а понимания, как эти инструменты решают бизнес-задачи.

Программист

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

• Базовое программирование: переменные, циклы, функции, основы объектно-ориентированного программирования, уверенное владение хотя бы одним языком — Python, JavaScript, Java или C#. Плюсом идут TypeScript, Go или Kotlin.
• Веб и API: понимание протокола HTTP, работа с REST и JSON, базовые знания GraphQL, HTML и CSS для понимания фронтенда, SQL и основы NoSQL-баз данных. Тренд 2026 года — реактивные API и стриминг-данные в реальном времени.
• Инструменты разработки: Git для контроля версий, базовое понимание CI/CD, умение работать с Docker для контейнеризации приложений, навыки деплоя в облако хотя бы на базовом уровне.
• Алгоритмы и структуры данных: работа с массивами, списками, хэш-таблицами, понимание основных алгоритмов сортировки и поиска, базовое представление о сложности алгоритмов (нотация Big O).

Многое зависит от направления. Во фронтенде нужны JavaScript или TypeScript и React, в бэкенде — Python, Java или Go. Важный момент: импортозамещение делает обязательным опыт работы с отечественными платформами. В вакансиях на позицию Junior Backend Developer все чаще встречается требование знания Yandex Cloud или VK Cloud — это уже не плюс в резюме, а базовое ожидание.

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

Для тех, кто выбирает разработку как основное направление, важна структурированная база. Программы по программированию в Академии ТОП дают практический стек под востребованные языки — от Python до Java — с проектами в портфолио и помощью в трудоустройстве.

Дизайнер

Среди множества направлений дизайна — графического, UX/UI, 2D, 3D, motion, интерьерного — веб остается одним из самых востребованных. В 2026 году от веб-дизайнера ждут базовых умений работать с Figma, понимания технологий, данных и того, как меняется пользовательский опыт.

• Работа с ИИ: умение ставить задачи моделям и оценивать результат. ИИ не заменяет дизайнера, но специалист, который не умеет его использовать, проигрывает в скорости.
• Адаптивный дизайн: проектирование интерфейсов под разные устройства и разрешения экрана, понимание сеток и основ HTML/CSS.
• Знание UX/UI: построение удобных пользовательских сценариев, навигации, проведение базового юзабилити-тестирования.
• Базовое понимание кода: не обязательно писать код самостоятельно, но понимать, как работают HTML, CSS и JavaScript, чтобы грамотно общаться с разработчиками и не предлагать решения, которые невозможно реализовать.
• Интерактив и анимация: применение CSS/SVG-анимаций и простых эффектов для повышения вовлеченности пользователей.
• Системное мышление: понимание связи данных, логики и поведения пользователя.

Дизайнеры, которые понимают, как работает код, получают офферы на 30-40% выше рынка. Они говорят с разработчиками на одном языке и экономят недели на правках.

Освоить веб-дизайн с учетом требований 2026 года можно на практических программах — курс по веб-дизайну в Академии ТОП обновляется под актуальные требования рынка и включает работу с адаптивностью, основами кода и UX/UI-проектированием.

Маркетолог

Маркетолог в IT — это связующее звено между продуктом, аудиторией и цифрами. В 2026 году нужно понимать, что стоит за данными, как работает автоматизация и где ИИ действительно помогает.

• Аналитика и данные: умение читать цифры (конверсии, retention, LTV), сегментировать аудиторию по поведению, работать с инструментами аналитики.
• Креатив: генерировать идеи и использовать новые форматы.
• Автоматизация и CRM: настройка email-цепочек, триггерных сообщений, персонализации контента в зависимости от действий пользователя.
• Понимание целевой аудитории: изучение поведения пользователей, построение customer journey map, создание точных предложений на основе данных.
• Личный бренд: активность в digital-среде и профессиональных сообществах.
• Работа с ИИ: умение ставить задачи моделям для генерации контента и проверять результаты на фактические ошибки.
• Системное мышление: понимание того, как маркетинговые решения влияют на продукт, продажи и техподдержку.

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

Для системного понимания digital-маркетинга существуют программы, которые учат работать с данными, автоматизацией и ИИ — курсы по маркетингу в Академии ТОП помогают собрать портфолио под реальные задачи и освоить современные инструменты аналитики.

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

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

Почему программирование важно в 2026 году

1. Основа для работы с ИИ и данными. Продвинутые промты для GPT напоминают программирование. Чтобы интегрировать модель в продукт или дообучить ее, нужно знание языков — например, Python. Дата-аналитик, который умеет писать SQL-запросы и Python-скрипты, обрабатывает данные значительно быстрее того, кто работает только в Excel.
2. Прямое воздействие на бизнес-метрики. Написание скрипта для автоматизации еженедельного отчета экономит восемь человеко-часов в неделю. Создание простого чат-бота на Python снижает нагрузку на службу поддержки на 30%.
3. Язык создания цифровых продуктов. Понимание того, как работают бэкенд и фронтенд, позволяет менеджерам, маркетологам и продуктологам ставить технически грамотные задачи и говорить на одном языке с разработчиками.
4. Страховка от поверхностной автоматизации. No-Code инструменты хорошо решают типовые задачи. Но когда нужна кастомизация, сложная логика или интеграция несовместимых систем, без кода не обойтись. Специалист, который знает код, решает задачи, недоступные другим.

Программирование в 2026 году — это не про то, чтобы стать разработчиком мирового уровня. Это про системное мышление, возможность создавать решения и глубоко влиять на цифровую среду. Это навык для тех, кто хочет не просто адаптироваться к изменениям, а активно влиять на них.

Частые вопросы

Можно ли войти в IT без технического образования?

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

Какие навыки прокачивать в первую очередь?

Базовую цифровую грамотность, аналитическое мышление и умение работать с ИИ. Эти компетенции универсальны и применимы в любом направлении IT.

Насколько важен английский в 2026 году?

На старте достаточно уровня B1 для чтения документации и работы с инструментами. Для международных команд потребуется B2 и выше.

Станут ли ИИ-инструменты угрозой для специалистов?

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

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

Реклама. Рекламодатель АНО ДПО «Академия Топ», ИНН 7730257499, erid: 2W5zFJ5yya8

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

Но теперь эта «шутка» стала наглядной — проект Stacktower превращает рисунок в настоящую визуализацию зависимостей.

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

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

Как работает Stacktower

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

Пользователь может загрузить зависимости своих приложений — например, на Python или JavaScript — и увидеть, что будет, если убрать даже один элемент.

На странице приводится пример для Node.js:

приложение зависит от Express → Express зависит от body-parser → body-parser зависит от qs → и так далее

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

Есть и Python-вариант:

импорт Flask тянет Werkzeug, Jinja2, MarkupSafe, Click и еще несколько пакетов. А те, в свою очередь, имеют собственные зависимости.

Зачем это нужно

Автор подчеркивает: цель проекта — не критиковать экосистемы, а показать их реальное устройство.

Стек современных приложений неизбежно сложен и даже крошечный модуль может стать критически важным. Именно так в 2022 году случайное удаление библиотеки left-pad временно «сломало» огромный кусок JavaScript-мира.

Stacktower превращает эту абстрактную проблему в понятный визуальный эффект: убираешь одну зависимость — рушится вся конструкция.

Комьюнити уже подхватило идею

Проект быстро разошелся по Reddit, Hacker News и X: разработчики делятся скриншотами своих «башен», спорят о хрупкости экосистем и обсуждают, стоит ли пересматривать подход к зависимости.

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

Изучить проект подробнее можно на его странице на GitHub.

Одна из самых жестких рецензий пришла от инженера Apple — Рафаэля Багманова. Он заявил, что книга стала «толще, но не умнее». Больше отвлеченных рассуждений, повторов и риторики, а вот практической пользы — меньше.

По его словам, обновленная версия ощущается как смесь Clean Code, Clean Coder, Clean Architecture и блог-постов Роберта Мартина, но без прежней фокусировки.

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

«Чрезмерные мини-функции» и странные абстракции

Главная претензия Багманова — навязчивый стиль Tiny Functions: функции с одним параметром, длинные имена, множество маленьких методов, вызванных ради избежания комментариев.

Автор критики приводит пример разбора римских чисел: в книге Мартин превращает простую задачу в набор связанных методов и полей класса. Это усложняет код, а не делает его чище.

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

Слабая работа с производительностью и моделированием

Рафаэль Багманов также отметил, что Мартин игнорирует ключевые аспекты разработки:

• производительность падает из-за десятков мелких методов и постоянных аллокаций;
• тесты замедляются из-за передачи данных через поля объекта;
• моделирование домена уступает место механическому применению SOLID.

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

В реальных системах так не работает — налоговые правила зависят от региона, периода и категории товара, а не от «класса предмета».

Комментарии: редкие хорошие примеры и странная позиция

Несмотря на то, что Мартин снова заявляет, что комментарии — «признак провала», книга почти не показывает хороших примеров того, как писать нужные комментарии.

Инженер Apple подчеркивает: в реальном мире комментарии — не зло, а инструмент. И хорошую мысль проще объяснить текстом, чем ломать архитектуру ради самодокументируемости.

Итог: книга стала объемнее, но не глубже

В итоге Багманов пришел к выводу, что второе издание «Чистого кода» скорее разочаровывает. Оно наследует стиль, который не подходит современным языкам и практикам, усиливает слабые стороны первого издания и добавляет многословие без реальных улучшений.

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

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

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

Кем должен быть ML‑специалист — математиком или программистом

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

Сколько математики нужно в ML

Без линейной алгебры, матриц, теории вероятностей и дифференцирования не получится даже понимать, что именно делает модель. Эти базовые знания можно освоить за полгода‑год, но важно не просто формулы выучить, а развить интуицию.

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

Как развиваться в ML и не застрять на старте

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

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

Развитие начинается, когда ты сам задаёшь вопросы вроде «почему слой ведёт себя так», «как меняются веса», «что даёт нормализация». Именно через эти вопросы начинается путь к инженеру, а не к пользователю фреймворков и вайбкодингу.

Что с большими языковыми моделями

Хайп вокруг больших языковых моделей уже выдохся: корпорации гонятся за размерами, а остальные используют их как библиотеку. Это не плохо — эмбеддинги и промты действительно решают прикладные задачи, от резюмирования встреч до автозаполнения CRM.

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

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

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

Какие методы сейчас реально работают

По данным Александра, для бизнес‑задач нет универсального решения, но есть набор проверенных инструментов. Если данные категориальные — лучше использовать градиентный бустинг, например CatBoost или XGBoost. Эти методы часто точнее нейросетей и требуют меньше подгонки.

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

Если данных мало или вычислительных мощностей не хватает, помогает байесовский подход. Он хорошо ведёт себя на шумных и несбалансированных выборках, где другие методы не подходят или не работают. Отдельное направление — оптимизация моделей. Уменьшение моделей через compression позволяет запускать их на обычных серверах без потери точности — актуально для компаний без GPU‑кластеров.

Когда ML действительно нужен

Не любую задачу стоит решать через машинное обучение. Александр объясняет: если алгоритм можно описать правилами, лучше начинать с классики. Но когда формулы не работают — например, при обработке изображений или машинном переводе — подходит ML. Главное, чтобы были данные: сотни или тысячи пар примеров «правильно» и «неправильно». Без них обучение просто не из чего строить.

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

Решение в пользу ML — это не вопрос нового стека, а вопрос наличия данных и понимания задачи. Если подход классических алгоритмов решает проблему быстрее и дешевле, значит, выбираем его.

Что делать, если данных мало

Недостаток данных — это нормальное состояние, полных и сбалансированных выборок почти не бывает. Поэтому разработчику приходится проявлять креатив. Один из способов — генерировать синтетические данные. Например, создавать дополнительные примеры с небольшими изменениями, чтобы модель видела больше разнообразия.

Полезно искать и дополнительные источники сигналов. Если пользователь бросил корзину в интернет‑магазине, это может быть прокси‑признак будущей покупки. Такие косвенные данные часто помогают вытащить модель на нужный уровень точности.

Где ML приносит реальную пользу бизнесу

Александр приводит примеры из практики Bitrix24. Один из самых ощутимых по эффекту — скоринг лидов и сделок. Там используется логистическая регрессия и градиентный бустинг. Метод простой, но позволяет заметно повысить точность прогнозов и напрямую влияет на выручку.

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

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

Пример: текст "машина" при длине шингла 3 даёт набор шинглов: "маш", "аши", "шин", "ина".

Дальше можно сравнивать эти множества и вычислять похожесть, например через коэффициент Жаккара.

В Bitrix24 метод шинглов помогает системе одинаково понимать обращения пользователей на разных языках или с разными формулировками.

Как проверить, что модель действительно работает

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

Дальше важно понимать метрики: precision, recall, F1 и другие. Они показывают, на сколько точно модель попадает в нужные ответы и сколько ложных срабатываний допускает. Не стоит воспринимать метрики как формальности — от них зависит, будет ли решение полезно для бизнеса.

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

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

Какие инструменты и ресурсы использовать

Основная экосистема машинного обучения сегодня крутится вокруг Python, и начинать логично с него. Хороший старт — realpython.com, где подробно объясняются основы языка и приёмы написания читаемого кода.

Но нужно развивать инженерные привычки. Александр рекомендует читать книги вроде Effective Java Джошуа Блоха, чтобы прокачивать культуру разработки и понимать многопоточность. Даже если вы работаете с Python, знания из других языков помогают писать лучше и думать о производительности.

Из библиотек стоит освоить PyTorch или TensorFlow для нейросетей и scikit‑learn для классического ML. При росте нагрузки полезно переписывать критичные части на Java или Rust — это уменьшает задержки и делает систему устойчивее.

Как набраться практики и выбрать правильную команду

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

Идите в крупные компании вроде Яндекса, ВК, Сбера или X5 — там есть инфраструктура, процессы и опытные коллеги. Просто читать статьи и собирать pet‑проекты недостаточно, если не сталкиваешься с настоящими продуктами и их ограничениями.

Главный признак хорошей команды — наличие тестов, QA и понятного кода. Если в отделе этого нет, нужно уходить, иначе быстро потеряешь профессиональный уровень. ML уже давно не чудо‑технология, а инструмент. И успех зависит не от того, кто первым применил нейросеть, а от того, чья команда умеет держать систему в рабочем состоянии и проверять результаты каждый день.

В конце хочется спросить: как вы сами учились или учитесь ML — через курсы, проекты или книги? Делитесь своим опытом и мыслями в комментариях — обсудим, какие подходы к обучению и работе в ML работают сегодня.

Маша Даровская: Это Маша, шеф-редактор Тпрогера. Сегодня у нас очередной выпуск подкаста про хобби айтишников. Будем узнавать, как не выгорать и какими хобби можно наслаждаться в свободное от работы время. Сегодня у нас в гостях Андрей Фёдоров из Люксембурга. Он Java-разработчик и расскажет о своих многочисленных увлечениях. Паркур, DnD, а ещё фотография, кулинария. В общем, Андрей, расскажи немного о себе. Как ты оказался в Люксембурге? Как отдыхаешь там?

Андрей Фёдоров: Ну, всё довольно просто: я оказался в Люксембурге, потому что эмигрировал сюда в 2022 году по работе. В этом смысле мне повезло — на тот момент у меня был совсем небольшой стаж, я отработал всего около года, но меня пригласили сюда, в местную компанию, и полностью перевезли. В этом смысле мне очень повезло, я благодарен судьбе. Сейчас работаю здесь уже три года. И, кстати, именно здесь у меня появились почти все хобби — как ответ на те проблемы, с которыми столкнулся на работе.

Жизнь в Люксембурге: погода, камерность и инфраструктура

Маша Даровская: Расскажи, пожалуйста, как тебе вообще в Люксембурге? Как тебе там всё?

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

Маша Даровская: Понимаю. В принципе, во многих местах бывает такая дождливая погода. А скажи, пожалуйста, Люксембург — это ведь довольно маленькое королевство. Как тебе его камерность?

Андрей Фёдоров: Это очень здорово. Здесь гораздо спокойнее, чем в Москве, где я жил раньше. Я сам родом из Астрахани, и Люксембург напоминает мне лучшее от обоих этих мест. Здесь очень высокий уровень инфраструктуры, есть общественный транспорт. Кстати, Люксембург — единственная страна в мире, кажется, где общественный транспорт полностью бесплатный и для туристов, и для местных жителей. Все поезда, автобусы и трамваи здесь бесплатные. И, действительно, очень спокойно. Многие говорят, что здесь скучно, особенно те, кто любит ходить на дискотеки или в клубы — такие люди отмечают, что мало движения. Но мне это не близко, я ещё в подростковом возрасте понял, что такие развлечения не для меня, поэтому мне здесь хорошо.

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

Социализация и языки в Люксембурге

Маша Даровская: Скажи, пожалуйста, а в Люксембурге тебе хватает общения? Насколько ты смог социализироваться? Как у тебя с коммуникацией, с языком?

Андрей Фёдоров: С каждым годом становится всё лучше. Общение можно разделить на несколько категорий. Во-первых, это русскоязычное общение внутри диаспоры. В первый год после переезда было довольно сложно, потому что не было ни сил, ни особого желания куда-то ходить, искать новых знакомых. Я начал этим заниматься только на втором году и обнаружил, что у нас уже сформировалось сообщество по «Что? Где? Когда?». Я несколько раз там сыграл. Сейчас уже не играю, но иногда выступаю в роли ведущего — читаю вопросы. Я не организатор, а именно ведущий. Это мне близко, потому что в школьные годы я играл в ЧГК около пяти-шести лет.

Потом я узнал, что здесь есть клуб настольных игр, в основном мафии. Я туда ходил, участвовал, общался с людьми, а потом начал сам проводить настольные игры. Именно там познакомился с ребятами, с которыми мы позже начали играть в ДНД офлайн. В плане русскоязычного общения с каждым годом становилось всё лучше, потому что здесь на самом деле довольно много людей. Точных цифр не знаю, но, по моим наблюдениям, в Люксембурге живёт примерно три-пять тысяч русскоязычных. Если говорить о людях, которые входят в мой круг интересов, их всё равно довольно много. К нам иногда приезжают ребята из Трира и других соседних городов за границей Люксембурга. Это что касается русскоязычной части.

Если смотреть на нерусскоязычную, тут тоже есть своя градация, потому что в Люксембурге говорят как минимум на трёх языках. Даже если не учитывать английский, здесь есть французский, немецкий и, собственно, люксембургский. Каждый язык используется в разных контекстах. Например, молодёжь — им по 18–19 лет, кстати, здесь в школе учатся до 20 — между собой часто говорит на люксембургском. Я хожу на паркур, и большинство ребят, с которыми занимаюсь, — подростки. Они постоянно болтают между собой на люксембургском, и я ничего не понимаю. Пока ещё не начал учить этот язык, только зимой собираюсь приступить.

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

Здесь даже есть своеобразная «игра» — познакомиться с люксембуржцем, потому что это довольно сложно. Но, как мне кажется, основная проблема у людей — в подходе. Вместо того чтобы специально искать люксембуржцев, лучше просто ходить в места по интересам и там знакомиться с людьми естественно. Здесь люди в основном знакомятся в спортивных кружках, потому что здесь очень много разных ассоциаций. Я, например, хожу на паркур, но есть ещё футбольные, баскетбольные, теннисные секции, настольный теннис — вариантов действительно много. Это довольно большое пространство, где люди часто встречаются и общаются.

Есть ещё языковые кафе, но там в основном встречаются другие мигранты, которые тоже приехали сюда. Здесь вообще очень много иммигрантов, их часто называют экспатами. Буквально почти половина населения страны — это люди, которые сюда приехали, а не те, кто здесь родился и вырос. Точную статистику я не знаю, но, кажется, граждан здесь примерно половина населения. Остальные — это экспаты, и, по-моему, в статистику не входят те, кто приезжает сюда каждый день, но не живёт здесь постоянно. В общем, на неродном языке общаться немного сложнее, у меня эта часть пока ещё проседает.

Сейчас я участвую в организации айтишных митапов в Люксембурге — они называются Lux Tech Pulse. Раньше это был Luxembourg Jazz, но теперь мероприятие расширилось и охватывает разные направления. Там я постепенно знакомлюсь с людьми, которые говорят не только по-русски. В остальном, возможно, я просто не так часто бываю в местах, где можно познакомиться с новыми людьми. Работу я не беру в счёт — я познакомился со всеми своими тридцатью коллегами, и на этом всё. Но это довольно ограниченный круг знакомств.

Работа и команда

Маша Даровская: А чем, кстати, занимается твоя компания, и на каком языке вы общаетесь в команде?

Андрей Фёдоров: Я бы не назвал это стартапом. Это компания, которой уже около шестнадцати лет, она давно вышла из стадии стартапа — по крайней мере, так говорит наш SEO. Это люксембургская компания, основная часть находится в Люксембурге. Мы занимаемся продуктами для финтеха. Есть несколько решений для аутентификации пользователей, а также продукт, похожий на WhatsApp, только более безопасный: компании могут хранить данные у себя, сами хостят сервер. Я работаю в третьей команде, которая занимается кастомными решениями для клиентов — не внутренними продуктами, а разработкой на заказ для других компаний.

Маша Даровская: Поняла. А на каком языке вы общаетесь? На английском?

Андрей Фёдоров: Да, у нас в компании основным языком общения является английский, и это очень удобно. Мы как-то подсчитывали: на тот момент у нас было около четырнадцати или пятнадцати разных национальностей. Есть ребята из СНГ — украинцы, россияне, парень из Молдовы, есть коллеги из Индии, несколько человек из Люксембурга, из Франции, из Германии, из Латинской Америки тоже были ребята. В общем, команда очень интернациональная. Здорово, что английский стал общим языком — он действительно поддерживает мультикультурную среду.

Маша Даровская: Да, это язык для общения между представителями разных культур.

Андрей Фёдоров: В этом смысле в Люксембурге с английским и другими языками проще. Здесь много людей, для которых эти языки не родные, они их учили. И, по крайней мере, с английским нет такого, что тебя стыдят за неправильное произношение или что-то подобное. Все говорят по-разному и стараются понять друг друга.

Паркур: от боли в спине к удовольствию

Маша Даровская: А расскажи, как у тебя появились хобби в Люксембурге? Ты говорил, что только на второй год начал активно общаться. Почему решил заняться паркуром? Какой у тебя вообще спортивный бэкграунд?

Андрей Фёдоров: Паркуром я занялся потому, что у меня болела спина — это короткий ответ. А если подробнее, то особого спортивного бэкграунда у меня нет. Обычное детство, наверное, как у многих парней, которые выросли не в Москве, а просто где-то в России. Не знаю, как в Москве, а я в детстве бегал по дворам, лазил по крышам гаражей, забирался в подъезды — просто ради интереса, ничего не выносил. Мне это нравилось, и, в общем-то, на этом всё. Когда я приехал сюда, первый год был сложным — все силы уходили на адаптацию, нужно было понять, как здесь вообще жить. То есть, какие здесь вообще правила? Как, например, с документами: куда их нужно относить, где получать, какие базовые вещи нужно настроить, чтобы просто нормально жить.

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

Я продолжил искать и в какой-то момент начал смотреть на YouTube видео о мировых соревнованиях по паркуру. Подумал: «Ммм, классно». На самом деле, это называлось Chazen Tech — что-то вроде догонялок, только с элементами паркура: нужно прыгать через препятствия. Я подумал, что это очень прикольная штука, захотел попробовать, и стал размышлять, чему нужно научиться, чтобы участвовать в таких соревнованиях. Понял, что для начала нужен паркур — хотя бы чтобы не сломать себе шею в процессе.

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

Занятия проходят очень весело: два часа пролетают незаметно, будто оказываешься внутри компьютерной игры, которая нравилась с детства. Мне всегда нравилась серия Assassin’s Creed, где герои лазают по стенам, бегают по крышам и тайно устраняют злодеев. Я часто представлял себя на их месте — бегаю, прыгаю, преодолеваю препятствия. В зале это особенно классно: есть специальный инвентарь, боксы разной высоты, на которые можно залезать и прыгать, есть маты для безопасного приземления. Первый раз, когда сделал сальто, ощущения были как в игре — не успеваешь даже понять, как делаешь кувырок, всё вокруг на мгновение размывается, голова кружится. Это чем-то напоминает Mirror’s Edge — есть такая игра про паркур, бег по стенам, прыжки туда-сюда. Это очень весело. И, главное, благодаря этому у меня не болит спина. Когда я не занимаюсь, например, вот сейчас летом был перерыв, у меня начинает хрустеть вся спина. Я могу потянуться вправо или влево — и слышу, как будто пузырьки воздуха лопаются. А когда я хожу на паркур, ничего не хрустит, как бы я ни тянулся.

Маша Даровская: Да, я тебя понимаю. У меня тоже сидячая работа, и без спортзала спина просто отказывает. Скажи, пожалуйста, как проходят твои тренировки и сколько это стоит в Люксембурге?

Андрей Фёдоров: Паркур здесь стоит очень дёшево. На самом деле, большинство спортивных секций недорогие, потому что их организуют что-то вроде НКО — Ассоциации Федерации Спорта. Например, за сезон, который длится с сентября по июль, то есть почти весь год, я плачу 100 евро. По люксембургским меркам это совсем немного. Для сравнения, месяц занятий йогой стоит столько же, потому что в Люксембурге у йоги нет ассоциации, и там только индивидуальные занятия. А тренировки по паркуру у нас проходят так: обычно это двухчасовое занятие. Первый час тренировки проходит с тренером: он учит нас определённым движениям. Второй час — свободный, можно взять любой инвентарь, который лежит в зале, расставить его как угодно и тренировать что-то своё.

Маша Даровская: Скажи, а сколько у тебя в среднем тренировок в неделю?

Андрей Фёдоров: Здесь только одна тренировка по паркуру. Пока мне этого достаточно — это всё же лучше, чем ничего. Ну, что есть.

Настольные игры и D&D-сообщество

Маша Даровская: Ты говорил, что сначала участвовал в мафии, не организовывал, а именно участвовал. Я так понимаю, это вообще популярная тема среди мигрантов — играть в мафию, потому что…

Андрей Фёдоров: Да, но мне мафия, честно говоря, не нравится.

Маша Даровская: Я тоже не очень люблю, если честно. А потом ты организовал сообщество для тех, кто играет офлайн в ДНД. Расскажешь подробнее?

Андрей Фёдоров: На самом деле, мы играем офлайн не только в ДНД, а вообще в разные настольные игры. У нас есть большое сообщество, где ребята собираются на мафию, но также устраивают и другие активности: ходят в походы, иногда в театр, сейчас вот книжный клуб появился. Как часть этого сообщества я в какой-то момент начал проводить настольные игры. Даже организовал небольшой фестиваль на 35 человек: собрал кучу разных настолок, некоторые взял у знакомых, чтобы все могли прийти и попробовать что-то новое. Для тех, кто раньше не играл, часто кажется, что настолки — это сложно и непонятно. Ой, когда слышишь, что в какую-то игру нужно играть час или даже два, становится немного страшно. А бывает и все пять часов.

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

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

После этого я начал проводить ваншоты — односессионные игры для совсем новичков. Проводил такие игры и для детей, например, для двенадцатилетних, и для взрослых тоже, просто чтобы показать людям, как это устроено. Мне хотелось, чтобы число людей, которые хотят играть в D&D здесь, в Люксембурге, росло. Тогда можно будет делать что-то более интересное. Чем больше игроков и мастеров, тем больше всего интересного мы можем вместе придумать. Это ещё и отличный способ знакомиться с новыми людьми. Например, тот год, когда мы играли в кампанию, по сути, подарил мне новых друзей — людей, с которыми я вряд ли бы познакомился иначе, потому что мы из разных возрастных групп: некоторые ребята на двадцать, а то и на тридцать лет старше меня. У них совсем другие заботы, профессии, и в обычной жизни мы, возможно, даже не пересеклись бы, или это было бы как-то странно и непривычно. А когда вы год за одним столом играете, отыгрываете разных персонажей, попадаете в комичные или даже кроваво-комичные ситуации, вы сближаетесь и начинаете общаться уже как настоящие друзья.

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

Параллельно с этим я решил, что хочу попробовать сделать то же самое онлайн. Нашёл программу Foundry VTT — если кому-то интересно. Думаю, в предыдущем выпуске вы уже упоминали об этом, когда говорили про ДНД. Я сохранил тот выпуск, хотел посмотреть, потому что видел там Сашу Бриганова и подумал: интересно, надо послушать, что он рассказывает, а то я его только в Твиттере читаю. В итоге я скинулся с несколькими ребятами, они мне задонатили, и я купил лицензию. Подумал, что не хочу, чтобы каждый мастер сам покупал лицензию на эту программу и разбирался, как всё установить и развернуть.

Я подумал: почему бы не создать сообщество, общий сервер, где буду я и ещё несколько админов? Мы бы решали все технические вопросы — как установить систему, как перенести её на более дешёвый сервер, как мигрировать и обновлять данные и так далее. А мастерам и игрокам просто предоставили бы возможность собираться и играть. Ведь онлайн-игры — отличный способ вновь связаться с друзьями, которые живут в других городах. Мы с друзьями уже играли в разные случайные мультиплеерные игры с 2022 года, в основном через Discord. Но это бывает непросто, особенно если речь о играх, которые быстро устаревают и теряют интерес. А вот такие игры, где нужно импровизировать и общаться, по сути, не стареют. Благодаря этому я стал снова больше общаться с несколькими старыми друзьями. Один из них даже присоединился ко мне, и теперь мы вместе развиваем это сообщество.

Сейчас у нас уже около 80 человек в Telegram-канале. Мы запустили проект в апреле, и за это время провели, наверное, около 10–15 игр, точно не помню. Сообщество постепенно растёт, и это очень радует. Я вижу, как люди, которые иначе никогда бы не встретились — потому что живут в разных частях мира, — знакомятся, начинают вместе играть, и это действительно здорово.

Любимые настольные игры

Андрей Фёдоров: Я играю в настольные игры ещё с университета. Мы с соседом и другом по комнате оба увлекались настолками и часто собирались поиграть. Моя любимая игра — «Каркассон». У меня большая коробка с, наверное, десятью разными дополнениями. Мы с женой регулярно играем, несколько раз в месяц, и с друзьями тоже собираемся. В нашей библиотеке есть ещё одна игра — «Страшные сказки». Это простая карточная игра, подходит для двоих и до четырёх человек. Ещё есть игра, которую я люблю с детства, потому что играл в неё с дедушкой. Она называется «Реверси». Это что-то вроде го, только гораздо проще.

Есть ещё классная старая игра — Scotland Yard. Она до сих пор популярна, в неё играют. Мне нравится, что там асимметричный геймплей: один игрок — шпион, остальные — детективы, которые его ловят. Все знают, кто шпион, но пытаются поймать его в Лондоне. Интересная дедуктивная игра, отлично подходит для любителей детективов. Попробовать просчитать, куда пошёл человек, где он сейчас находится — это интересная задача. Есть ещё две игры, которые я бы выделил. Одна из них называется «Азул». Она отлично подходит для двух-четырёх игроков. Мне особенно нравится её тактильность: там есть такие плиточки, которые нужно доставать из тканевого мешочка. Это просто приятно — держать их в руках, играть с друзьями, просчитывать ходы.

Другая игра — «Палео». Это кооперативная игра, а таких мне встречалось не так много, где вы играете не друг против друга, а против самой игры. Она как раз хорошо подходит для вечера вдвоём, например, с женой. Вместо соперничества вы действуете вместе. Сюжет такой: у вас есть доисторическое племя, и ваша задача — оставить след в истории, просто выжить и не вымереть. Есть ещё игры, которые мне нравятся, но которых у меня сейчас нет, потому что не удалось их перевезти. Например, «Рут» — тоже асимметричная игра. Или «Битва за Рокуган». Это не самые известные игры, но они действительно интересные.

Маша Даровская: Из кооперативных мне нравится «Таинственный остров», но, по-моему, она только на русском.

Андрей Фёдоров: Не слышал про такую. Есть такая игра — «Эволюция», она была придумана в России. Это, кстати, непросто, потому что мне она тоже очень нравится. Но на английском, насколько я знаю, её вообще нигде не найти. Получается, с друзьями, которые не говорят по-русски, в неё не поиграть.

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

Андрей Фёдоров: Точно сказать сложно. Для меня настолки — это и способ провести время, и возможность пообщаться. В среднем, наверное, играю несколько раз в месяц. Если говорить именно о настольно-ролевых играх, например, D&D, то с тех пор, как я начал заниматься онлайн-сообществом, сам стал играть чуть меньше — времени уходит много на организацию: нужно искать мастеров, игроков, помогать им всё настроить, проверить, что всё работает. Это занимает довольно много времени. Здесь, офлайн, я сейчас веду кампанию как мастер, но летом, честно говоря, это просто мёртвый сезон для многих активностей — все разъезжаются, у всех разные графики. Через две недели у нас наконец будет следующая сессия. Надеюсь, мы хотя бы раз в месяц сможем собираться, потому что у нас уже шутка ходит: самое страшное в D&D — это не боссы и не правила, а попытка состыковать графики пяти или шести взрослых людей.

Маша Даровская: Да, да, да, вот именно это меня и пугает в идее начать играть в D&D — где найти время?

Андрей Фёдоров: Это, кстати, одна из причин, почему я начал проводить игры онлайн. Оффлайн эта проблема стояла особенно остро. Например, у нас в Люксембурге всего, допустим, пятнадцать человек, которые хотят играть. Это буквально две-три, максимум четыре группы, а по факту — одна-две. И все заняты: у кого-то дети, у кого-то командировки, у всех свои дела, и состыковаться очень сложно. В онлайне проще: у тебя гораздо больше людей на выбор, и если нет принципиального требования играть именно с конкретным другом, найти компанию становится легче. Просто размещаешь объявление: такая-то игра, столько-то человек. Собираются пять человек, которые раньше друг друга не знали — и начинают играть. В принципе, это работает, я бы сказал. Дальше всё зависит от запроса. Для игр, ваншотов — это вообще отлично подходит, можно легко находить такие игры. Для компаний, конечно, сложнее. Вы один раз собрались, совпали по дате, а потом, когда наступает следующая сессия, снова возникает вопрос — как состыковаться. Тут уже становятся необходимы всякие сервисы для синхронизации календарей.

Кулинария и творчество

Маша Даровская: Скажи, кроме паркура и игр, ты ещё говорил, что любишь готовить. Это увлечение появилось у тебя в Люксембурге или раньше?

Андрей Фёдоров: Наверное, скорее здесь, в Люксембурге, потому что у меня стало больше времени дома. Когда я жил в Москве, большую часть времени я проводил в общаге, и там было сложно готовить что-то особенное. Помню, как-то летом я готовил шаурму и продавал её другим в общаге. Но это быстро надоело — за несколько дней я полностью вымотался и понял, что прибыль того не стоит. До переезда я не так много готовил. То есть, я любил готовить, но в основном обычные блюда. Например, блины — у нас в семье я блинный мастер. Какие-то мясные блюда — и не больше.

А здесь, когда мы переехали, у нас появилось гораздо больше возможностей попробовать разные кухни. Для нас это стало настоящим открытием. Не знаю, может, у меня вообще переезд получился не дауншифтинг, а скорее наоборот — если использовать это слово, то скорее upshifting. В общем, уровень жизни повысился: зарплата относительно расходов стала больше, а еда, по моим ощущениям, не сильно дороже. Поэтому мы начали ходить в разные места, пробовать новую еду, и мне захотелось повторять эти блюда дома. Например, мы несколько раз ездили в Грецию, пробовали там разные блюда с бобами, с фетой — это было очень вкусно, и захотелось научиться готовить такое самому.

Иногда можно просто найти рецепт в интернете, а иногда интересно прийти в кафе, заказать блюдо и, пока ешь, пытаться понять, как его приготовили. В какой-то момент я очень увлёкся приготовлением пиццы. Сейчас, скажем так, немного остыл — не потому что разонравилось, а просто жду, когда перееду в другое место, где будет балкон или терраса. Хочется купить специальную печь для пиццы, которую можно поставить на улице. Сейчас я немного устал делать пиццу в духовке, потому что всегда старался готовить её практически с нуля. Тесто нужно оставить в холодильнике на ночь, чтобы оно как следует подошло — шарики, всё как надо. Это классно, но занимает очень много времени.

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

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

Я пробовал вести YouTube-канал, где частично показывал бы сам процесс и просто болтал на разные темы, но быстро понял, что это не для меня. Оказалось, у меня просто не хватает времени и сил, чтобы заниматься монтажом самостоятельно. Я уже забыл, как это делается. Лет десять назад я монтировал видео, когда работал фотографом и параллельно снимал ролики, но сейчас полностью утратил эти навыки. Я понимаю, что тратить несколько часов на съёмку, а потом ещё в четыре раза больше на монтаж — мне этого совсем не хочется. Да, когда становишься взрослым, приходится расставлять приоритеты.

Маша Даровская: А какие-то видео с готовкой у тебя остались?

Андрей Фёдоров: Да, что-то осталось. Буквально три штуки, наверное. Я довольно быстро понял, что всё идёт не так, как мне хотелось бы. При этом, конечно, родители моей жены очень ждут новых видео. Они постоянно спрашивают: «Андрей, когда следующее?» А я им отвечаю: «Блин, не знаю, это слишком сложно и долго». Но у меня вообще с YouTube есть своя история. Лет в четырнадцать я уже делал канал, пытался что-то записывать и выкладывать. Я специально с тех пор ничего не удаляю — для меня это часть своего рода наследия. Просто интересно потом посмотреть, что было тогда, что сейчас, и, надеюсь, порадоваться изменениям.

Баланс хобби и советы слушателям

Андрей Фёдоров: Я для себя это когда-то описал как разные корзинки. Представляю себе такую картину: есть игра, в которую я сам никогда не играл, но знаю — советская электроника, где волк ловит яйца. Он бегает вправо-влево и ловит яйца, чтобы они не разбились. Вот примерно так я ещё в школе представлял себе жизнь: как совокупность разных активностей. Вместо того чтобы стоять на одном месте и собирать всё только там, ты постоянно переключаешься — тут немного, там немного. В итоге жизнь получается сбалансированной по разным направлениям. В какой-то период ты больше занимаешься одним делом, потом берёшь паузу и подтягиваешь другие направления. В результате всё идёт довольно ровно и разнообразно. Это действительно помогает не выгорать, потому что активность постоянно меняется.

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

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

А музыка помогает — не знаю, позволяет выплеснуть творческий порыв. Не могу сказать, что на работе этого не происходит: там тоже много творчества, когда придумываешь, как реализовать что-то. Особенно мне повезло в том, что у меня есть право голоса — могу спрашивать: «А почему вы этого хотите? А чего конкретно хотите достичь?» Иногда даже предлагать альтернативы. Это тоже своего рода творчество. Но музыка помогает именно выражать эмоции. Кроме того, что я сам иногда играю на гитаре или сочиняю песни, я много просто пою — включаю музыку и пою. Это у меня с детства. И это помогает нормализовать эмоциональное состояние, потому что с некоторыми песнями, которые откликаются, ты выплёскиваешь накопившиеся эмоции, и становится легче.

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

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

Маша Даровская: А всё остальное — дело техники. Я, например, окончила музыкальную школу, но у меня низкий голос, и всё, что высоко, мне просто не даётся. Таких песен, которые можно петь низко, на самом деле не так много, их мало. Поэтому — как есть. Колыбельную петь научилась, уже хорошо. Скажи, пожалуйста, что бы ты мог пожелать нашим слушателям? Как найти себя, своё увлечение, как не потерять себя в этом безумном мире, когда всё вокруг бывает сложно?

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

Маша Даровская: Да, согласна. Главное — пробовать и ждать, что отзовётся внутри, что действительно откликнется. Спасибо тебе большое. Ребята, с нами сегодня был замечательный Андрей Фёдоров. Он рассказал много интересного о своих увлечениях. Ищите свои хобби, своё призвание — то, что действительно приносит вам удовольствие. Не выгорайте. Пусть у всех всё будет хорошо.

Компания представила официальный Swift SDK для Android, позволяющий писать нативные Android-приложения на фирменном языке, изначально созданном для iOS и macOS.

От iPhone до Android

Swift появился в 2014 году как альтернатива Objective-C — более безопасный, современный и лаконичный язык для экосистемы Apple.

За 11 лет он вырос из «внутреннего» инструмента в многофункциональную платформу, на которой создают облачные сервисы, десктопные приложения для Windows и даже прошивки для микроконтроллеров.

Теперь Swift впервые официально выходит за пределы «яблочной экосистемы. Превью-версия SDK для Android доступна уже сегодня — в составе Swift-инсталлятора для Windows или отдельно для macOS и Linux.

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

Новый SDK — результат многомесячной работы Swift Android Workgroup, открытого сообщества, куда может присоединиться любой разработчик. С его помощью можно:

• собирать нативные Android-приложения на Swift;
• переносить существующие Swift-пакеты — более 25% уже совместимы с Android;
• интегрировать Swift-код с Java через проект swift-java, автоматически генерирующий безопасные биндинги между языками.

Apple опубликовала подробное руководство «Getting Started» и примеры кода, демонстрирующие полный цикл разработки Android-приложений на Swift.

Что это значит для экосистемы

Релиз открывает дорогу к кроссплатформенным приложениям без использования Flutter, Kotlin Multiplatform или React Native.

Теперь компании смогут писать бизнес-логику один раз на Swift и использовать ее и в iOS-, и в Android-версиях.

Эксперты отмечают, что шаг Apple может снизить барьеры между мобильными экосистемами и ускорить развитие open-source сообщества Swift.

Что дальше

По словам участников проекта, впереди — создание полноценного Android-Toolchain, улучшение совместимости со средами разработки и официальное внедрение CI-сборок.

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

«Swift вырос из языка для iOS в универсальный инструмент для всего программного мира. Теперь он будет жить и в Android-экосистеме», — говорится в сообщении разработчиков.

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

Почему это плохо

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

Это приводит к тому, что:

• невозможно использовать тип в интерфейсах других пакетов;
• ломается архитектура и DI (dependency injection);
• документация GoDoc не видит такие типы;
• код становится неидиоматичным и сбивает с толку других разработчиков.

Правильный подход

Правильный подход

Go поощряет простую инициализацию структур. Многие стандартные типы например,

работают корректно без конструктора. Для сложных сервисов используйте именованные конструкторы, которые проверяют зависимости и возвращают ошибку при некорректной инициализации. Это — идиоматичный путь Go: лучше обработать ошибку явно, чем скрывать её за “удобством”.

service, err := NewDomainService(cfg, deps)

if err != nil {

log.Fatal(err)

}

Итог

Экспортировать приватные типы — соблазнительно, но опасно. Это разрушает архитектуру и противоречит философии Go. Используйте приватные структуры только внутри пакета и придерживайтесь идиоматичных решений — они делают ваш код безопаснее и понятнее.

Источник статьи наш блог, опыт разработчика Webdelo

Вы его не перезапускали. Код не меняли. Но внезапно — без предупреждения — оно начинает писать:

Никаких рестартов. Никаких деплоев. Никакого git pull. Просто… поменялось.

Звучит как фокус? Но это — настоящая инструментация JVM, доступная каждому. И сегодня я покажу, как подключиться к живой JVM, загрузить свой агент и изменить поведение класса — без единой строчки в исходнике. Да, даже если метод final. (если только он не static final).

Это рантайм, а не компиляция

Допустим, по описанному примеру выше, у нас есть простой сервис:

Он вызывается в бесконечном цикле:

Приложение работает. Состояние в памяти. Соединения открыты. Кэши разогреты.

А мы хотим поменять сообщение. Прямо сейчас. Без перезапуска.

Перезапуск — это потеря данных, времени, пользовательских сессий. А что, если можно просто… заменить реализацию?

Как это вообще возможно?

Java — не такой уж статичный язык, как кажется.

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

• IDE для HotSwap
• Mockito — чтобы мокать final классы
  
• Lombok — хотя чаще на этапе компиляции
  
• Spring AOP — через CGLIB-прокси
  
• OpenTelemetry, Datadog, New Relic — для трассировки без изменения кода
  

Всё это работает благодаря java.lang.instrument.Instrumentation — API, которое позволяет:

• Перехватывать загрузку классов (ClassFileTransformer)
• Изменять байт-код на лету
  
• Заменять реализации методов через redefineClasses() или retransformClasses()
  

Но чтобы получить доступ к Instrumentation, нужно войти внутрь целевой JVM.

Этап 1: Подключение к JVM — Attach API

JVM позволяет «прицепиться» к себе извне — через Attach API.

Да, это как ssh, но для Java-процесса. Вы находите PID (jps, ps aux | grep java), подключаетесь — и получаете полный контроль.

Через loadAgent() вы загружаете JAR-файл, который выполнится внутри целевого приложения. И самое важное: этот агент может получить экземпляр Instrumentation.

Этап 2: Агент с правами root

У Java-агента особая точка входа — agentmain, а не main:

Как только агент загружен, он может:

• Регистрировать ClassFileTransformer
• Модифицировать байт-код уже загруженных классов
  
• Заменять методы, поля, аннотации
  

И всё это — без перезапуска.

Этап 3: Меняем getMessage() на лету

С помощью [Byte Buddy](https://bytebuddy.net/) (обёртка над ASM) это выглядит почти как обычный Java-код:

Что происходит?

1. Мы ищем MessageService среди всех загруженных классов.
2. Проверяем, что его можно переопределять (isModifiableClass).
   
3. Через Byte Buddy заменяем тело getMessage() на константу.
   
4. Генерируем новый байт-код.
   
5. Передаём его JVM через redefineClasses().

И вот — следующий вызов getMessage() уже возвращает "Hello from Agent!". Без прокси. Без интерфейсов. Без рефлексии. Прямая замена байт-кода.

Почему это важно? Потому что это не обёртка, а это оригинальный класс, но с другим телом метода.

Где это реально применяется?

Именно такой подход лежит в основе множества современных Java-инструментов:

• Spring AOP — создаёт CGLIB-прокси, например для @Transactional, @Cacheable.
• Mockito — мокает final классы через Byte Buddy
  
• APM-агенты (OpenTelemetry, Datadog) — внедряют трассировку в HTTP-клиенты, БД-драйверы.
  

Все они используют те же самые механизмы. Эта возможность особенно мощна при работе с динамически генерируемыми классами. Например, когда Spring создаёт CGLIB-прокси для @Transactional-бинов, этот класс появляется в памяти во время выполнения. Ваш ClassFileTransformer может перехватить его загрузку и добавить логирование, метрики или аудит.

APM-системы именно так и работают: они не требуют изменения кода, но умеют измерять время выполнения методов, SQL-запросов, HTTP-вызовов — потому что могут модифицировать байт-код на лету.

Реальные трудности: что может пойти не так?

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

🔹 "Agent JAR not found or no Agent-Class attribute"

> Причина: jar собирался без MANIFEST.MF. Также возможно, если в MANIFEST.MF не указать Agent-Class или путь к jar.

> Решение: добавил в pom.xml явное указание манифеста через maven-jar-plugin.

🔹 "Agent JAR loaded but agent failed to initialize"

> Причина: агент зависел от ByteBuddy, но зависимости не были встроены в JAR.

> Решение: перешёл на maven-shade-plugin — собрал fat-jar со всеми зависимостями.

🔹 "Cannot inject already loaded type"

> Причина: Я использовал .load(classLoader) после redefine, где пытался загрузить класс, а не переопределить.

> Решение: убрал .load(...), и вместо этого применил inst.redefineClasses(...) — ведь redefine не загружает, а заменяет существующий класс.

🔹 Динамический attach в будущем будет отключён по умолчанию

В новых версиях Java появляются предупреждения:

Я тестировал на JDK 23. Возможно уже есть решение или потребуется использовать флаг -XX:+EnableDynamicAgentLoading.

Заключение

Java — это не только язык. Это платформа, которую можно программировать извне.

Знание java.lang.instrument, attach, redefine и работы с байт-кодом — это отдельный уровень мастерства.

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

Spring, Mockito, Lombok, OpenTelemetry — все они используют эти же механизмы. А теперь вы знаете, как они работают. И можете написать свой.

Код проекта на github:

Проект состоит из:

• target-app — целевое приложение («жертва»)
• hotswap-agent — агент для изменения классов на лету
  
• attach-client — клиент для подключения к JVM
  

P.S. А вы когда-нибудь писали свой Java-агент? Делитесь в комментариях!

• джунам, которые выбирают первый стек технологий;
• мидлам, которые хотят сравнить свой опыт с коллегами;
• сеньорам, которые подбирают инструменты под новый проект.

Вы узнаете — какие библиотеки и фреймворки выручают Java-разработчиков в 2025 году. Игорь Казаков, Константин Шибков и Вадим Федосеев рассказали, почему джависты предпочитают конкретный инструмент, для каких задач он удобен и на что обращать внимание при выборе.

Чем фреймворк отличается от библиотеки?

Библиотека работает как набор инструментов.

Хотите парсить JSON? Подключаете Jackson. Нужно логирование? Добавляете SLF4J. Вы решаете, когда и как использовать код библиотеки.

Фреймворк задаёт структуру приложения.

К примеру, Spring Boot — он запускает ваше приложение, создаёт контекст, инжектит зависимости. Хотите вы или нет, но придётся писать контроллеры, сервисы и репозитории по правилам фреймворка.

Некоторые фреймворки можно использовать как библиотеки. Например, Hibernate — с ним работают как с библиотекой для маппинга объектов или как с полноценным фреймворком с управлением сессиями и жизненным циклом. Выбор зависит от задачи и предпочтений команды.

На что смотрят профи, когда выбирают Java-фреймворк?

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

Игорь Казаков, Lead Software Engineer (Java), при выборе инструмента оценивает:

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

Отдельно он подчёркивает модульность и обратную совместимость — никто не хочет переписывать половину проекта после обновления версии.

Константин Шибков, Java-разработчик, ждёт от фреймворка следующее:

Жду от идеального фреймворка регулярные релизы с поддержкой новых технологий и версий языка, простое подключение модулей и понятный путь при миграции до новых мажорных версий. Идеальный фреймворк закрывает 80% типовых задач без бойлерплейта и лишней магии. Заложенная безопасность, готовая россыпь метрик его работы, обратная связь с командой разработки — это обязательные элементы отличного инструмента.

1. Spring Boot

Spring — это целая экосистема фреймворков. Spring Boot — один из его фреймворков. При работе с SB вы используете «стартеры», которые автоматически создают бины для компонентов Spring.

Фреймворк определяет, какие библиотеки вы используете, и самостоятельно их настраивает. Если подключите базу данных, Spring Boot создаст пул соединений, добавите веб-зависимость — получите встроенный Tomcat-сервер. Любую автоматическую настройку можно переопределить.

Spring Boot выбирают для разработки:

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

Spring Boot — самый распространённый фундамент любого бекэнд приложения. В большинстве вакансий я вижу именно SB. Фреймворк отлично сочетает рабочие библиотеки, хорошо описан и даёт достаточно контроля.

Новичкам советую начать именно со Spring Boot. Даже если проект в итоге не потребует всего функционала, вы получите отличное понимание современных практик Java-разработки, а также сможете быстро написать приложение без копания в тоннах документации и бесконечных отладок кода.

2. Hibernate

Фреймворк связывает Java-объекты с таблицами в базе данных. Вместо написания SQL-запросов вы работаете с обычными классами и методами.

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

Инструмент рекомендуют для разработки типичных бизнес-приложений с CRUD-операциями. Hibernate автоматически генерирует SQL, управляет транзакциями и кеширует данные. Вы пишете user.save() — фреймворк сам создаёт INSERT-запрос и выполняет его.

Иногда складывается обманчивое впечатление, когда запуск простого приложения на фреймворке — это задача 5 минут. Hibernate достаточно прост для создания CRUD приложения. Но когда нужны сложные связи между таблицами, особые типы данных или непростые выборки данных, в этих случаях фреймворк начинает «давить» на разработчика ограничениями и неявными правилами, которые были скрыты в угоду удобства.

3. Jackson

Библиотека превращает Java-объекты в JSON и обратно. Работает через аннотации — вешаете @JsonProperty на поле, и Jackson понимает, как его назвать в JSON.

Нужно игнорировать какое-то поле? Добавили @JsonIgnore и забыли. При этом Jackson умеет работать даже без аннотаций — просто смотрит на геттеры и сеттеры вашего класса.

Jackson стабилен, гибок и незаменим в работе с JSON.

Базовый модуль работает с JSON, но можно подключить дополнительные: для XML, YAML, CSV. Один и тот же код сериализует объекты в разные форматы. Ещё Jackson дружит с Java 8+ фичами через отдельный модуль.

Библиотека пригодится, когда пишете REST API, работаете с конфигурационными файлами или интегрируетесь с внешними сервисами. Spring Boot использует Jackson по умолчанию — все @RestController автоматически отдают JSON через него.

4. JUnit

Больше 20 лет JUnit лидирует среди фреймворков для тестирования Java-приложений. Разработчики выбирают его за простоту и скорость написания тестов — достаточно поставить аннотацию @Test над методом, и он превращается в полноценный тест.

JUnit — это модульные тесты через простую аннотационную модель, интеграция с IDE и средами сборки.

Фреймворк выручает при рефакторинге старого кода. Написали тесты на существующую логику — можете менять реализацию. Тесты покажут, если что-то сломалось.

JUnit 5 добавил параметризованные тесты: один тестовый метод проверяет сразу десяток разных входных данных.

К Spring Boot обязательно беру JUnit + AssertJ, Mockito и Testcontainers — вместе они обеспечивают реалистичные интеграционные тесты и быстрый фидбек в CI.

5. MapStruct

Библиотека генерирует код маппинга между Java-объектами во время компиляции. Вместо ручного переписывания полей из одного объекта в другой, вы пишете простой интерфейс с аннотациями — MapStruct создаёт реализацию автоматически.

Не представляю быструю реализацию мапперов без MapStruct. Библиотека избавляет от сотен строк шаблонного кода и ошибок при преобразовании DTO< ->Entity.

MapStruct изящно решает рутинную задачу преобразования объектов без магии и просадок производительности.

6. Lombok

Библиотека автоматически генерирует повторяющийся код через аннотации. Вместо того, чтобы писать геттеры, сеттеры, конструкторы и методы equals/hashCode руками, вы просто ставите аннотацию @Data над классом.

Lombok экономит время: помогает писать код чище.

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

Jackson и Lombok — стандарт для энтерпрайза, без них не обходится ни один проект. Lombok не идеален, но сильно сокращает шаблонный код и делает DTO более читаемыми, позволяет сосредоточиться на бизнес-логике.

7. Testcontainers

Testcontainers решает классическую проблему: как протестировать код, который работает с базой данных или внешними сервисами? Библиотека запускает настоящие Docker-контейнеры прямо из тестов — PostgreSQL, Redis, Kafka, что угодно. Тесты получают реальное окружение вместо заглушек и моков.

Контейнеры живут ровно столько, сколько выполняются тесты. Запустил тест — поднялась база, прошёл тест — контейнер удалился.

Testcontainers выручает при:

• интеграционном тестировании с реальными базами данных,
• проверке миграций и SQL-запросов,
• тестировании микросервисов с брокерами сообщений,
• работе с NoSQL-хранилищами.

JUnit 5 с Jupiter API — стандарт для тестирования. Особенно в связке с Testcontainers — это очень важный инструмент.

8. Micronaut

Фреймворк компилирует магию dependency injection на этапе сборки, а не во время запуска приложения. Ваш сервис стартует за 1-2 секунды вместо привычных 10-30 секунд у Spring Boot. Типичное приложение съедает 50-100 МБ вместо нескольких сотен.

Фреймворк рекомендуют в трёх случаях:

• Пишете микросервисы и устали ждать перезапуска при каждом изменении.
• Разворачиваете приложения в AWS Lambda, Google Cloud Functions.
• Платите за облачные ресурсы и хотите сэкономить на железе.

Micronaut поддерживает реактивное программирование из коробки, дружит с GraalVM и компилируется в нативные образы. При этом синтаксис остаётся знакомым — те же аннотации @Controller, @Service, @Repository, что и в Spring.

9. Quarkus

Фреймворк компилирует код в нативные исполняемые файлы через GraalVM. Ещё Quarkus работает с микросервисами и облачными платформами.

Quarkus потребляет в 10 раз меньше памяти по сравнению с традиционными Java-приложениями. Разработчики пишут обычный Java-код, а фреймворк самостоятельно оптимизирует его под контейнеры и Kubernetes.

Некоторые компании используют Quarkus как более быструю и легкую альтернативу Spring Boot. Однако мне показалось, что вакансий с ним на рынке СНГ в разы меньше, чем на SB.

Quarkus и Micronaut хороши для небольших проектов и там, где важен быстрый старт приложения. Но пока они проигрывают Spring Boot в зрелости и глубине интеграций для большинства enterprise-сценариев.

10. MyBatis

Фреймворк соединяет Java-объекты с БД через SQL-запросы. В отличие от Hibernate, где SQL генерируется автоматически, здесь вы пишете запросы сами и размещаете их в XML-файлах или аннотациях.

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

Фреймворк не навязывает архитектуру приложения и легко встраивается в существующий код.

11. Guava

Библиотека Google Guava закрывает пробелы стандартной Java. Это набор утилит, который экономит время на рутине. Валидация параметров, работа с Optional до Java 8, удобные билдеры для коллекций — библиотека решает десятки мелких задач, с которыми сталкивается каждый разработчик.

Новичкам всегда советую брать самые популярные инструменты, которыми пользуются большинство компаний. В Java не так много фреймворков, поэтому по умолчанию рекомендую Spring Boot, Hibernate, JUnit. Это тот опыт, который нужен для большинства вакансий. Изучив перечисленные инструменты, можно попробовать менее популярные инструменты и уже на личном опыте оценить их пользу.

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

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

Для некоторых курсов я даже нашла уникальные промокоды, которые позволят получить приятные скидки и бонусы при записи — отличная возможность сэкономить и начать обучение с дополнительными преимуществами!

ТОП-10 лучших курсов по автоматизации тестирования в 2026 году

1. Инженер по автоматизации тестирования от GeekBrains — комплексная программа с углубленным изучением Java, Python и JavaScript.
2. Инженер по автоматизации тестирования от Skillbox — практико-ориентированный курс с упором на Selenium и CI/CD.
3. Инженер по тестированию от Нетологии — расширенное обучение с модулями по нейросетям и современным фреймворкам.
4. Инженер по тестированию от Skypro — системная подготовка с созданием собственного фреймворка и дипломным проектом.
5. Ав­то­ма­ти­зи­ро­ван­ное тестирование на Python от Skillbox — обучение с акцентом на Python, Pytest и DevOps-практики.
6. Инженер по тестированию: от новичка до автоматизатора от «Яндекс Практикума» — поэтапное освоение от ручного тестирования до авто-тестов с реальными проектами.
7. Python QA Engineer от OTUS — интенсивный курс с PyTest, Selenium и упором на DevOps.
8. Автоматизатор тестирования на Java от «Яндекс Практикума» — обучение Java с нуля и построение CI/CD пайплайнов.
9. Инженер по автоматизированному тестированию на JavaScript от «Хекслета» — практика с Playwright, Jest и проектами на GitHub.
10. Автоматизатор тестирования на Python от «Яндекс Практикума» — обучение на Python с упором на pytest, Selenium и Docker.

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

Онлайн-курсы по автоматизации тестирования

1. Инженер по автоматизации тестирования | GeekBrains

Используйте промокод kursfinder, чтобы получить скидку 7%

Получить скидку >>>

Программа охватывает три популярных языка программирования — Java, Python и JavaScript. Студенты осваивают современные инструменты и практики: Selenium WebDriver, JUnit, Chrome DevTools, Postman, GitLab, Grafana, SQL и Jira. Вы также научитесь созданию автотестов для веб- и мобильных приложений, работе с API и внедрению непрерывной интеграции.

Обучение ведут практикующие эксперты из Ozon, СКБ «Контур» и других крупных компаний. Курс сочетает теоретические видеоуроки с практикой на реальных проектах, что позволяет студентам формировать портфолио уже во время обучения.

• Стоимость: от 3 358 руб. в месяц при рассрочке
• Длительность: 110 часов теории и 400 часов практики
• Формат обучения: видеоуроки, вебинары, практические задания, проекты, консультации кураторов и проверка домашних заданий
• Сертификат: официальный диплом с лицензией

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

Преимущества

• совместная программа GeekBrains и Skillbox;
• обучение с лицензией государственного образца;
• углубленное изучение Java, Python и JavaScript;
• работа с современными инструментами для тестирования;
• большой объем практики на реальных кейсах;
• персональная обратная связь от экспертов;
• возможность собрать портфолио во время обучения;
• поддержка HR-специалистов для выхода на рынок труда;
• гибкий график и доступ к материалам в любое время;
• рассрочка без переплат и налоговый вычет.

Недостатки

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

Программа обучения:

• Изучение одного из языков программирования Java/JavaScript/Python
• Создание первых автотестов с использованием Selenium
• Продвинутое автоматизированное тестирование
• Работа с SQL для тестирования баз данных
• Использование Jira для постановки задач и баг-репортов
• Работа с API и Postman
• Настройка CI/CD процессов
• Метрики тестирования и их применение
• Создание UI-тестов
• Итоговые проекты и защита портфолио

Ознакомиться с полной программой >>>

2. Инженер по автоматизации тестирования | Skillbox

Используйте промокод kursfinder, чтобы получить скидку 60%

Получить скидку >>>

Студенты осваивают один из трех языков программирования — Java, Python или JavaScript, знакомятся с современными инструментами, такими как Selenium WebDriver, JUnit, Git и CI/CD, и уже с первых модулей применяют знания на практике, создавая проекты для портфолио.

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

• Стоимость: от 5 382 руб. в месяц при рассрочке
• Длительность: 9 месяцев
• Формат обучения: видеолекции, практические задания, проекты, вебинары, кураторская поддержка и доступ к мобильной версии платформы
• Сертификат: официальный документ с лицензией

Кому подойдет: junior-тестировщикам, студентам курса «Инженер по тестированию» для продолжения обучения, специалистам, которые хотят перейти от ручных проверок к автоматизации.

Преимущества

• обучение с лицензией государственного образца;
• освоение Java, Python и JavaScript;
• практика с первого модуля;
• работа с Selenium IDE и WebDriver;
• изучение CI/CD и GitLab;
• доступ к видеоурокам навсегда;
• мобильная версия платформы;
• помощь кураторов и экспертов;
• дополнительные модули по SQL и API;
• участие в двух финальных проектах;
• возможность пополнить портфолио практическими кейсами;
• обучение с опытными спикерами из OZON и СКБ «Контур»;
• налоговый вычет до 13% от стоимости курса.

Недостатки

• курс рассчитан только на специалистов с базовыми знаниями ручного тестирования;
• ограничение по языкам программирования (только Java, Python, JavaScript);
• трудоустройство не гарантировано, есть лишь канал с вакансиями.

Программа обучения

• Изучение одного из языков программирования Java/JavaScript/Python
• Первые автотесты во фреймворке Selenium
• Продвинутое автоматизированное тестирование
• Настройка CI/CD и параллельных запусков тестов
• Работа с SQL и тестирование баз данных
• Создание UI-тестов и их интеграция в процесс разработки
• Работа с Git и управление версиями кода
• Тестирование API и практические задачи с Postman
• Итоговые проекты и защита работ

Ознакомиться с полной программой >>>

3. Инженер по тестированию | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Получить скидку >>>

Программа построена поэтапно: сначала студенты изучают ручное тестирование веб- и мобильных приложений, затем переходят к автоматизированным сценариям на Python или Java, а в расширенном блоке осваивают JavaScript и популярные фреймворки — Cypress, Playwright и Puppeteer. Курс также включает модули по SQL, тестированию API, нагрузочному тестированию сервисов, анализу сетевого трафика и базовым практикам безопасности с использованием OWASP ZAP и Burp Suite.

Дополнительно студенты знакомятся с Docker, Git, Postman и JMeter, учатся планировать автоматизацию и анализировать результаты тестов. Четыре блока посвящены применению нейросетей для генерации кода автотестов, оптимизации рутинных задач и подготовки документации. В течение курса выполняется более 20 практических проектов, включая групповые задания на основе кейсов от компаний Dragons, OneTwoTrip, QIWI и «Глобус ИТ».

• Стоимость: от 3 816 руб. в месяц при рассрочке
• Длительность: 14 месяцев (408 часов практики)
• Формат обучения: вебинары, видеолекции, тренажеры для работы с кодом, домашние задания, проекты, командные кейсы, практические вебинары и поддержка экспертов в чате
• Сертификат: диплом о профессиональной переподготовке установленного образца

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

Преимущества

• обновленная программа 2026 года с модулями по нейросетям;пошаговое погружение от ручного тестирования до автоматизации;
• 20 крупных проектов для портфолио;
• командная практика по реальным кейсам от партнеров;
• изучение Python, Java и JavaScript на выбор;
• освоение популярных фреймворков для автоматизации;
• практика работы с SQL и тестированием API;
• модули по нагрузочному и функциональному тестированию;
• основы тестирования безопасности и анализа уязвимостей;
• знакомство с Docker и CI/CD;
• поддержка экспертов из VK, Т-Банка, QIWI и других компаний;
• доступ к мобильному приложению для обучения;
• помощь в трудоустройстве и сопровождение после выпуска.

Недостатки

• курс рассчитан на системное освоение, быстрых результатов не будет.

Программа обучения

• Ручное тестирование веб-приложений
• Git и система контроля версий
• Python для тестировщиков или Java для тестировщиков
• Автоматизированное тестирование на Python или Java
• JavaScript и фреймворки для автоматизации
• Тестирование API и интеграция в CI
• Нагрузочное тестирование сервисов
• Тестирование мобильных приложений
• Основы тестирования безопасности
• Работа с Docker и CI/CD
• Дополнительные модули по нейросетям для тестировщиков
• Итоговые проекты и дипломная работа

Ознакомиться с полной программой >>>

4. Инженер по тестированию | Skypro

Используйте промокод Kursfinder, чтобы получить скидку 10%

Получить скидку >>>

Программа построена так, чтобы студенты постепенно осваивали как ручное, так и автоматизированное тестирование. Сначала слушатели изучают работу с баг-репортами, тест-кейсами и системами управления тестами, затем переходят к освоению баг-трекинговых сервисов, методик тест-дизайна, регрессионного и дымового тестирования. Используются Chrome DevTools, Postman, SoapUI, SQL и JMeter для анализа работы веб-платформ, API и баз данных.

Дальше курс погружает студентов в автоматизацию на Python и Java, работу с Pytest, библиотекой requests и формирование отчетности в Allure. Студенты создают UI-тесты с помощью Selenium, изучают CI/CD и практикуются с Docker для автоматизации запуска тестов. В рамках обучения разрабатывается собственный тестовый фреймворк, а завершающим этапом становится дипломный проект. Программа насыщена практическими заданиями — около 70% материалов основаны на реальных кейсах работодателей и фриланс-платформ, что позволяет выпускникам сформировать полноценное портфолио к концу курса.

• Стоимость: от 5 972 руб. в месяц при рассрочке
• Длительность: 12 месяцев
• Формат обучения: онлайн-занятия, видеолекции, практические задания, работа с наставниками, тренажеры, проекты и дипломная работа
• Сертификат: диплом о профессиональной переподготовке

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

Преимущества

• системная программа с базовыми и продвинутыми блоками;
• 70% практики на реальных задачах;
• изучение баг-трекинговых систем и TMS;
• работа с Chrome DevTools и кросс-браузерным тестированием;
• освоение Postman и SoapUI;
• практика с SQL и нагрузочным тестированием в JMeter;
• автоматизация тестов на Python и Java;
• знакомство с Pytest и библиотекой requests;
• отчетность и визуализация через Allure;
• практика с Selenium WebDriver;
• освоение принципов CI/CD и Docker;
• создание собственного фреймворка для автотестов;
• карьерные консультации и помощь в трудоустройстве.

Недостатки

• длительный срок обучения (1 год);
• упор на Python и Java, другие языки не рассматриваются.

Программа обучения

• Основы функционального тестирования
• Работа с баг-репортами и баг-трекинговыми системами
• Тест-кейсы и системы управления тестами
• Уровни тестирования и тест-дизайн
• Smoke- и регрессионное тестирование
• Тестирование документации и метрики
• Тестирование веб-приложений и работа с HTML/CSS
• Chrome DevTools и кросс-браузерное тестирование
• Git и основы CI/CD
• Тестирование API с Postman и SoapUI
• Нагрузочное тестирование с JMeter
• Основы SQL и работа с базами данных
• Автоматизация тестирования на Python или Java
• Pytest, requests и Allure для отчетности
• UI-тесты и Selenium WebDriver
• Docker и настройка CI/CD процессов
• Дипломный проект и защита портфолио

Ознакомиться с полной программой >>>

5. Ав­то­ма­ти­зи­ро­ван­ное тестирование на Python | Skillbox

Используйте промокод kursfinder, чтобы получить скидку 50%

Получить скидку >>>

На занятиях студенты осваивают написание чистого кода на Python, применяют принципы объектно-ориентированного и функционального программирования, разрабатывают архитектуру тестов и объединяют их в тестсьюты. Особое внимание в программе уделяется работе с DevTools и PyCharm, использованию Pytest и Selenium для построения автотестов, а также созданию сценариев на основе паттернов тестирования.

Отдельные блоки посвящены DevOps-инструментам: студенты интегрируют тесты в Jenkins, настраивают параллельные и последовательные проверки и внедряют их в CI/CD-процессы. Курс также охватывает работу с Git, решение конфликтов версий и ведение командных проектов. Теория сразу закрепляется практикой, а итогом становится полноценное портфолио готовых кейсов. Программу ведут эксперты: Дарья Манухина, специалист с опытом работы в МТС и Skyeng, и Павел Громов, backend-разработчик с практикой преподавания и участия в конференциях по тестированию.

• Стоимость: от 5 028 руб. в месяц при рассрочке
• Длительность: 9 месяцев
• Формат обучения: онлайн-лекции, практические задания, вебинары, индивидуальная проверка домашних работ кураторами, обратная связь и доступ к материалам без ограничения по времени
• Сертификат: диплом о профессиональной переподготовке

Кому подойдет: начинающим тестировщикам, которые хотят с нуля освоить Python и автоматизацию; junior-специалистам для повышения уровня знаний; middle-инженерам по тестированию, желающим закрепить практику и выйти на новый уровень.

Преимущества

• обучение с упором на Python;
• освоение Pytest и Selenium;
• практика с DevTools и PyCharm;
• изучение принципов тест-дизайна;
• написание автотестов для реальных кейсов;
• построение архитектуры тестов и паттернов;
• работа с Jenkins и CI/CD;
• интеграция тестов с Git;
• коммит, merge и разрешение конфликтов версий;
• практика на примере веб- и API-проектов;
• участие экспертов-практиков;
• доступ к курсу навсегда;
• бесплатный бонус — год английского языка.

Недостатки

• упор на один язык программирования;
• значительный объем теории, требующий регулярной практики;
• курс рассчитан на 9 месяцев, быстрых результатов не будет;ограничение по выбору инструментов вне экосистемы Python.

Программа обучения

• Python Basic
• Python Advanced
• Введение в автоматизацию тестирования API
• Автотесты на Python. Базовая часть
• Автотесты на Python. Продвинутая часть
• DevOps для тестировщиков
• Итоговые проекты и дипломная работа

Ознакомиться с полной программой >>>

6. Инженер по тестированию: от новичка до автоматизатора | Яндекс Практикум

Купите любой курс с выгодой до 20% при оплате сразу или получите скидку 7% за прохождение бесплатной части курса за неделю

Получить скидку >>>

Обучение начинается с освоения принципов тестирования приложений и работы с тестовой документацией, после чего студенты переходят к созданию автотестов на Java или Python. В программе используются инструменты Charles, Postman, Swagger, DevTools, Selenium WebDriver, Pytest, Allure и Jenkins, а также SQL для работы с базами данных. Знания сразу закрепляются практикой: за время курса слушатели выполняют 10 реальных проектов, формируя портфолио для будущего трудоустройства.

Вы научитесь также тестированию веб- и мобильных приложений, API и работе с инфраструктурой, что позволяет применять навыки в различных сферах — от банковских сервисов до игровых компаний. Обучение проводят эксперты из Яндекса и крупных IT-компаний, включая Константина Булатова, Кристину Тимошенко и Романа Орлова. Дополнительно студенты изучают применение нейросетей в тестировании и получают навыки подготовки резюме для привлечения работодателей.

• Стоимость: от 3 225 руб./мес или 79 000 руб. единым платежом
• Длительность: 9 месяцев
• Формат обучения: вебинары с практикующими тестировщиками, видеолекции, интерактивный учебник, командные проекты, поддержка наставников и ревьюеров, доступ к материалам навсегда
• Сертификат: диплом о профессиональной переподготовке от АНО ДПО «Образовательные технологии Яндекса»

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

Преимущества

• освоение ручного и автоматизированного тестирования;
• выбор языка для автотестов (Java или Python);
• практика на 10 реальных проектах;
• инструменты Charles, Postman, Swagger, SQL, Selenium, Jenkins;
• работа с мобильными приложениями и API;
• модуль по применению нейросетей;
• обучение у специалистов Яндекса и EPAM;
• поддержка наставников и ревьюеров;
• доступ к материалам курса без ограничений;
• помощь в трудоустройстве через карьерный центр;
• возможность совмещать учебу с работой;
• налоговый вычет до 19 500 руб.;
• гарантия возврата средств при отказе от курса.

Недостатки

• высокая учебная нагрузка (от 15 часов в неделю);
• основной упор на начинающих.

Программа обучения

• Бесплатный вводный модуль
• Основы тестирования
• Регрессионное тестирование и ретест багов
• Тестирование фичи от анализа до баг-репорта
• Расширенное тестирование веб-приложений
• Тестирование мобильных приложений
• Тестирование API
• Основы баз данных
• Автоматизированное тестирование на Java
• Автоматизированное тестирование на Python
• Итоговый проект
• Нейросети для тестировщиков
• Карьерный трек

Ознакомиться с полной программой >>>

7. Python QA Engineer | OTUS

Программа построена так, чтобы студенты научились работать с фреймворком PyTest, автоматизировать UI- и API-тесты, использовать Selenium 4 и Appium, проводить тестирование REST API и настраивать процессы в системах непрерывной интеграции. Выпускники осваивают запуск автотестов в CI/CD, анализ результатов и работу с инфраструктурой.

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

• Стоимость: 121 000 руб. (есть рассрочка и налоговый вычет до 13%)
• Длительность: 6 месяцев
• Формат обучения: вебинары дважды в неделю, доступ к записям и материалам, практические задания, выпускной проект, поддержка в закрытом чате
• Сертификат: официальный сертификат OTUS о прохождении курса

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

Преимущества

• упор на практику с реальными кейсами;
• изучение PyTest как основного фреймворка;
• работа с Selenium 4 и Appium;
• тестирование REST API;
• освоение DevOps-практик;
• использование Linux для диагностики;
• обучение у экспертов-практиков;
• участие в живых вебинарах;
• обратная связь по домашним заданиям;
• доступ к закрытому сообществу;
• выпускной проект для портфолио;
• доступ к репозиторию с примерами тестов;
• возможность оплаты курса работодателем.

Недостатки

• обязательное вступительное тестирование перед началом;
• курс рассчитан на студентов с базовыми знаниями Python;
• высокая учебная нагрузка (две вечерние сессии в неделю).

Программа обучения

• Введение в автоматизацию тестирования
• Тестирование API
• Тестирование UI
• DevOps
• Мобильное тестирование
• Работа с бэкендом
• Другие виды тестирования
• Подготовка к поиску работы
• Проектный модуль и защита выпускного проекта

Ознакомиться с полной программой >>>

8. Автоматизатор тестирования на Java | Яндекс Практикум

Купите любой курс с выгодой до 20% при оплате сразу или получите скидку 7% за прохождение бесплатной части курса за неделю

Получить скидку >>>

В рамках курса студенты осваивают основы языка Java, учатся писать код и применять его для создания автотестов для веб-приложений и API. Программа включает популярные инструменты тестировщика: IntelliJ IDEA, Maven, Git, Selenium WebDriver, Selenide, JUnit, Postman, REST Assured, Allure и Jenkins. Шаг за шагом слушатели погружаются в процесс автоматизации — от базовых конструкций и написания юнит-тестов до разработки архитектуры тестирования и построения полноценного пайплайна CI/CD.

Отдельные блоки посвящены тестированию интерфейсов, API и баз данных, а также внедрению подхода Behavior-Driven Development с использованием Cucumber и Gherkin. На занятиях студенты выполняют проекты, максимально приближенные к реальным задачам индустрии, и получают обратную связь от опытных специалистов. Завершающим этапом курса становится итоговая работа, где необходимо покрыть автотестами веб-приложение, API и написать юнит-тесты, объединяя все полученные навыки.

• Стоимость: от 4 204 руб. в месяц (есть рассрочка и налоговый вычет)
• Длительность: 5–6 месяцев (в зависимости от тарифа)
• Формат обучения: онлайн-лекции, интерактивные задания в тренажере, вебинары каждые 2 недели, проекты для портфолио, индивидуальные встречи с наставником, обратная связь от экспертов
• Сертификат: диплом о профессиональной переподготовке

Кому подойдет: ручным тестировщикам, которые хотят перейти в автоматизацию; junior-специалистам, готовым укрепить навыки и освоить Java; действующим QA-инженерам, планирующим карьерный рост.

Преимущества

• освоение Java с нуля;
• обучение работе с IntelliJ IDEA и Maven;
• практика с Git и GitHub;
• изучение юнит-тестирования на JUnit 5;
• знакомство с Mockito и DI;
• написание автотестов с Selenium и Selenide;
• тестирование интерфейсов через DevTools;
• автоматизация API с использованием Postman и REST Assured;
• отчетность в Allure;
• построение пайплайнов CI/CD в Jenkins;
• работа с Docker и Kubernetes;
• освоение BDD и Cucumber;
• проектная работа для портфолио.

Недостатки

• требуется регулярное выделение времени (не менее 15 часов в неделю);
• часть материалов доступна только в расширенной версии.

Программа обучения

• Введение в профессию и основы Git
• Изучение Java: базовый и продвинутый уровни
• Объектно-ориентированное программирование и базовые конструкции
• Юнит-тестирование и работа с JUnit, Mockito
• UI-тестирование на Selenium и Page Object Model
• Тестирование API с Postman, Swagger, REST Assured
• Работа с базами данных и SQLCI/CD, Docker, Kubernetes, Jenkins
• Behavior-Driven Development с Cucumber и Gherkin
• Работа с асинхронными сервисами и Kafka
• Итоговый проект и защита работы

Ознакомиться с полной программой >>>

9. Инженер по автоматизированному тестированию на JavaScript | Хекслет

С первых занятий студенты начинают программировать на JavaScript, осваивают построение автотестов и их применение к реальным веб-приложениям. Вы научитесь работе с Playwright и Jest, а также интеграционному, модульному и e2e-тестированию. Обучение построено на практических заданиях и проектах: студенты пишут автотесты для учебных сервисов, работают с Git, осваивают CI/CD и Docker, создавая полноценные проекты для портфолио.

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

• Стоимость: от 85 000 руб. (есть рассрочка и акции)
• Длительность: 8 месяцев
• Формат обучения: теория в текстовом и видеоформате, практические задания, проекты на GitHub, домашние упражнения, вебинары, код-ревью и наставничество
• Сертификат: официальный документ Хекслета, ценимый работодателями

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

Преимущества

• упор на практику с первых занятий;
• изучение JavaScript в контексте тестирования;
• освоение Playwright для UI-тестов;
• работа с Jest и Vitest для модульного тестирования;
• интеграция Git и командной строки в учебный процесс;
• проекты с реальными бизнес-задачами;
• портфолио на GitHub с завершенными проектами;
• коммерческие задачи от партнеров;
• наставничество от опытных инженеров;
• карьерное сопровождение через Хекслет.Карьеру;
• подготовка резюме и собеседований;
• поддержка при трудоустройстве;
• возможность академического отпуска при необходимости.

Недостатки

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

Программа обучения

• Основы JavaScript и настройка окружения
• Работа с Git и командной строкой
• Юнит- и интеграционное тестирование на Jest
• Асинхронное программирование и тестирование API
• E2E-тестирование с Playwright
• Работа с HTML, CSS и DOM API
• Тестирование бэкенда и взаимодействие с базами данных
• CI/CD и основы Docker
• Учебные и коммерческие проекты для портфолио
• Итоговый проект с полной автоматизацией веб-приложения

Ознакомиться с полной программой >>>

10. Автоматизатор тестирования на Python | Яндекс Практикум

Купите любой курс с выгодой до 20% при оплате сразу или получите скидку 7% за прохождение бесплатной части курса за неделю

Получить скидку >>>

Студенты осваивают базовый синтаксис Python и сразу начинают применять его для написания автотестов. Программа включает работу с pytest, Selenium WebDriver, Allure, Git, DevTools, а также использование XPath и CSS-локаторов. Вас научат архитектуре приложений, методам тестирования API и организации тестовых сценариев. Обучение строится на практике: студенты создают проекты для портфолио, покрывают тестами веб-приложения, API и пишут юнит-тесты с использованием моков, стабов и Spy. Курс разработан опытными инженерами по тестированию из Яндекса и других крупных IT-компаний, что гарантирует актуальность материалов и их связь с реальной индустрией.

Теоретический материал подается в удобной форме и закрепляется интерактивными заданиями в тренажере, а регулярные вебинары позволяют разбирать сложные кейсы вместе с экспертами. В результате выпускники получают навыки построения процессов автоматизации, работы с CI/CD и Docker, а также опыт создания комплексных отчетов о тестировании. Дополнительно студенты формируют портфолио с реальными проектами, которое подтверждает их компетенции перед работодателями.

• Стоимость: от 4 204 руб. в месяц (есть рассрочка и налоговый вычет)
• Длительность: 5–6 месяцев (в зависимости от тарифа)
• Формат обучения: видеолекции и текстовые материалы, тренажер для практики, домашние задания, вебинары каждые 2 недели, проекты для портфолио, обратная связь от наставников
• Сертификат: диплом о профессиональной переподготовке или справка об обучении

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

Преимущества

• обучение на Python с нуля;
• освоение pytest для юнит-тестов;
• практика с Selenium WebDriver;
• работа с DevTools и XPath;
• создание отчетов в Allure;
• тестирование API с Postman и Swagger;
• изучение принципов архитектуры приложений;
• работа с базами данных и SQL;
• освоение CI/CD и Docker;
• практика в реальных проектах;
• 7–10 проектов для портфолио;
• доступ к вебинарам и Q&A-сессиям;
• поддержка наставников и экспертов Яндекса.

Недостатки

• высокая нагрузка (нужно минимум 15 часов в неделю);
• часть тем и проектов доступна только в расширенной версии;
• полностью онлайн-формат без живых встреч;
• для новичков могут быть сложны темы ООП и CI/CD.

Программа обучения

• Введение и знакомство с Git
• Основы Python и базовые конструкции
• Объектно-ориентированное программирование
• Инкапсуляция и обработка исключений
• Юнит-тестирование с использованием pytest
• UI-тестирование на Selenium и DevTools
• Применение Page Object Model и Allure
• Тестирование API и работа с Postman, Swagger
• Основы архитектуры и организация процессов тестирования
• Итоговый проект с полной автоматизацией веб-приложения
• Дополнительный модуль по SQL и тестированию баз данных
• CI/CD и работа с Docker (в расширенной версии)

Ознакомиться с полной программой >>>

Еще 4 курса по автоматизации тестирования

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

• QA-инженер по тестированию: с нуля до автоматизатора от «Хекслета». Курс построен так, чтобы с нуля подготовить специалиста к профессии QA-инженера и постепенно довести его до уровня автоматизатора на JavaScript. В программе много практики: студенты тестируют реальные веб- и мобильные приложения, пишут баг-репорты, создают автотесты с использованием Vitest и Playwright, осваивают работу с API и SQL. Обучение сопровождается проектами для портфолио и консультациями наставников, а завершение курса подтверждается сертификатами по двум профессиям.
• Тестировщик в IT от Yagla. Курс рассчитан на тех, кто хочет быстро войти в IT и освоить профессию тестировщика с нуля. Программа охватывает ручное и автоматизированное тестирование, работу с базами данных, инструментами Git, SQL, Selenium, Postman и другими технологиями. Обучение построено на практике и реальных кейсах, к окончанию курса формируется портфолио и выдается сертификат, подтверждающий квалификацию.
• Тестирование с Pytest от «Хекслета». Курс обучает работе с Pytest и современными техниками автоматизированного тестирования на Python. Студенты осваивают модульные тесты, фикстуры, подход TDD, а также продвинутые инструменты вроде моков, стабов и манкипатчинга. Занятия построены на практике с использованием виртуальной среды и автоматической проверкой решений, что позволяет сразу закреплять полученные знания.
• Инженер по тестированию от Skillbox. Программа готовит специалистов по ручному и автоматизированному тестированию с упором на современные ИИ-инструменты. В процессе обучения студенты осваивают Java, Python или JavaScript для написания автотестов, учатся работать с Postman, Selenium, SQL, Git и Unity, а также тестируют реальные проекты от компаний-партнеров. В курс добавлены блоки по тестированию мобильных приложений и игр, что расширяет возможности трудоустройства и формирует сильное портфолио.

Еще 2 курса по автоматизации тестирования на Java

Если вы хотите углубить знания в автоматизации тестирования на Java, эти два курса станут отличным выбором. Они помогут закрепить навыки создания автотестов, работы с современными инструментами и подготовят к реальным задачам в IT-индустрии.

• Автоматизация тестирования ПО (Java). Basic от Level Up. Курс знакомит с основами автоматизации тестирования на Java и учит применять популярные инструменты вроде Selenium, Selenide, Cucumber, JUnit и RestAssured. Обучение построено на сочетании теории и практики, предполагает работу с CI/CD и Jenkins, а также формирование базовых навыков написания автотестов. По окончании программы студенты получают представление о роли инженера по автоматизации и приобретают навыки, достаточные для работы на позиции junior.
• Автоматизированное тестирование ПО на Java от Университета «Иннополис». Программа знакомит с автоматизацией тестирования на Java и учит работать с ключевыми инструментами — Selenium, Selenide, RestAssured, Docker и CI/CD. Студенты осваивают написание автотестов для UI и API, работу с базами данных и основы BDD. Обучение построено на практических заданиях и завершается дипломом о профессиональной переподготовке, что позволяет претендовать на позиции AQA-инженера.

Еще 4 курса по автоматизации тестирования на Python

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

• Автоматизация тестирования на Python от «Контур.Школы». Программа обучает автоматизации тестирования на Python и помогает создавать автотесты для API, мобильных и веб-приложений. В процессе занятий студенты осваивают PyTest, Selenium, а также принципы Page Object Model. Курс сочетает теорию с практическими задачами и завершается итоговым тестом, после которого выдается официальный документ о повышении квалификации.
• Тестировщик на Python от SkillFactory. Программа обучает ручному и автоматизированному тестированию, в том числе работа с Python, PyTest, Selenium, SQL и REST API. В процессе обучения студенты выполняют проекты от реальных компаний, составляют баг-репорты и тест-кейсы, проходят практику на коммерческих сервисах. По окончании выдается диплом о профессиональной переподготовке или сертификат, что позволяет претендовать на позиции тестировщика и QA-инженера.
• Автоматизированное тестирование на Python от EasyUM. Курс помогает освоить автоматизацию тестирования на Python с нуля и шаг за шагом перейти к созданию автотестов для веб-приложений и API. В программе есть работа с PyTest, Selenium, Docker и Jenkins, а также основы DevOps. Обучение построено на практике, есть реальные задания и проекты для портфолио, а по завершении выдается сертификат и проводится подготовка к трудоустройству.
• Автоматизированное тестирование на Python от Teachmeskills. Курс учит создавать автотесты на Python с использованием Selenium, PyTest, Docker и Jenkins. В процессе обучения студенты осваивают тестирование API и веб-приложений, а также работу с базами данных и Linux. Программа построена на практике, предполагает также разработку реального проекта для портфолио и завершается защитой диплома с поддержкой в трудоустройстве.

Бесплатные курсы по автоматизации тестирования

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

1. Легкий старт в профессию тестировщика — Skillbox

Этот интенсив подойдет новичкам, которые хотят попробовать себя в тестировании и понять, насколько им близка эта профессия. За несколько дней слушатели познакомятся с базовыми принципами ручного и автоматизированного тестирования, узнают о юзабилити и стандартах работы в IT-компаниях. Участники получат практику в поиске ошибок, составлении баг-репортов и запуске первых автотестов с помощью Selenium IDE. Такой формат обучения позволяет быстро погрузиться в профессию и сформировать первые навыки.

Главное о курсе:

• знакомство с процессами тестирования и профессией QA;проведение первых автотестов с использованием Selenium IDE;
• освоение правил юзабилити и нефункционального тестирования;
• практика в составлении баг-репортов и работе с ошибками;
• выполнение интерактивных заданий на реальных примерах.

2. Основы Java для автоматизации тестирования — Stepik

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

Главное о курсе:

• базовые знания языка Java и основы ООП;
• создание первых программ и работа с массивами, строками и классами;
• использование принципов инкапсуляции, наследования и полиморфизма;
• практика обработки исключений и документирования кода;
• более 70 часов обучения с тестами и интерактивными заданиями.

3. Тестировщик программного обеспечения: с нуля до первых проектов — «Содействие занятости»

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

Главное о курсе:

• знакомство с базовыми принципами тестирования ПО;
• работа с тестовой документацией и баг-репортами;
• практика в SQL и тестировании API через Postman;
• использование инструментов Jira, Яндекс Трекера, TestRail и DevTools;
• выполнение итогового проекта и получение удостоверения о квалификации.

4. Автоматизация тестирования с помощью Selenium и Python — Stepik

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

Главное о курсе:

• написание автотестов на Python с использованием Selenium;
• работа с веб-элементами и построение стабильных тестов;
• применение pytest и других фреймворков для автоматизации;
• использование паттерна PageObject для удобной поддержки сценариев;
• практика работы с git и Github.

5. Тесты и тренажеры для тестировщиков — LearnQA

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

Главное о курсе:

• тесты по Git, SQL, Java, Bash и базовым знаниям IT;
• тренажеры с эмуляцией рабочих ситуаций и поиском багов;
• подготовка к собеседованиям через практические задания;
• возможность закрепить знания и проверить себя в удобном формате.

Видеоуроки по автоматизации тестирования

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

1. Введение в автоматизацию для QA — Simple Automation. Плейлист подойдет тем, кто хочет разобраться в автоматизации тестирования с нуля и получить базовые навыки работы с основными инструментами. Видеоуроки построены последовательно — от теории и языка Java до работы с Git, Maven, JUnit, REST Assured и Selenium WebDriver. Такой формат помогает шаг за шагом освоить практику и закрепить знания через наглядные примеры.
2. Автоматизация тестирования с Pytest и Python — SolveMe. Плейлист подойдет тем, кто хочет научиться работать с Pytest и применять Python для автоматизации тестирования на практике. В уроках разбираются базовые приемы написания автотестов, работа с фикстурами, декораторами и генерацией отчетов. Отдельные видео посвящены использованию Pydantic, SQLAlchemy и Docker, что позволяет получить более глубокое понимание современного тестирования.
3. Автоматизация тестирования java + selenium webdriver — Алексей Маршал. Плейлист поможет тем, кто хочет освоить автоматизацию тестирования на Java с использованием Selenium WebDriver. В видеоуроках объясняются основы работы с DOM, локаторами, XPath и CSS-селекторами, а также показано, как взаимодействовать с элементами интерфейса. Отдельное внимание уделяется ожиданиям, работе с модальными окнами, вкладками браузера и построению фреймворка на основе PageObject.
4. Автоматизация на пальцах — Стас Пешкур. Плейлист создан для тех, кто хочет разобраться в автоматизации тестирования на практике и понять ее основы простым языком. В видео разбираются ключевые инструменты и подходы, работа с API-тестами, использование Rest Assured, Cucumber, Selenide и Page Object. Также показаны примеры настройки Maven, Jenkins и Gitlab CI/CD, создания отчетов в Allure и отладки кода на реальных задачах.
5. QA с нуля — Александр Хвастович. Этот плейлист подойдет тем, кто только начинает путь в тестировании и хочет понять основы профессии с нуля. В видеоуроках разбираются ключевые темы — от базовых принципов QA и методологий разработки до тестовой документации, работы с Jira, Git и SQL. Формат построен так, чтобы постепенно вести новичка от теории к первым практическим навыкам и подготовке к старту карьеры в IT.

Часто задаваемые вопросы (FAQ)

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

Почему именно курсы по автоматизации тестирования на Python пользуются наибольшим спросом среди новичков в IT?

Python отличается простым синтаксисом и богатым набором инструментов для тестирования. В курсах Skillbox и Яндекс Практикума студенты начинают с основ языка и сразу переходят к работе с Pytest и Selenium, что позволяет быстро освоить профессию и собрать портфолио.

За какой срок реально перейти от нуля до трудоустройства в профессии тестировщика-автоматизатора на Python?

Срок зависит от программы: от 5–6 месяцев в Яндекс Практикуме и OTUS до года в Skypro. Нетология предлагает 14-месячное обучение с углублением в ручное тестирование, автоматизацию и нейросети. Такой диапазон позволяет выбрать формат в зависимости от целей и доступного времени.

Что конкретно умеют делать после завершения курса по автоматизации тестирования на Python выпускники профильных программ?

Выпускники осваивают написание UI- и API-тестов, создание отчетов в Allure, работу с Jenkins, Docker и CI/CD. В Нетологии студенты дополнительно учатся использовать Cypress и Playwright, а в Skillbox углубляются в DevOps-практики и архитектуру тестов.

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

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

На каких инструментах делают упор в программах по автоматизации тестирования: Selenium, Pytest или другие решения?

Почти в каждом курсе присутствуют Selenium и Pytest. В GeekBrains+Skillbox акцент дополнен Postman, SQL и Jira. В Хекслете главными инструментами становятся Playwright и Jest, а в Нетологии изучают также Cypress и Puppeteer.

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

Да, большинство программ рассчитано на новичков. В Skypro и Яндекс Практикуме есть вводные блоки по основам тестирования и Python, а в Skillbox добавлены модули Python Basic и Advanced.

Нужен ли практический опыт ручного тестирования прежде чем переходить к автоматизации тестов ПО?

Некоторые школы начинают именно с ручного тестирования. В Нетологии и Skypro студенты сначала осваивают баг-репорты и тест-дизайн, а затем переходят к автоматизации. В OTUS требуется базовое знание Python, поэтому упор сразу делается на автотесты.

Какие карьерные возможности открывает освоение автоматизации тестирования веб-приложений?

Выпускники курсов могут претендовать на должности QA Automation Engineer или Python QA Engineer. Например, в GeekBrains+Skillbox студенты учатся работать с CI/CD и SQL, а в Яндекс Практикуме формируют портфолио из 10 проектов, что помогает быстрее выйти на рынок.

Включают ли топовые школы обучение API-тестированию в базовую образовательную программу?

Да, API-тестирование есть почти в каждом курсе. В Skypro студенты осваивают Postman и SoapUI, в OTUS работают с REST Assured, а в Яндекс Практикуме применяют Postman и Swagger.

Содержат ли современные образовательные программы модуль по работе с базами данных и изучению SQL для автоматизаторов?

Да, SQL включен в программы большинства школ. В Skillbox есть отдельный модуль для работы с базами, в Нетологии SQL используется в нагрузочном тестировании, а в Яндекс Практикуме он входит в базовую часть курса.

Какие практические работы включают в портфолио выпускники программ по автоматизированному тестированию?

Это проекты с автотестами для веб-приложений, API и мобильных сервисов, отчеты в Allure и кейсы с CI/CD. В OTUS выпускники создают собственный фреймворк, в Хекслете портфолио публикуется на GitHub, а в Яндекс Практикуме итоговый проект объединяет UI-, API- и юнит-тесты.

Профессия тестировщика-автоматизатора остается одной из самых востребованных в IT. Начинающие специалисты могут рассчитывать на зарплату от 70 000–90 000 руб., а опытные инженеры в крупных городах, особенно с навыками Python, Java и современными фреймворками, зарабатывают от 250 000 руб. и выше. Автоматизация открывает путь к стремительному карьерному росту, ведь компании ценят специалистов, которые умеют экономить ресурсы и ускорять выпуск продуктов. Выбирая курсы по автоматизации тестирования, важно обращать внимание на практическую часть, количество проектов и поддержку экспертов — это ключ к формированию портфолио и реальным навыкам, которые сразу пригодятся на рынке труда.

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

Почему скорость сайта так важна

В мире, где внимание пользователей рассеивается за восемь секунд, быстрая загрузка сайта становится критически важной. Статистика подтверждает: 53% мобильных пользователей покидают сайт, если он грузится дольше 3 секунд, а 70% потребителей отмечают, что скорость влияет на их решение о покупке. Walmart, например, зафиксировал рост конверсий на 2% за каждую секунду сокращения времени загрузки.

Быстрые сайты обеспечивают:

• Долгое пребывание пользователей на сайте;
• Больше просмотров страниц благодаря быстрой навигации;
• Меньше отказов из-за медленных загрузок;
• Выше конверсии и доходов, так как скорость напрямую влияет на покупки;
• Лучшую удовлетворенность и удержание пользователей;
• Рост органического трафика, так как Google учитывает Core Web Vitals в SEO-ранжировании;
• Экономию на CDN и трафике, ведь оптимизированные сайты потребляют меньше данных;
• Повышение качества рекламы в Google Ads, так как быстрые страницы снижают стоимость кликов.

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

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

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

• Google PageSpeed Insights: быстрый аудит Core Web Vitals с рекомендациями.
• Chrome Lighthouse: встроенный в DevTools инструмент для анализа производительности, SEO и лучших практик.
• WebPageTest: детализированные метрики, визуализация загрузки и советы по оптимизации.
• GTmetrix: анализ скорости загрузки с рекомендациями.
• CrUX в Google Search Console: реальные данные пользовательского опыта (Core Web Vitals) для SEO.

Лабораторные инструменты дают контролируемые метрики, а мониторинг реальных пользователей (через Web Vitals JS, SpeedCurve или Calibre) показывает, как сайт работает в реальных условиях. Это поможет определить приоритеты для оптимизации.

Чек-лист оптимизации фронтенда 2025

Производительность — это командная работа. Бэкенд должен быть масштабируемым, UX-дизайнеры — балансировать визуал и скорость, а фронтенд-разработчики — реализовывать оптимизированный код. Этот чек-лист подходит для любой платформы: от Next.js и Astro до WordPress и PHP. Адаптируйте его под ваш проект, уделяя внимание ключевым метрикам, таким как LCP, CLS и INP (новый показатель, заменивший FID в 2024 году).

HTML

HTML — основа страницы, и его оптимизация ускоряет загрузку и улучшает пользовательский опыт.

• Приоритизируйте критический HTML: доставляйте HTML для верхней части страницы первым, чтобы браузер начал рендеринг. Фреймворки вроде Next.js или Astro с SSR/SSG рендерят HTML на сервере, улучшая First Contentful Paint.
• Удаляйте лишний код: уберите ненужные теги, комментарии и пробелы. Компактный HTML загружается быстрее, особенно в мобильных сетях.
• Включите сжатие: используйте GZIP или Brotli, чтобы уменьшить размер HTML. Большинство серверов и CDN это поддерживают.
• Оптимизируйте загрузку ресурсов: размещайте CSS в <head> для быстрого рендера, а скрипты — перед </body> или с атрибутами async/defer, чтобы не блокировать разбор HTML.
• Минимизируйте iframe: они загружают дополнительные страницы, замедляя сайт. Используйте loading="lazy" для iframe ниже линии сгиба или загружайте их по клику.

Совет: держите DOM компактным. Например, Astro разбивает страницы на «островки», минимизируя гидратацию JavaScript, что ускоряет рендеринг.

CSS

CSS может блокировать рендеринг, если не оптимизирован. Вот как сделать стили быстрее:

• Удаляйте неиспользуемый CSS: используйте PurgeCSS или Chrome DevTools, чтобы убрать мертвый код, особенно в проектах с Tailwind.
• Модуляризуйте стили: разделяйте CSS по страницам или функциям, загружая только необходимое. Критические стили встраивайте в <head>, остальное загружайте асинхронно.
• Избегайте @import: он создает дополнительные запросы и блокирует рендеринг. Используйте <link rel="stylesheet"> или объединяйте CSS при сборке.
• Используйте критический CSS: встраивайте стили для верхней части страницы в HTML, а остальное загружайте позже (например, через media="print"). Инструменты вроде Critical помогут это автоматизировать.
• Минимизируйте CSS: убирайте пробелы и комментарии с помощью Clean-CSS или cssnano.
• Предварительно загружайте ключевые стили: используйте <link rel="preload" as="style"> для важных CSS-файлов.
• Упрощайте селекторы: избегайте сложных вложенных цепочек, чтобы ускорить вычисления стилей. Например, .headline лучше, чем body div#main article h1.
• Применяйте современный CSS: используйте content-visibility: auto для отложенного рендера контента за пределами экрана. Это ускоряет начальную загрузку и снижает потребление памяти.

JavaScript

JavaScript часто замедляет страницы из-за объема и времени выполнения. Оптимизируйте его так:

• Заменяйте JS на HTML/CSS: используйте CSS-анимации, <details> или валидацию форм вместо JS, где возможно.

• Минимизируйте фреймворки: избегайте тяжелых библиотек для простых задач. Проверяйте сторонние скрипты (аналитика, реклама) и удаляйте ненужные.
• Разделяйте код: используйте динамический import() или возможности фреймворков для загрузки JS по необходимости.
• Предварительно загружайте важные скрипты: используйте <link rel="preload" as="script"> для ключевых JS-файлов.
• Применяйте async/defer: добавляйте эти атрибуты к <script>, чтобы не блокировать рендеринг. Defer сохраняет порядок выполнения, async подходит для независимых скриптов.
• Минимизируйте JS: используйте UglifyJS или tree shaking для удаления неиспользуемого кода. Настраивайте сборку для ES-модулей.
• Обновляйте зависимости: новые версии фреймворков (esbuild, SWC) часто быстрее. Используйте Renovate или Dependabot для автоматизации.
• Выбирайте подходящий фреймворк: Next.js с React Server Components или Astro с «островковой» архитектурой сокращают объем JS на клиенте, ускоряя загрузку.

Изображения

Изображения — один из главных факторов загрузки страниц. Оптимизируйте их так:

• Используйте правильный размер: не загружайте изображения больше, чем нужно для отображения. Инструменты вроде ImageMagick или Sharp помогут автоматизировать ресайз.
• Применяйте адаптивные изображения: используйте <img srcset> или <picture> для доставки изображений в зависимости от устройства.
• Сжимайте изображения: используйте ImageOptim, mozJPEG для JPEG, PNGQuant для PNG или SVGO для SVG.
• Предварительно загружайте ключевые изображения: используйте <link rel="preload" as="image"> или fetchpriority="high" для баннеров, влияющих на LCP.
• Откладывайте загрузку: добавляйте loading="lazy" для изображений ниже линии сгиба.
• Используйте WebP/AVIF: эти форматы обеспечивают лучшее сжатие, чем JPEG/PNG. CDN и фреймворки вроде Next.js автоматизируют конвертацию.
• Указывайте размеры: добавляйте width и height или CSS aspect-ratio, чтобы избежать сдвигов макета (CLS).
• Автоматизируйте оптимизацию: используйте Next.js <Image>, Astro или CDN (Cloudinary, Imgix) для автоматической обработки изображений.

Видео

Видео могут быть тяжелее изображений, поэтому требуют особого внимания:

• Сжимайте видео: используйте Handbrake для MP4/WebM, снижая битрейт или разрешение (например, 720p вместо 1080p).
• Используйте современные кодеки: WebM (VP9) или AV1 обеспечивают лучшее сжатие, чем MP4 (H.264).
• Настройте предварительную загрузку: используйте preload="metadata" или none для видео, чтобы не загружать лишние данные.
• Откладывайте загрузку: применяйте loading="lazy" для iframe или загружайте видео по клику/прокрутке.
• Удаляйте ненужное аудио: уберите звуковую дорожку из фоновых видео с помощью FFmpeg.
• Используйте потоковую передачу: для длинных видео применяйте HLS или DASH для адаптивной загрузки.
• Оптимизируйте сторонние видео: используйте облегченные встраивания (например, lite-youtube-embed) для YouTube/Vimeo.

Шрифты

Пользовательские шрифты улучшают брендинг, но могут замедлить рендеринг. Оптимизируйте их так:

• Ограничьте количество шрифтов: используйте минимум семейств и начертаний, чтобы сократить запросы.
• Применяйте WOFF2: этот формат компактнее TTF или WOFF и поддерживается всеми браузерами.
• Предварительно подключайтесь к источникам: используйте <link rel="preconnect"> для Google Fonts или других хостов.
• Используйте font-display: swap: это предотвращает FOIT (невидимый текст) и улучшает пользовательский опыт.
• Избегайте сдвигов макета: подбирайте резервные шрифты с похожими метриками или используйте font-size-adjust.
• Рассмотрите переменные шрифты: один файл заменяет несколько начертаний, снижая объем данных.
• Используйте системные шрифты: они не требуют загрузки и работают мгновенно.

Хостинг и сервер

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

• Используйте HTTPS: это не только безопасно, но и быстрее, благодаря HTTP/2+. Google учитывает HTTPS для SEO.
• Сократите HTTP-запросы: удаляйте ненужные ресурсы и минимизируйте сторонние скрипты.
• Перейдите на HTTP/2 или HTTP/3: HTTP/2 поддерживает мультиплексирование, HTTP/3 (QUIC) ускоряет соединение, особенно на мобильных сетях.
• Используйте CDN: кэшируйте ресурсы на серверах по всему миру для снижения задержек.
• Настройте кэширование: используйте Cache-Control для статических ресурсов и кэширование на уровне приложения.
• Оптимизируйте сервер: держите TTFB ниже 200 мс, оптимизируя запросы к базе данных и вычисления.
• Применяйте статическую генерацию: используйте SSG или ISR (Next.js) для доставки готовых HTML-страниц через CDN.

Быстрые улучшения

Эти небольшие оптимизации дают заметный эффект:

• Избегайте сдвигов макета: резервируйте место для изображений, iframe и динамического контента, чтобы минимизировать CLS.
• Используйте приоритеты: применяйте fetchpriority="high" для ключевых ресурсов и low для некритических.
• Сократите сторонние запросы: откладывайте загрузку аналитики или рекламы до взаимодействия пользователя.
• Используйте один протокол: избегайте смешанного контента (HTTP/HTTPS).
• Настройте кэширование: используйте длительный max-age для статических ресурсов с хэшами в именах файлов.
• Предварительно загружайте страницы: используйте <link rel="prefetch"> для вероятных переходов.
• Применяйте Service Workers: кэшируйте ресурсы для мгновенной загрузки и оффлайн-доступа.

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

1. TabNine

Если вам важна скорость — TabNine стоит попробовать хотя бы ради этого. Расширение — лёгкий AI-ассистент, который работает как умный автодополнитель кода, непохожий на аналоги вроде Codeium или Copilot.

TabNine обучен на миллионах строк открытого кода и умеет предсказывать, что вы напишете дальше, с учётом контекста проекта и языка. Отлично справляется с рутинными вещами: автозавершает функции, переменные, конструкции — всё быстро и чаще всего в тему.

Кому подойдёт: тем, кто хочет ускорить набор кода, но не готов передавать весь проект в облако или открывать чат с Copilot. Поддерживает офлайн-режим и локальное обучение модели.

Плюсы:

• Работает из коробки, не требует тонкой настройки;
• Есть локальная версия — удобно для закрытых проектов;
• Поддерживает большинство языков и фреймворков.

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

2. GitLens

GitLens встраивает историю изменений прямо в VSCode — и делает это максимально удобно. Показывает, кто и когда изменил строку, коммит-месседж, хэш, ветку и другие детали. Можно не уходить в консоль или отдельный Git-клиент для поиска информации.

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

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

Плюсы:

• Информация о коммитах отображается прямо в редакторе под строкой;
• Есть таймлайн изменений файла;
• Удобный diff по коммитам, авторам, веткам и даже фрагментам кода.

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

3. Error Lens

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

Можно настроить отображение: выделять ошибки цветом, добавлять иконки или даже показывать краткие подсказки с предложениями по исправлению. Поддерживает большинство языков и линтеров, включая ESLint, TypeScript и других.

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

Плюсы:

• Ошибки и предупреждения отображаются прямо в редакторе, рядом со строкой кода;
• Гибкая настройка стилей и уровня детализации сообщений;
• Ускоряет процесс отладки, особенно при работе с большими файлами.

Чем полезен: минимизирует время на поиск и анализ ошибок, позволяя сразу фокусироваться на их исправлении. Это особенно ценно, когда вы пишете код в реальном времени или работаете с новыми библиотеками, где легко допустить мелкие недочёты.

4. Path Intellisense

Path Intellisense — одно из тех расширений, которое просто работает и экономит кучу времени. Оно автоматически подсказывает пути к файлам, папкам и модулям в вашем проекте, как только вы начинаете их набирать. Поддерживает абсолютные и относительные пути, учитывает структуру проекта и форматирует предложения так, как это принято в выбранном языке.

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

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

Плюсы:

• Подсказки появляются автоматически при наборе пути;
• Поддерживает большинство языков и фреймворков;
• Учитывает jsconfig.json и tsconfig.json при работе с alias-ами.

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

5. TODO Highlight

TODO Highlight подсвечивает комментарии с задачами (например, TODO, FIXME, NOTE) прямо в коде, делая их заметными и удобными для отслеживания. Расширение помогает не терять важные заметки, которые вы оставляете в коде, и быстро находить места, требующие доработки.

Можно настроить ключевые слова, цвета подсветки и даже добавить свои собственные метки. Работает с любыми языками программирования и интегрируется с панелью задач VSCode для удобного обзора всех TODO в проекте.

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

Плюсы:

• Яркая подсветка TODO-комментариев прямо в редакторе;
• Гибкая настройка ключевых слов и стилей;
• Интеграция с панелью задач для быстрого обзора.

Чем полезен: экономит время на поиск и управление задачами в коде, помогая не упустить важные доработки или напоминания. Особенно удобно в больших проектах, где комментарии могут затеряться среди строк.

6. Prettier – Code formatter

Prettier — расширение, которое автоматически приводит ваш код к единому стилю, избавляет от ручной правки отступов, кавычек и переносов. Оно поддерживает множество языков (JavaScript, TypeScript, CSS, HTML и другие) и интегрируется с линтерами, чтобы ваш код был не только красивым, но и консистентным.

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

Кому подойдёт: разработчикам, которые хотят экономить время на форматировании, и командам, стремящимся к единообразию кода.

Плюсы:

• Автоматическое форматирование при сохранении или по хоткеям;
• Поддержка множества языков и кастомных настроек;
• Интеграция с ESLint и другими инструментами для проверки кода.

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

7. Live Server

Live Server запускает локальный сервер прямо из VSCode, позволяя просматривать изменения в HTML, CSS и JavaScript в браузере в реальном времени. После сохранения файла страница автоматически обновляется, что исключает необходимость ручного перезапуска или обновления браузера.

Поддерживает кастомные порты, HTTPS, и работает с любыми фронтенд-проектами, от простых HTML-страниц до сложных приложений на React или Vue. Можно настроить, чтобы сервер открывался автоматически при запуске проекта.

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

Плюсы:

• Автоматическое обновление страницы при изменении кода;
• Простая настройка и поддержка HTTPS для безопасного тестирования;
• Лёгкий запуск сервера прямо из редактора.

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

8. Project Manager

Если работаете над несколькими проектами одновременно — это расширение сэкономит вам часы. Project Manager позволяет создавать список избранных проектов и открывать их в один клик, без ручного поиска папок и недавних вкладок.

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

Кому подойдёт: разработчикам, которые ведут сразу несколько проектов, часто переключаются между ними и устали искать нужный путь через File > Open Folder.

Плюсы:

• Быстрое переключение между проектами через интерфейс или хоткеи;
• Поддержка избранного и тэгов;
• Можно автоматически подтягивать все папки из заданной директории.

Чем полезен: избавляет от рутинных действий при переходе между проектами — особенно когда важно не терять фокус и не сбиваться с рабочего темпа.

9. Code Spell Checker

Code Spell Checker выявляет орфографические ошибки в комментариях, строках и именах переменных прямо в редакторе VSCode. Расширение подчёркивает опечатки волнистой линией и предлагает варианты исправления через Ctrl+. или Cmd+., что позволяет быстро исправить ошибки.

Поддерживает множество ЯП и словари для разных языков (английский, русский, немецкий — с дополнительными расширениями). Можно добавлять свои слова в пользовательский словарь или игнорировать определённые термины, чтобы адаптировать проверку под проект. Работает с camelCase и snake_case, не помечая их как ошибки.

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

Плюсы:

• Мгновенное обнаружение ошибок с подсказками для исправления;
• Гибкая настройка словарей и игнорируемых слов;
• Поддержка технических терминов и различных стилей написания кода.

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

10. REST Client

REST Client позволяет отправлять HTTP-запросы и просматривать ответы непосредственно в VSCode. Достаточно создать файл с расширением .http или .rest, написать запрос в простом текстовом формате, и вы увидите кнопку Send Request для моментального выполнения.

Поддерживает все типы запросов (GET, POST, PUT, DELETE и другие), авторизацию (Basic, OAuth, JWT), переменные окружения и даже генерацию кода на разных языках. Запросы можно сохранять в репозиторий, что удобно для командной работы. Расширение также позволяет использовать динамические переменные по типу {{$timestamp}} или {{$guid}}, всё для гибкой настройки запросов.

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

Плюсы:

• Простая отправка запросов через .http или .rest файлы с кнопкой Send Request;
• Поддержка переменных окружения и авторизации для сложных API;
• Возможность сохранять запросы в репозитории для совместной работы.

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

А какими расширениями пользуетесь вы? Пишите в комментариях!

Главные отличия Web3 от Web2

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

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

В Web3 логика сильно меняется. Пользователь входит в систему с помощью криптокошелька, например, MetaMask. Каждая задача создаётся транзакцией и записывается в смарт‑контракт, а значит становится частью блокчейна. Удалить её уже нельзя — только отметить статус выполнения. Такой подход даёт прозрачность: любой участник сети может проверить, что задача действительно существует, и её статус изменён честно.

Стек Web3: что понадобится на практике

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

• Блокчейн: Ethereum, Layer‑2 (Arbitrum, Optimism, Base, Polygon), Solana.
• Языки: Solidity (EVM), Rust (Solana), Go (инфраструктура и сервисы).
• Библиотеки: ethers.js, wagmi.
• Фреймворки: Hardhat, Foundry, Truffle.
• Хранилища: IPFS/Arweave для файлов и метаданных.
• Кошельки/подключение: MetaMask, WalletConnect (v2/WalletConnect Network), Web3Auth.

Точка входа для новичка — Alchemy, а также ethers.js.

Пример. Быстрое подключение кошелька (ethers.js).

Архитектура DApp: из чего состоит современное Web3‑приложение

Любое Web3‑приложение строится из нескольких слоёв, каждый со своей ролью. Фронтенд остаётся привычным SPA, но работает не с сервером, а напрямую с кошельком и смарт-контрактами. Контракты содержат бизнес‑логику и хранят ссылки на данные в децентрализованных хранилищах. Оракулы обеспечивают связь с внешним миром, например, передают цены или сообщения между разными блокчейнами. Важную часть играет off‑chain слой — сервисы вне блокчейна (индексаторы, аналитика), которые помогают быстрее искать и обрабатывать данные, при этом не перегружать сеть.

Пример. Возьмём DeFi‑приложение. Пользователь открывает фронтенд и инициирует операцию swap(). В ответ фронтенд обращается к смарт‑контракту, который выполняет обмен токенов. Чтобы определить курс, контракт тянет актуальные данные через оракул. При этом тяжёлые артефакты, изображения или отчёты не хранятся в блокчейне напрямую — они лежат в IPFS. Сам контракт содержит только контент‑идентификаторы CID. Таким образом, получаем баланс: блокчейн отвечает за логику и безопасность, а децентрализованное хранилище — за данные.

Практика: ваш первый DApp за вечер

Давайте попробуем собрать простейшее приложение своими руками.

Шаг 0. Подготовка

Сначала убедитесь, что у вас стоит Node.js LTS и Git. Также нужен браузер с установленным MetaMask, где можно создать тестовый аккаунт. Чтобы оплачивать транзакции в тестовой сети, заранее возьмите немного тестовых монет через faucet — например, для Sepolia или Polygon Amoy.

Шаг 1. Проект

Создадим новый проект и установим Hardhat вместе с тулзами. Эта среда нужна для компиляции и деплоя контрактов.

Шаг 2. Контракт

В папке contracts/ создаём файл TaskTracker.sol и копируем туда код смарт-контракта из первого раздела. Это и будет бизнес-логика нашего приложения.

Шаг 3. Сценарий деплоя

Пишем скрипт, который разворачивает контракт в сети. Это простой скрипт на JavaScript, который вызывает методы Hardhat.

Шаг 4. Конфиг сети

В файле hardhat.config.js добавляем настройки для подключения к тестовой сети. Используем RPC-URL от Alchemy или Infura и приватный ключ от тестового аккаунта — его можно экспортировать из MetaMask, но использовать только для тестовой сети.

Шаг 5. Деплой в тестнет

Теперь запускаем скрипт деплоя. После выполнения увидите адрес контракта — он понадобится для фронтенда.

Шаг 6. Фронтенд (React + ethers.js + wagmi)

Собираем простое SPA: форма, чтобы добавить задачи, и кнопка «complete». Здесь мы используем ethers.js для обращения к контракту. Сделайте вызовы addTask и completeTask.

Подводные камни Web3-разработки и что с ними делать

Комиссии (gas): любая запись в блокчейн стоит денег и иногда комиссия выше ценности операции — например, $10 за простую задачу.

• Что делать: использовать Layer-2 (Arbitrum/Optimism/Base/Polygon), выбирать сети с низкими комиссиями (Solana, Avalanche), оптимизировать контракты и батчи транзакций.

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

• Что делать: показывать «оптимистичный UI», кешировать данные, переносить часть логики off-chain, использовать быстрые сети (Solana, Near, Aptos).

Безопасность: код контракта неизменяем, и одна ошибка может стоить миллионов.

• Что делать: проходить аудит (CertiK, Trail of Bits), использовать проверенные библиотеки (OpenZeppelin), писать тесты в тестовых сетях (Goerli, Sepolia), внедрять баг-баунти и ролевую модель доступа.
• Ресурс: ConsenSys Diligence — Smart Contract Security Best Practices.

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

• Что делать: использовать аккаунт-абстракцию (ERC-4337), социальный логин, gasless транзакции через Paymaster, улучшать UI (подсказки, авто-фокус на MetaMask).

Регуляция: законы о Web3 пока разные в каждой стране. Легальное в одной юрисдикции может быть запрещено в другой (например, токенизация акций без лицензии).

• Что делать: консультироваться с юристами, следить за изменениями. Например, MiCA в ЕС — “Markets in Crypto-Assets Regulation” — это единый регламент по криптоактивам в Евросоюзе.

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

Карьерные возможности и перспективы

Web3‑разработчиков уже активно ищут: зарплаты в среднем предлагают выше, чем у Web2‑коллег. Кроме программистов, востребованы смежные роли: аудиторы смарт‑контрактов, специалисты по безопасности, а также продакт‑менеджеры и аналитики, которые понимают специфику блокчейна.

Чтобы войти в профессию, начните с изучения Solidity и базовых паттернов смарт‑контрактов. Сделайте пару пет‑проектов и выложите код в GitHub. Отличный вариант прокачки — участвовать в хакатонах и грантовых программах от Ethereum Foundation или Solana Grants. Это даёт и опыт, и контакты, и иногда финансирование.

Пара пет‑проектов + понимание блокчейна — хороший старт в Web3‑команду.

Будущее Web3

Web3 не вытеснит Web2 полностью, но поменяет привычный подход к разработке. Разработчику это открывает новые вызовы: комиссии, безопасность и UX, но одновременно и новые возможности — прозрачные данные, токенизация, децентрализованные бизнес‑модели.

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

Web3 будет развиваться параллельно с Web2, усиливая те области, где важны децентрализация, доверие и контроль за данными. Попробуйте задеплоить первый контракт — и вы сами почувствуете, что это не просто мода, а новый уровень возможностей.

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

Главное из нововведений

• 64-битная адресация: теперь Wasm может использовать i64 вместо i32, что расширяет лимит адресуемой памяти с 4 ГБ до 16 ЭБ (в реальности — до 16 ГБ в браузерах).
• Несколько областей памяти: модули теперь могут напрямую использовать и копировать данные между разной памятью, без обходных трюков с импортом других модулей.
• Сборка мусора (GC): добавлена поддержка управляемой памяти для языков с автоматическим управлением памятью (например, Java, Scala, Kotlin, Dart).
• Типизированные ссылки: улучшенная типизация ссылок и функций позволяет избежать лишних проверок в рантайме.
• Исключения: наконец-то появилась полноценная система обработки исключений — с try, throw и catch, как в других языках.
• Хвостовые вызовы: позволяют не занимать стек при возврате через вызов, что критично для функциональных языков и оптимизаций.
• Расслабленные SIMD-инструкции: добавлены быстрые, но менее детерминированные версии векторных инструкций для повышения производительности.
• Детерминированный профиль: теперь для задач с требованием полной воспроизводимости (например, блокчейны) можно включить строго определенное поведение операций.
• Аннотации в тексте: появилась возможность вставлять пользовательские аннотации прямо в текстовый формат .wat.

Что это значит

WebAssembly становится всё ближе к полноценной виртуальной машине для высокоуровневых языков. В новой версии уже появляются компиляторы для Java, OCaml, Scala и прочих ЯП — благодаря поддержке GC и исключений.

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

Репозиторий уже собрал почти 65 000 звезд на GitHub. Разбираемся, как он устроен и какие интересные модули лежат внутри.

Что делает этот алгоритм

Алгоритм отвечает за то, какие посты и аккаунты вы видите на всех основных страницах в X: от рекомендаций и трендов до пушей. Внутри — десятки сервисов и моделей, взаимодействующих между собой.

Например, компонент home-mixer собирает кандидатные твиты из разных источников (например, через search-index, tweet-mixer, user-tweet-entity-graph) и ранжирует их при помощи легкой и тяжелой нейросети (light-ranker, heavy-ranker).

После этого подключаются фильтры (например, visibility-filters), которые убирают нежелательный контент и скрытые посты.

Из чего это все собрано

Проект построен на Scala (66%), Java (20%) и Rust. Некоторые модули используют Python и даже TensorFlow v1 (например, twml). Базовые компоненты включают:

• Данные — tweepypie, unified-user-actions, user-signal-service
• Модели — SimClusters, TwHIN, real-graph, tweepcred, trust-and-safety-models
• Фреймворки — navi (на Rust), product-mixer, representation-scorer, representation-manager

Также присутствуют специфические компоненты для пушей — сервис pushservice, ранжирующие модели pushservice-light-ranker и pushservice-heavy-ranker, предсказывающие, откроет ли пользователь уведомление.

Почему это важно

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

Во-вторых, открытый код — это редкость в мире коммерческих рекомендаций, особенно на таком масштабе.

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

Что это значит для разработчиков

Этот проект — хорошее поле для изучения реального промышленного машинного обучения. Особенно интересны:

• плотные графовые эмбеддинги в TwHIN
• модели репутации и социальной близости в real-graph и tweepcred
• многозадачные модели в pushservice-heavy-ranker

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

Модель создана с нуля, обучена на реальных пулл-реквестах и задачах из практики. Она уже доступна в IDE.

Новая глава в «вайб-кодинге»

Модель grok-code-fast-1 от xAI позиционируется как конкурент решениям от OpenAI, Google и Anthropic. Она оптимизирована для разработки на TypeScript, Python, Java, Rust, C++ и Go, а значит покрывает большинство реальных кейсов в современной разработке.

Модель уже интегрирована в IDE и CLI вроде GitHub Copilot, Cursor, Cline, Roo Code, Kilo Code, OpenCode и Windsurf. В ближайшее (но ограниченное) время она будет доступна бесплатно.

Быстрая, дешевая и довольно-таки умная

xAI делает ставку на цену, скорость и удобство. Стоимость использования grok-code-fast-1:

• $0,20 за 1 млн входных токенов
• $1,50 за 1 млн выходных токенов
• $0,02 за 1 млн кэшированных входных токенов

Во внутреннем бенчмарке SWE-Bench-Verified, модель показала результат 70,8%, но независимых тестов пока нет — их ждут в ближайшие недели.

В xAI утверждают, что при создании модели основное внимание уделялось практическому использованию и удобству в реальных задачах. Якобы разработчики оценили grok-code-fast-1 как «быструю и надежную» при повседневной работе с кодом.

До 160 токенов в секунду и 90% кэш-хитов

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

Кроме того, реализовано кэширование подсказок, которое обеспечивает до 90% попаданий при работе с GitHub Copilot и другими интеграциями. Это позволяет существенно сократить задержки и стоимость использования.

Мы поговорили с экспертами и попросили их поделиться задачами, которые помогут прокачать логику и навыки работы с данными. Заодно узнали, зачем вообще новичку браться за алгоритмы. Решения оставим в комментариях. Не подглядывайте сразу, а сначала попробуйте свои силы.

Зачем вообще решать алгоритмические задачи

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

Разработчик Валерий Жила говорит, что на алгоритмы можно смотреть по-разному:

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

А Константин Шибков, senior Java-разработчик в СДЭК, автор канала «Три монитора», вспоминает, что задачи стали для него тренировочным залом для мозгов:

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

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

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

В бигтехе эти навыки проверяют особо тщательно: Яндекс, OZON и другие компании любят устраивать отдельные алгоритмические сессии. Бонусом вы будете готовы и к ним.

Простые задачи — лучший вход

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

Например, Merge Two Sorted Lists — простая задача, которая учит работать с указателями. Разобравшись, можно попробовать Merge k Sorted Lists — это более сложная задача с тем же базовым подходом.

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

Почему простые задачи действительно приносят пользу:

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

Где искать задачи для практики

Загляните на специальные онлайн-сервисы для практики алгоритмического программирования. Вот список популярных в русскоязычной среде сайтов:

• LeetCode — мировой лидер, база задач от простых до сложных для подготовки к интервью
• Codeforces — сообщество для соревнований и обучения
• CodeRun — российская платформа с задачами на алгоритмы и регулярными контестами
• Timus Online Judge — портал с архивом олимпиадных задач, востребованный у студентов и олимпиадников
• Advent of Code — ежегодный онлайн-марафон задач в формате адвент-календаря, стилизованный под приключения
• Codewars — геймифицированная платформа с заданиями по разным языкам и уровням сложности

Как-то раз я завалил экзамен по алгоритмам в университете, будучи уверенным, что предмет — элементарный. Взялся за материалы, LeetCode, Advent of Code, Codewars и пару месяцев плотно ими занимался. Решал по 5−10 задач в день. Экзамен я пересдал на отлично. На последующих собеседованиях уже получалось интуитивно нащупывать решения.

Что решают разработчики, чтобы держать мозг в тонусе

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

Валерий Жила:

1. Two Sum — найти два числа в массиве, сумма которых равна заданному значению. Чему учит: работать с хэш-таблицами и быстро находить соответствия. Базовый паттерн, который часто встречается в других задачах.
2. Number of Islands — посчитать количество связных компонент на карте. Чему учит: обходить граф DFS/BFS, думать в терминах связности элементов.
3. Decode String — декодировать строку с вложенными структурами. Чему учит: использовать стек, вложенные циклы и парсинг данных.

Совет: «Если сухой LeetCode наскучил, попробуйте Advent of Code».

Константин Шибков:

1. Maximize Distance to Closest Person — выбрать место в ряду, чтобы максимизировать расстояние до ближайшего соседа. Чему учит: работать с краевыми случаями, искать оптимальную позицию по условию.
2. Merge Two Sorted Lists — объединить два отсортированных списка в один. Чему учит: работать с указателями и аккуратно обрабатывать данные в упорядоченных структурах.
3. Move Zeroes — переместить все нули в конец массива, сохранив порядок остальных элементов. Чему учит: оптимизировать алгоритм без создания дополнительных структур.
4. Partition to K Equal Sum Subsets — разделить массив на K подмножеств с равной суммой элементов. Чему учит: использовать поиск с возвратом, оптимизировать перебор.

Никита Дубко, старший руководитель продуктов Яндекс Контеста, автор канала mefody.dev

1. Мандарины и апельсины 2.0 — выбрать n ящиков так, чтобы в них оказалось не менее половины всех мандаринов и апельсинов. Чему учит: использовать свойства возрастающих последовательностей, минимизировать количество проходов по данным и находить решение без полного перебора.
2. Ча-ча-ча — определить итоговую оценку по набору буквенных оценок с ограничением, что итог не может быть более чем на балл выше худшей. Чему учит: работать со строками и символами в ASCII/UTF-8, а также применять решение в лоб, когда оно эффективно.

Совет: «Тренируйтесь не только решать, но и объяснять, почему ваш алгоритм работает и укладывается в ограничения. Этот навык ценят на собеседованиях».

Как не сломаться на старте: выгорание и ошибки новичков

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

Главные ловушки:

• Гонка на износ. План «100 задач за месяц» звучит амбициозно, но в реальности превращается в марафон без подготовки.
• Залипание на одной задаче. Если вы часами бьётесь над решением, азарт сменяется усталостью.
• Кажется, что все остальные ушли далеко вперед. Вы видите только чужие успехи, но не видите их ошибки.
• Синтаксическая ловушка. Новички пытаются угадать код, вместо того чтобы проработать логику на бумаге.
• Держать всё в голове. Легко потеряться в деталях, если не набросать план на бумаге.

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

Что советуют эксперты:

• Решайте по одной задаче в день, как утреннюю разминку для мозга.
• Чередуйте лёгкие и средние задачи, чтобы тренироваться в комфортном темпе, но с небольшим вызовом. Так вы будете расти без ощущения, что тонете.
• Если за час решение не приходит, то посмотрите разбор без кода, а затем напишите свой вариант.
• Отмечайте, какой приём вы отработали — это даёт чувство прогресса.
• Записывайте решение пошагово. Даже опытные разработчики часто начинают с блокнота.

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

Как продолжать развиваться

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

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

• сортировки,
• графы,
• строковые алгоритмы,
• деревья.

2. Устройте себе челлендж. Например, «30 задач за 30 дней». Берите не количеством, а регулярностью. Можно чередовать дни по уровням сложности.

3. Используйте готовые подборки. Есть отличные списки от экспертов. Приведём лишь некоторые из них

• LeetCode Patterns — задачи сгруппированы по типам и темам;
• Blind 75 — 75 самых популярных задач для собеседований;
• GfG‑160 — 160 задач для тех, кто хочет по-настоящему прокачать алгоритмы

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

Однажды на работе мне нужно было распределить посылки по ячейкам постамата так, чтобы максимально эффективно использовать пространство. По сути, это была вариация задачи Partition to K Equal Sum Subsets: разложить элементы по контейнерам без перегруза. Я использовал поиск с возвратом и оптимизацию, которые до этого отрабатывал на алгоритмических задачах. Закрыл задачу быстрее, чем если бы разрабатывал всё с нуля.

Но стоит учесть, что код на LeetCode отличается от того, что мы обычно пишем в прод. У нас на работе даже есть локальный мем «по-литкодовски», когда код — максимально короткий, без попытки быть понятным и простым. Главное для него — быть эффективным. Когда переносишь алгоритмы решения в реальный мир, нужно выделять алгоритм в изолированный класс или метод. Так вы сможете проверить его тестами и сделать более понятным для других.

Выводы

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

Читайте также:

Алгоритм Дейкстры: как работает и где используется

ТОП-15 алгоритмов, которые реально нужны на бэкенде

Что такое хэш-таблицы и как их использовать

Квиз: какой стек технологий тебе подходит?

Рабочий план: как изучить новый стек за 3 месяца

Недавно я столкнулся с одной проблемой на реальном проекте. У меня есть сайт: бэкенд написан на Spring, а фронтенд — на Angular. Я добавлял новую форму для отправки отзыва пользователя и, в спешке, забыл добавить валидацию на одно из полей формы на фронтенде.

Я хотел, чтобы поле «комментарий» было обязательным и имело длину от 1 до 100 символов. На бэкенде использовал аннотацию @Size(min = 1, max = 100) к обязательным полям, например для поля `comment` в моем DTO имеет такой вид:

Тест с пустой строкой {"comment": ""} был корректно отклонён. Однако, когда я отправил запрос без поля "comment" вообще ( {} ), валидация прошла успешно, и поле «comment» пришло как null. Это была серьёзная ошибка — поле, которое по логике было обязательным, могло быть пропущено. Т.е. могли потеряться важные для меня данные.

Почему так происходит?

Причина кроется в спецификации JSR-303 (Bean Validation). Документация (Javadoc) для аннотации @Size прямо указывает: «null elements are considered valid». Это означает, что если значение поля null, валидатор @Size считает его валидным и не выполняет проверку длины.

Это поведение подтверждается и в исходном коде валидатора. Метод, отвечающий за проверку строки, сначала проверяет значение на null, и если оно null, сразу возвращает true, не переходя к проверке размера. Это стандартное поведение для многих аннотаций валидации, таких как @Min, @Max, @Pattern и т.д. Они проверяют качество значения, но не его наличие.

Предлагаемое решение

Чтобы поле было действительно обязательным (не null и не пустое), необходимо использовать аннотации, которые проверяют наличие значения - это @NotNull, @NotEmpty, @NotBlank . Для строк лучшим выбором является комбинация:

Понимание разницы между этими аннотациями критически важно:

• @NotNull: Гарантирует, что значение поля не является null. Однако оно не проверяет пустые строки или строки из пробелов и будут считаться валидными.

• @NotEmpty: Гарантирует, что значение не null и не пустое (для строки длина > 0). Это означает, что "" будет отклонено, но строка из одних пробелов " " пройдёт валидацию, так как её длина больше 0.

• @NotBlank: Предназначена исключительно для String. Гарантирует, что строка не null, не пустая и после удаления пробелов с начала и конца (trim) имеет длину больше 0. Это означает, что null, "" и " " будут отклонены. Именно это поведение обычно ожидается от "обязательного текстового поля".

Красивое возвращение ошибок

Для того чтобы клиент (в моём случае, Angular-приложение) получал понятные сообщения об ошибках валидации, я настроил глобальный обработчик исключений с помощью @ControllerAdvice. Когда валидация не проходит, Spring выбрасывает MethodArgumentNotValidException. Далее, я его перехватываю и возвращаю структурированный ответ.

Angular-приложение может легко обработать этот JSON и отобразить пользователю понятное сообщение об ошибке.

Выводы

Аннотация @Size сама по себе не делает поле обязательным. Она проверяет только длину, если значение не null. Для обязательных строковых полей всегда используйте @NotBlank. Для других типов данных используйте @NotNull.

Не полагайтесь на @Size(min = 1) как на замену проверки на null или пустую строку. Эта ловушка, в которую я сам попался, может привести к консистентным данным в вашей системе и потенциальным уязвимостям, если бэкенд будет работать с неожиданными null значениями. Всегда явно указывайте, что поле является обязательным, с помощью соответствующих аннотаций.

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

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

Михаил сделал клон страницы Яндекс Поиска, чтобы испробовать все нововведения (Baseline), поддерживаемые в браузерах на 2025 год. У каждой фичи есть веб-платформенные тесты от сообщества — набор кейсов, который проверяет функциональность. Многие из фичей, несмотря на то, что находятся в Baseline 2025 года, не имеют 100% покрытия тестов.

Гриды и сабгриды

За основу Layout страницы взяли гриды, которые находятся в продакшене уже более 8 лет.

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

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

Это позволяет за счёт изменения одного свойства родителя полностью изменить внешний вид элемента — например, сделать иконки разного размера.

Но это ещё не всё. Если мы сверстали карточку в ленте фида, она получилась классной, но тестирование указало нам на проблемы с доступностью. У нас не оказалось тега <article> и тега anchor element <a> для ссылки. Но при добавлении этих тегов вёрстка может поплыть.

Если вы используете сабгриды, всё нормально — будет унаследована сетка родителя, и элемент останется красивым. Это позволяет верстать блок без использования position легко и удобно.

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

Масштабирование

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

Достигается это за счёт того, что страница свёрстана в em — это величина, которая меняет размер шрифта. А меняя его, мы меняем размер элементов. Раньше это писалось с помощью медиа-выражений, который зависит от min-width, то сейчас есть возможность упростить визуальный синтаксис, добавив интервальный. Он позволяет дописать больше или равно/ меньше или равно — то, что человеку понятнее. Есть post css плагин, который позволяет завезти это поведение для старых браузеров, чтобы всё работало хорошо.

А можно ещё сильнее упростить код, за счёт использования css Nesting из baseline 2023. Поэтому в браузерах новее 2023 года это работает из коробки, а в более старых можно с помощью post css плагина затрансперировать поведение, чтобы всё корректно работало. Тем самым, мы сэкономим немного строк кода.

Но можно пойти ещё дальше в будущее к @function, и в 139 Chrome уже пообещали запустить эту функциональность, но пока доступна только в Chrome Canary браузере (для опытных разработчиков). Позволяет заменить mix in в CSS, SASS для препроцессинга.

Но можно пойти в @property. Поддерживается почти во всех браузерах и позволяет задать кастомное свойство, задать значение по умолчанию и узнать, наследуется ли оно. Здесь мы задаём стандартное значение размера шрифта в em, потому что оно зависит от контекста. По спецификации initial value должно быть постоянным значением, которое не изменяется нигде.

Отказ от SASS — не всё так просто

Если у нас есть полоска сервисов, которые в зависимости от размеров экрана меняют свой размер, то за счёт селектора nth-child мы можем указать: возьми все элементы, начиная с n, кроме all, и примени к нему display: none. А внутри медиа-выражение в зависимости от размера экрана срабатывает по-разному. У медиа-выражений есть явная проблема: если у нас меняется продуктовое поведение, например, размер блока или расположение компонента, то все стили устаревают и медиа-выражения приходится заново переписывать.

Но у нас появились container queries, которые позволяют мэтчиться не на размер страницы, а на размер конкретного элемента — ширину или высоту. Работает с 2023 года, но в продакшен тащить рано — в старых браузерах вёрстка поедет.

Код в примере очень репетативен — мы повторяем одно и тоже много раз.

Можно ли написать вот так?

Но в таком коде есть много проблем, он не работает и никогда не будет работать.

В container queries у нас есть константы, можно использовать calc, чтобы сложить em и пиксели. Но мы не можем там использовать CSS-переменные, браузер их просто проигнорирует. А в nth-child всё ещё хуже: можно использовать только целочисленные значения.

Postcss-Preset-Env

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

Попап сервисов (dialog)

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

В будущем это должно будет работать так:

Но спецификация до сих пор не стабилизирована. Всё, кроме закрытия по парандже работает без JS. Есть полифил (polyfill), но для его работы нужно писать дополнительные селекторы и он не работает без JavaScript, нет понятия Top Layer.

Меню в фиде

В любой элемент страницы, будь то div, span или dialog, нужно добавить интерактивности, чтобы он открывался по клику. В сочетании с micro position меню позиционируется рядом с кодом без единой строчки JS и работает с 2025 года, то есть через пять лет можно будет затащить решение в продакшене.

Прогрессивные улучшения

Пользователи старых браузеров эти улучшения не получают, но их опыт не ухудшается, а это важно.

Сюда входят дискретные анимации для бинарных свойств с помощью allow-discrete. Так значение свойств изменится только к концу анимации.

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

Но оказалось, что прогрессивные улучшения могут навредить пользователям. В 120 и 121 Chrome есть баг, который крашит браузер. Совет — экспериментировать, проверять и замерять.

Scrollbars

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

Появился Scrollbar Styling первого уровня, который позволяет делать красивые скроллбары. Есть набор констант от none до thin, и можно задавать цвет как самого трекера, так и подложки.

Но Scrollbar может всё равно вылезать за пределы страницы, а ещё сложно управлять цветом и расположением элемента.

Чтобы это исправить, можно использовать другое свойство без стабильной спецификации, поддерживаемое во всех браузерах — это webkit-scrollbar.

Правда с его помощью не получится добиться красивого скругления. Но сочетать webkit-scrollbar и scrollbar-styling не выйдет. Либо одно, либо другое.

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

Рекомендация — всегда добавлять на html-тег это свойство, чтоб проблем не было и интерфейс не оказался сдвинут.

Анимации

Также сейчас можно сдвигать элемент на чистом CSS без использования JS — с помощью animation timeline scroll или animation timeline view.

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

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

Например, в этом случае два элемента будут наплывать друг на друга или произойдёт мерцание.

View Transition API

API крайне мощный, но пока не очень поддерживается.

Итоги

• Переменные уже заменены и их можно использовать $name->var(-name).
• Миксины через 5 лет можно будет заменить mixin->@function.
• Нативный нестинг — хорош!
• Даже функция if() уже доступна в Chrome136.
• Не скоро ещё можно будет отказаться от языков препроцессинга, например, от SASS.
• Область использования var() и env() ограничена.
• CSS не умеет в циклы.
• @function пока слишком рано использовать.
• Но мы можем перейти на CSS + Post CSS. И в Яндекс Поиске пошли по этому пути. При этом во всей кодовой базе mix in использовались всего несколько раз. Поэтому оказалось что функции препроцессора особо не используется. От нестига пришлось мигрировать — но это было не сложно.
• Popover и полифилл есть в baseline 2025, но не все wpt проходят.
• Полифилл имеет ограниченную поддержку.
• Полифилл не работает в браузерах с частичной поддержкой popover.
• Anchor-positioning есть в Inerop 2025 и у него есть полифилл, но спецификация ещё меняется.
• Полифилл не поддерживает множество кейсов — практически никакие, кроме базовых.
• Даже прогрессивные улучшения могут навредить.

Давно пора исползовать:

• Dialog — упрощает написание кода и работает даже в старых браузерах с полифоллом.
• CSS Nesting и CSS — Variables упрощают написание стилей и хорошо работает в связке с PostCSS.
• Grid Layout — упрощает вёрстку сложных сайтов и работает в браузерах 8-летней давности.

Через пять лет вёрстка сильно изменится за счёт новых фичей, которые появляются уже сейчас! А какую из фичей вы желаете больше всего затащить в продакшен?

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

Бонус — комментарии экспертов с многолетним опытом работы за границей и глубоким пониманием международного рынка труда.

Какие IT-профессии наиболее востребованы за рубежом

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

• менеджеры по продажам и работе с клиентами (13%),
• операторы колл-центров (5%),
• дизайнеры, менеджеры по маркетингу, интернет-маркетологи, художники (по 4%),
• учителя, SMM- и контент-менеджеры (по 3%),
• секретари, помощники руководителя, ассистенты (по 2%).

Программисты и разработчики заняли почётное второе место (10%). А специалисты технической поддержки и тестировщики набрали всего по 2%.

Но в исследовании образовательной онлайн-платформы «Нетология» и международного коммуникационного агентства Zecomms Agency специалист технической поддержки — наоборот, наиболее востребованная профессия за рубежом. С ним связано 17% от общего массива IT‑вакансий, что делает специалиста техподдержки абсолютным лидером по количеству открытых вакансий.

На втором месте расположился программный инженер (16%), на третьем — бизнес-аналитик (6%) и IT-консультант (6%).

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Российские IT-специалисты всё ещё остаются востребованными за рубежом, но по сравнению с 2022 годом ситуация изменилась. Международные компании уже не так охотно берут в штат сотрудников из России, известны случаи сокращений из-за гражданства. Причина — политика компаний, особенно тех, которые решили покинуть российский рынок. Зато за последние три года многие отечественные стартапы релоцировались в другие страны, и они отдают предпочтение сотрудникам из России.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

Согласно исследованию «Нетологии» и Zecomms Agency, Java признан самым популярным языком программирования — его активно используют компании по всему миру. На Java приходится более четверти всех открытых вакансий (26%) в сфере IT в Европе, США, Латинской Америке, Азии и на Ближнем Востоке.

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

На втором месте по популярности находится язык SQL, который используют для разработки баз данных и систем аналитики. На него пришлось 24% всех вакансий, бóльшая часть из них в Европе, Азии и на Ближнем Востоке.

Замыкает тройку лидеров Python (23%) — более половины открытых вакансий в Азии и на Ближнем Востоке связано именно с этим языком. Оно и неудивительно: на Python пишут модели для машинного обучения, анализа данных и автоматизации.

Сколько айтишникам платят за границей

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

Но ключевое — размер оклада. По данным «Профсоюза работников ИТ», медианная зарплата специалистов уровня senior в России составляет 276 362 рубля в месяц, в то время как за рубежом она равна 386 730 рублей в месяц. Российские миддлы получают 170 000 рублей, а работающие за границей — 205 142 рубля. Зарплата джунов несильно отличается, хотя «за бугром» она всё-таки немного больше: 85 000 рублей против 80 000 рублей в России.

Таким образом, зарплата IT-специалистов за рубежом как минимум в 1,5 раза больше, чем в России.

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

Где IT-кадры пользуются спросом

Найти работу в IT сейчас везде нелегко, но чуть проще это сделать там, где активно развивается IT-сектор и требуется много кадров соответствующего профиля:

Германия. Наибольший дефицит IT-специалистов наблюдается в Германии — в 2023 году было опубликовано 103 089 вакансий. Особенно остро нехватка кадров ощущается в таких областях, как разработка программного обеспечения, Data Science, кибербезопасность и DevOps. А в 2025 году страна планирует выдать на 10% больше рабочих виз, чем годом ранее.

Нидерланды. В стране большое внимание уделяется IT-стартапам. Так, в 2024 году голландские технологические компании привлекли €3,7 млрд венчурных инвестиций — это около 5% от общего объёма капитала, вложенного в европейскую экосистему. Благодаря этому Нидерланды вошли в топ‑10 стран Европы по объёму инвестиций в технологии. Особенно быстро растёт сектор DeepTech («глубоких технологий») — полупроводники, искусственный интеллект и квантовые технологии.

Канада. Такие канадские города как Торонто, Ванкувер и Монреаль считаются настоящей IT-меккой. Здесь активно развиваются стартапы и работают подразделения крупнейших технологических компаний — Google, Microsoft, Amazon. Кроме того, для IT-специалистов есть много иммиграционных программ, например, Global Talent Stream, которая позволяет получить разрешение на работу в течение двух недель.

США. В 2023 году объём IТ-рынка США достиг $1,3 трлн и продолжает развиваться высокими темпами. В Европейском союзе он составил $1,05 трлн, в Китае — $348 млрд, в России — $36,1 млрд. Таким образом, американский технологический рынок в 36 раз больше российского, в 1,24 раза больше европейского и почти в четыре раза превосходит китайский. Это подтверждает его статус мирового лидера. Соответственно, IT-специалистов нужно много.

Куда уехать проще всего

По данным HeadHunter, активнее всего российских специалистов приглашают на работу компании из:

• Белоруссии — 172,3 тыс. приглашений,
• Казахстана — 150,9 тыс. приглашений,
• Грузии и Турции — 69,7 тыс. и 67,8 тыс. приглашений соответственно,
• Узбекистана — 57,2 тыс. приглашений.

Самый большой рост интереса продемонстрировали китайские работодатели — он увеличился почти в шесть раз. В 2023 году количество предложений для жителей России о работе в Китае составляло всего 4,8 тыс., тогда как в 2024 году цифра достигла 27,6 тыс. предложений.

Кроме того, за год потребность в российских специалистах выросла в Сербии с 5,8 тыс. до 26,3 тыс. (+356,3%), в Турции — с 23,5 тыс. до 67,8 тыс. (+188,6%), на Кипре — с 4,6 тыс. до 12 тыс. (+160,9%), в Польше — с 4,1 тыс. до 9,0 тыс. (+119,6%) и в ОАЭ — с 19,2 тыс. до 41,7 тыс. (+117,2%).

А Европа стала лидером по количеству предложений для IT-специалистов со знанием русского языка — 3% всех IT-вакансий в регионе. На других рынках доля таких предложений не превышает 1%. Чаще всего русскоязычных специалистов ищут в Польше — 2 200 вакансий, Венгрии — 752 вакансии, Австрии — 178 вакансий, Греции — 152 вакансии.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Не все страны охотно принимают специалистов из других стран. Если раньше одними из самых популярных направлений для релокации были Канада и США, то сейчас переехать туда стало значительно сложнее. Больше шансов на трудоустройство в компании Испании, Португалии, Кипра, ОАЭ.

Как IT-специалисту найти работу за границей: четыре шага

1. Зарегистрируйтесь на международных платформах

Принцип поиска работы за рубежом такой же, как и в России. Нужно зарегистрироваться на платформах по типу HeadHunter и откликаться на понравившиеся вакансии. Чем больше откликов, тем лучше.

Вот подборка сайтов для поиска работы за границей:

• LinkedIn — профессиональная социальная сеть, где можно искать вакансии и налаживать контакты;
• Indeed — международный агрегатор вакансий, позволяющий фильтровать их по странам, городам и отраслям;
• Relocate.me — платформа для вакансий с релокацией;
• Remote OK — площадка для поиска удалённой работы;
• WWR — сервис, где публикуют вакансии крупные зарубежные компании, например, Amazon или Google.
• AngelList Talent — каталог вакансий в иностранных стартапах.

Некоторые из них открываются только с VPN.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Удобнее всего искать вакансии зарубежных компаний через LinkedIn. По моему опыту, большинство специалистов находят работу за границей именно через эту площадку. Но есть и альтернативные варианты — например, телеграм-каналы с профильными вакансиями. Будьте готовы к тому, что придётся отправлять много откликов. В среднем на 100 откликов приходится не более 5 ответов.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

В основном я искал работу через LinkedIn. Это самая эффективная платформа: я обновил профиль, загрузил резюме и активно взаимодействовал с рекрутерами. Также полезно размещать резюме на популярных job-порталах и быть открытым к предложениям — тогда многие специалисты по подбору персонала сами выходят на связь.

2. Адаптируйте резюме для иностранного рынка

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

Эксперты компании EP Advisory, которая помогает российским специалистам строить карьеру за рубежом, рекомендуют включать в CV разделы Name, Profile, Education, Experience, Skills & Other. Названия предыдущих компаний и занимаемые должности следует выделять, а каждый блок — разграничить чертой.

Кроме того, в некоторых странах, например, Великобритании, США и Канаде не принято добавлять фото в резюме. Такое правило стало следствием законов против дискриминации в этих странах, поэтому его несоблюдение может вызвать негативную реакцию и привести к мгновенному отказу.

Дополнительно к резюме стоит приложить мотивационное письмо (Cover Letter), подготовленное специально под конкретную вакансию. В мотивационном письме уже не пишут об образовании и навыках — эти сведения указывают только в резюме. А в Cover Letter особый упор делается на кейсах и объяснении, чем для вас интересна компания и почему вы для неё — самый подходящий кандидат.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Необходим большой и подтверждённый опыт работы. Придётся конкурировать со специалистами уровня senior со всех концов света. Особенно много кандидатов из Индии, Ирана, Пакистана.

3. Обратитесь в агентство по трудоустройству

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

Вот список наиболее известных рекрутинговых агентств:

• Adecco — крупнейшее агентство с вакансиями по всему миру;
• Manpower — международная стаффинговая, аутсорсинговая и HR-консалтинговая компания из России;
• Michael Page — международная компания, которая специализируется на подборе персонала среднего и высшего звена;
• Hays — британская рекрутинговая компания, которая предоставляет услуги по подбору персонала в 33 странах мира;
• Harvey Nash — международная компания, которая специализируется на IT-аутсорсинге;
• Randstad — голландская консалтинговая компания, которая сотрудничает с ведущими зарубежными работодателями.

Агентства также консультируют по вопросам адаптации и помогают с поиском жилья.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

Чтобы найти работу в Лондоне, я сотрудничал с международными и британскими рекрутинговыми агентствами — Hays, Harvey Nash и Michael Page. Примерно 50% предложений приходили именно от них. Эти агентства играют важную роль на IT-рынке и обладают широкой сетью контактов с работодателями по всей Европе. Они помогали мне в поиске подходящих позиций и сопровождали на всех этапах — от первичного отклика до собеседования и подписания оффера.

4. Получите визу и разрешение на работу

Без визы и разрешения приступить к работе за границей не получится. Здесь доступны два варианта — Digital Nomad Visa или обычные рабочие визы.

Digital Nomad Visa. Digital Nomad Visa или «виза цифрового кочевника» позволяет легально жить за рубежом, но при этом продолжать удалённо работать на родину. В отличие от туристической визы, Digital Nomad Visa даёт право длительно находиться в определённой стране, а в сравнении с рабочей визой — не требует трудоустройства на местном рынке.

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

Чтобы получить визу цифрового кочевника, нужно подтвердить минимальный доход (чаще всего не ниже 2000 евро в месяц) и наличие медицинской страховки. Также может понадобиться трудовой договор или договор подряда, доказывающие, что вы работаете удалённо. Сейчас Digital Nomad Visa оформляют в 66 странах, включая Португалию, Испанию, Эстонию, ОАЭ и Южную Корею.

Классические рабочие визы. Это визы EU Blue Card или виза H‑1B.

• Голубая карта (EU Blue card) — виза для работы в Европе. Чтобы получить её, нужен диплом о высшем образовании (не ниже бакалавра) и оффер с зарплатой от 48 300 евро год (43 760 евро для IT‑специалистов) на срок минимум шесть месяцев. В случае одобрения выдаётся вид на жительство, действующий до четырёх лет с возможностью продления.

• Виза H‑1B — виза для работы в США. Она также требует наличия высшего образования и оффера от местной компании. Но американское законодательство устанавливает лимит на выдачу H‑1B — 65 000 базовых и 20 000 дополнительных виз для специалистов с магистерской степенью из США. Всего 85 000 виз в год. Виза предоставляется максимум на три года с возможностью продления до шесть лет.

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

Официальное трудоустройство или фриланс

Удалённая работа на фрилансе

Фриланс — самый простой способ начать работать с зарубежными компаниями без лишней бюрократии и сложностей с оформлением. Достаточно зарегистрироваться на зарубежную фриланс-платформах Upwork или Fiverr, и можно сразу браться за международные проекты. Единственное, могут возникнуть трудности с оплатой, поэтому стоит завести себе иностранную банковскую карту.

Главные минусы фриланса — нет оплачиваемого отпуска и больничных, а доход крайне нестабилен.

Официальное трудоустройство с релокацией

Официальное трудоустройство гарантирует стабильную зарплату и полный соцпакет, а при релокации — помощь с переездом и адаптацией в новой стране.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Какой уровень владения английским языком нужен

Для оценки владения иностранными языками, включая английский, в Европе используют систему CEFR (Common European Framework of Reference). CEFR выделяет шесть уровней знания языка: A1, A2, B1, B2, C1, C2.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Обязательное требование — свободное владение английским: например, в Португалии большинство сотрудников IT-компаний общаются на нём. Но иногда кандидату необходимо знание местных языков — так, если вы хотите переехать во Францию, шансы на трудоустройство без владения французским минимальны.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Коротко о главном

• Иностранные компании активно используют Java, Python, SQL и нуждаются в программистах, умеющих писать на этих языках.
• IT-специалисты особенно востребованы в Германии, Нидерландах, Канаде и США — странах с наиболее интенсивным ростом технологического сектора.
• Проще всего уехать в Белоруссию, Казахстан, Турцию, Грузию и Китай.
• Работать за границей можно официально или на фрилансе.
• Чтобы получить оффер, следует зарегистрироваться на международных платформах для поиска работы, адаптировать резюме, оформить визу и, при необходимости, обратиться в агентство.

Представьте: пятница, 18:30. Релиз через час. Вы меняете один роут в конфиге — и внезапно половина приложения отлетает. Поздравляем, вы только что познакомились с классической болью фронтендеров.

Проблема кроется в самой природе JavaScript. Строковые пути вроде /users/profile/${id} существуют в коде как обычные строки — без проверок, автокомплита и гарантий корректности. Опечатался в /usres вместо /users — и твоя навигация сломалась, а TypeScript молчит как рыба.

Двадцать лет назад мы кликали по window.location.href, десять лет назад — радовались React Router, а сегодня пора переходить на типизированные решения.

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

Суть проблемы

Проблема очевидна: путь /admin/products размазан по всему коду. TypeScript не знает, что эти строки связаны с определенной директорией, поэтому не проверяет их корректность. Опечатка в product вместо products — и вылетает ошибка 404.

В больших проектах эта проблема критична. Приложение с 200+ путями, где навигация разбросана по сотне компонентов, превращается в минное поле. Один программист меняет структуру URL, а остальные даже не подозревают об этом. Команды используют TypeScript для типобезопасности, но навигация остается уязвимой.

Что такое типизированная навигация?

Типизированная навигация превращает строковые пути в типизированные объекты. Вместо /admin/products/123/edit программист работает с функциями, которые знают структуру приложения и проверяют корректность написания путей на этапе компиляции.

Представьте GPS-навигатор, который знает все адреса в городе. Вы не можете ввести несуществующую улицу — система сразу выдаст ошибку. Так работает типизированная навигация: TypeScript проверяет, что путь существует, параметры переданы правильно, а структура URL соответствует пути.

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

Польза зависит от уровня разработчика:

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

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

Как использовать React Router вместе с TypeScript

Для базовой типизации в React Router v6 сначала определите структуру путей. Создайте интерфейс, который описывает все пути в приложении:

Типизация параметров URL решает проблему с useParams. Вместо any получаете конкретные типы:

Query-параметры типизируются аналогично через useSearchParams. Создайте интерфейс для каждой страницы с query-параметрами и оберните хук.

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

Как внедрить типизированную навигацию в проекты

Централизованная система маршрутов облегчает управление навигацией в больших приложениях. Создайте отдельный файл с конфигурацией всех путей:

Конфигурация избавит от нужды дублировать код при генерации типов. TypeScript автоматически выведет все возможные пути и их параметры из одного объекта.

Современные библиотеки решают проблему из коробки. Например, Tanstack Router предоставляет полностью типизированную систему путей с автогенерацией типов, а Type-route создает типобезопасные пути через API.

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

Выбор инструмента зависит от размера программы. Если у вас небольшое приложение — быстрее написать хук в пару строк. Но если разрабатываете сложный сервис — используйте библиотеки.

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

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

Чеклист для код-ревью поможет не уронить прод:

• Все новые navigate() и используют типизированные версии;
• Параметры путей явно типизированы;
• Нет магических строк в навигации;
• Query-параметры описаны интерфейсами.

Важно: не используйте одновременно строки и типизированные пути — выберите один подход для проекта и не допускайте высокого уровня вложенности в объектах.

Автоматизация упрощает процесс. ESLint правило no-hardcoded-routes запретит использование строк в навигации. Код-генераторы создают типы из OpenAPI схем или конфигурации роутера.

Производительность не страдает — типы исчезают после компиляции. Теряется немного времени на компиляцию TypeScript, но экономия на отладке перекрывает затраты.

Где применять типизированную навигацию

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

E-commerce проекты выигрывают от типизации каталогов и фильтров. Пути вроде /catalog/:category/:subcategory?filters=price,brand содержат много параметров, которые легко сломать при рефакторинге.

Интеграция с Redux и Zustand упрощает синхронизацию состояния с URL. Типизированные селекторы автоматически обновляются при изменении роутов:

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

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

Казалось бы, код — это просто текст. Но каждый запрос к API, каждая компиляция и даже холостой цикл требуют энергии. Например, обучение GPT-4 в 2023 году «съело» столько же электричества, сколько 120 домохозяйств за год. А теперь представьте, что таких моделей тысячи, а серверов — миллионы.

Почему это важно? Во-первых, регуляторы ужесточают требования: в ЕС с 2025 года IT-компании обязаны раскрывать углеродный след своих продуктов. Во-вторых, инвесторы все чаще смотрят на ESG-рейтинги — показатели экологического и ответственного производства. В-третьих, оптимизация кода снижает затраты на инфраструктуру.

Эта статья — не манифест экоактивистов, а руководство для разработчиков, архитекторов и технических директоров компаний (СТО), которые стремятся более эффективные и экологичные проекты.

Углеродный след кода: что скрывается за строчками

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

Откуда берутся выбросы

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

Прямые выбросы — это энергия, которую потребляют серверы при выполнении вашего кода. Например, один средний веб-сервер на AWS EC2 (тип t3.large) в год вырабатывает около 400 кг CO₂ — как небольшой автомобиль, проехавший 2000 км. При этом нагрузка на серверы постоянно растет: с 2020 по 2025 год энергопотребление дата-центров увеличилось на 35%.

Косвенные выбросы часто упускают из виду. Производство серверного оборудования — процесс крайне энергоемкий. Для создания одной только микросхемы памяти DDR5 требуется около 200 кВт⋅ч энергии — столько же, сколько средний холодильник потребляет за год. А после выхода оборудования из строя лишь 20% компонентов перерабатывается должным образом (Global E-Waste Monitor 2024).

Системы охлаждения — еще один скрытый источник выбросов. Современные дата-центры работают 24/7, и даже с использованием жидкостного охлаждения на поддержание температуры уходит до 40% всей потребляемой энергии. В жарких странах, ОАЭ или Сингапуре, этот показатель может достигать 50%.

Яркий пример — крупные языковые модели. Если в 2023 году обучение GPT-4 потребовало ~10 ГВт⋅ч (эквивалент годового потребления 120 домохозяйств), то к 2025 году из-за увеличения размеров моделей этот показатель вырос в 1,5 раза. Один запрос к такому ИИ теперь генерирует около 2 г CO₂ — как если бы вы проехали 10 метров на бензиновом автомобиле.

Но проблема не только в ИИ. Обычное веб-приложение с посещаемостью 100 000 пользователей в месяц может производить до 1 тонны CO₂ в год — и это без учета мобильных клиентов и API. При этом 30% этой нагрузки приходится на неоптимизированный фронтенд: тяжелые изображения, избыточные JavaScript-библиотеки и частые запросы к серверу.

Ситуацию усугубляет географический фактор. Дата-центр в Норвегии, где 98% энергии поступает от ГЭС, будет «чище», чем такой же центр в Польше, где угольные электростанции дают 70% энергии. Разница в углеродном следе может быть 20-кратной для идентичных операций.

При этом стандарты измерения все еще остаются разрозненными. PUE (Power Usage Effectiveness), который используют Google и Microsoft, учитывает только эффективность инфраструктуры, но не источник энергии. Новый стандарт CUE (Carbon Usage Effectiveness), разработанный в 2024 году, уже включает эти данные, но его поддерживают менее 30% провайдеров.

Где код тратит энергию впустую

Некоторые части систем особенно вредны для экологии. Главные «пожиратели» ресурсов:

• Неоптимизированные алгоритмы. Сортировка пузырьком (O(n²)) на большом массиве данных может потреблять в 100 раз больше энергии, чем быстрая сортировка (O(n log n)).
• Микросервисный хаос. Архитектура из сотен микросервисов увеличивает нагрузку на сеть. Каждый вызов API между сервисами — это дополнительные 0,5–1 Вт⋅ч.
• Облачные провайдеры. Не все одинаково зеленые. AWS и Google используют 60–70% ВИЭ (возобновляемых источников энергии), но в Азии и Африке их дата-центры часто работают на угле.

Как измерить углеродный след

В 2025 году появились инструменты, которые помогают оценить влияние кода:

• Cloud Carbon Footprint — анализирует выбросы AWS, GCP и Azure.
• Scaphandre — мониторит энергопотребление серверов в реальном времени.
• Greenframe.io — симулирует нагрузку на веб-приложение и считает CO₂.

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

Европейский союз уже ввел санкции против пяти крупных SaaS-компаний за превышение углеродных квот, а Amazon Web Services выплатила 2,7 млн евро штрафа за неоптимизированные алгоритмы в своих сервисах.

Как изменились подходы к разработке

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

Экологичный DevOps — новая реальность

Современные системы автоматического масштабирования стали умнее. Kubernetes Horizontal Pod Autoscaler теперь учитывает не только нагрузку на CPU, но и текущий углеродный след дата-центра. Если в регионе пиковое потребление энергии и работают угольные электростанции, система сознательно ограничивает масштабирование.

Технология, разработанная Google в партнерстве с WattTime, уже снижает выбросы CO₂ на 27-33% по сравнению с традиционным подходом.

CI/CD-цепочки тоже стали «зеленее». Вместо запуска полного набора тестов при каждом коммите, современные системы определяют, какие именно модули затронуты изменениями.

GitHub Actions представил Carbon-Aware Runner, который планирует выполнение задач на время максимальной доступности возобновляемой энергии в регионе. По данным Microsoft, это сокращает углеродный след тестирования на 40%.

Языки программирования: война за эффективность

Rust продолжает набирать популярность не только из-за безопасности, но и благодаря энергоэффективности. Тесты Benchmarks Game показывают, что один и тот же алгоритм обработки данных на Rust потребляет на 38-42% меньше энергии, чем на Python. В 2025 году Rust вошел в топ-5 языков для enterprise-решений, вытеснив Java в 17% крупных проектов.

Но настоящим открытием стал Zig — язык, который сочетает производительность C с простотой синтаксиса. Его компилятор потребляет в 3 раза меньше ресурсов, чем LLVM-бэкенд Rust, что делает его идеальным выбором для встраиваемых систем.

ИИ на грани: когда меньше значит лучше

TinyML-революция набирает обороты. Современные нейросети для микроконтроллеров занимают менее 256 КБ памяти, но справляются с задачами, которые раньше требовали облачных вычислений.

Например, новые датчики Nest анализируют звук прямо на устройстве, определяя не только дым, но и тип возгорания. Это экономит до 150 МБ трафика в месяц на одно устройство.

На фронте больших языковых моделей тоже произошли изменения. Meta* выпустила LLaMA-3 Nano — модель с 500 млн параметров, которая работает на смартфоне и по качеству ответов не уступает GPT-3.5. Ее углеродный след при обучении в 1200 раз меньше, чем у GPT-4.

(*Компания запрещена в РФ)

Новые правила игры: регуляторы и бизнес

С января 2025 года в Евросоюзе действует Углеродный налог на цифровые продукты (Digital Carbon Border Tax). Теперь любое ПО, продающееся в ЕС, должно иметь сертификат углеродной эффективности.

Для крупных enterprise-решений максимально допустимый углеродный след составляет 500 г CO₂ на 1000 пользователей в месяц. Нарушители платят 7% от оборота продукта в регионе.

Венчурные фонды радикально изменили подход к инвестициям. Согласно отчету PwC, 43% фондов требуют ESG-отчетность перед заключением сделки, а 28% вообще не рассматривают стартапы без «зеленой» стратегии. В Кремниевой долине появился первый акселератор Carbon Neutral Startups, который дает бонусы в $50 000 проектам с нулевым углеродным следом.

Корпорации тоже не остались в стороне. Microsoft ввела внутренний углеродный налог — теперь каждое подразделение платит $100 за каждую тонну CO₂, связанную с его продуктами. Эти деньги идут на развитие возобновляемой энергетики.

Но самое интересное происходит на рынке труда. Разработчики с навыками «зеленого» программирования получают на 15-20% больше предложений. Появилась появилась новая категория навыков — «Устойчивая разработка ПО», а спрос на таких специалистов вырос на 300% за последний год.

Как писать «зеленый» код

Каждая лишняя операция в коде — это не только миллисекунды процессорного времени, но и реальные граммы CO₂. В 2025 году энергоэффективность кода перестала быть теоретической концепцией и превратилась в конкретный навык, который влияет на карьеру разработчика. Рассмотрим три ключевых направления оптимизации.

Оптимизация запросов к базе данных

Типичный пример — использование SELECT * вместо явного перечисления полей. Когда приложение запрашивает все поля таблицы users (включая редко используемые avatar_blob или metadata_json), сервер БД тратит дополнительные ресурсы на чтение и передачу этих данных. В крупных системах с миллионами запросов в день это приводит к значительному перерасходу вычислительных ресурсов.

Современные ORM типа Prisma и Drizzle добавили автоматическую оптимизацию запросов. Теперь при использовании select() они анализируют, какие поля действительно нужны на клиенте, и генерируют оптимальный SQL. В тестах это снижает нагрузку на БД на 12-18%.

Работа с циклами и алгоритмами

Классическая ошибка — продолжать перебор массива после нахождения нужного элемента. В 2025 году статический анализатор кода в WebStorm и VS Code автоматически предупреждает о таких ситуациях. Особенно критично это для мобильных приложений: лишние итерации цикла на слабых устройствах увеличивают энергопотребление на 5-7%.

Новые версии JavaScript и TypeScript ввели оптимизированные методы для массивов. Например, array.findLast() работает в 1,5 раза эффективнее ручной реализации с циклом. Для сложных алгоритмов появились «зеленые» библиотеки вроде EcoCollections для Java, которые минимизируют энергопотребление при работе с структурами данных.

Сжатие и передача данных

Формат Brotli стал новым стандартом для API: он обеспечивает лучшее сжатие, чем gzip, особенно для JSON-ответов. Компания Cloudflare провела эксперимент: после перехода на новую версию Brotli нагрузка на их серверы снизилась на 18%, что эквивалентно годовому потреблению энергии 2000 домохозяйств.

Но сжатие — не панацея. Грамотное проектирование API может дать больший эффект. GraphQL-подход, где клиент запрашивает только нужные данные, в среднем почти вдвое уменьшает объем передаваемой информации по сравнению с REST. А технология Server-Sent Events (SSE) для реального времени потребляет в 3 раза меньше ресурсов, чем WebSockets, когда не нужна двусторонняя связь.

Современные фреймворки начали учитывать энергоэффективность. Next.js 15 представил «зеленый» режим компиляции, который оптимизирует сборку под минимальное энергопотребление. В тестах это дало 8% экономии на процессоре при работе приложения. А Deno 2.0 автоматически кэширует зависимости на уровне ОС, сокращая число повторных загрузок.

Эти изменения кажутся мелкими, но в масштабах индустрии они имеют огромное значение. Если бы все репозитории на платформе применили базовые оптимизации, глобальное энергопотребление дата-центров сократилось бы на несколько процентов. Для отрасли, которая потребляет 700 ТВт⋅ч в год, это десятки миллионов долларов и тысячи тонн CO₂.

Выбор технологий

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

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

Rust и Go продолжают доминировать в высоконагруженных системах. Тесты показывают, что веб-сервер на Rust потребляет на 35-40% меньше энергии при одинаковой нагрузке по сравнению с Node.js. Особенно заметна разница в облачных средах, где каждый ватт на счету.

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

Python по-прежнему хорош для прототипирования, но в продакшене его лучше заменять на компилируемые языки. PyPy 8.0 сократил энергопотребление интерпретатора на 25%, но даже с этими улучшениями Python проигрывает Rust в 3-4 раза по эффективности.

Базы данных: от малого к большему

SQLite — идеальный выбор для небольших проектов и edge-устройств. Его новая версия 3.45 добавила режим «энергосбережения», который снижает потребление на 15% при фоновых операциях.

PostgreSQL 17 сделал большой шаг в энергоэффективности. Функция автоматического партиционирования теперь учитывает не только производительность, но и энергопотребление. В тестах это дало 20% экономии на крупных аналитических запросах.

Для высоконагруженных систем появилась альтернатива — ScyllaDB 5.0. Эта Cassandra-совместимая СУБД потребляет втрое раза меньше энергии при аналогичной нагрузке, благодаря полному переписыванию на Rust.

Кейсы: что работает, а что нет

Российские компании тоже внедряют экологичные IT-решения. МТС разработала мобильное приложение, где пользователи получают бонусы за раздельный сбор мусора — их можно обменять на подписки или скидки. За первый год проект привлек 500 тысяч участников и сократил количество непереработанных отходов в регионах присутствия.

НИУ ВШЭ, совместно с Росприроднадзором, автоматизировал сбор экологической отчетности с помощью ИИ. Нейросеть анализирует данные с датчиков и заполняет формы вместо специалистов. Это сократило время обработки с 100 до 10 часов в месяц и уменьшило количество ошибок.

Некоторые архитектурные решения приносят больше вреда, чем пользы. Один московский стартап без необходимости разбил монолитную систему на 50 микросервисов — в результате затраты на инфраструктуру выросли в 3 раза, а углеродный след увеличился на 180%.

Проблемы возникают и на уровне зависимостей. История с left-pad повторилась в 2024 году, когда один npm-пакет потянул за собой 80 МБ ненужных библиотек. Теперь крупные компании проверяют каждую зависимость через Bundlephobia и устанавливают лимит на размер node_modules.

Что нас ждет

В 2025 году отрасль стоит на пороге радикальных изменений, которые перевернут наши представления о «зеленом» программировании.

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

Google уже тестирует эту технологию в Северной Европе: когда в Норвегии дует сильный ветер и ветряные электростанции работают на пике, система переносит вычисления именно туда. По предварительным оценкам, это снижает углеродный след на 18-22% по сравнению со статичным распределением.

Но настоящий прорыв ожидается в сегменте квантовых вычислений. Хотя современные квантовые компьютеры потребляют колоссальное количество энергии (система IBM Quantum System One требует около 25 кВт⋅ч для работы одного кубита), их потенциал для оптимизации классических алгоритмов огромен.

В 2024 году исследователи из ЦЕРНа предложили квантовый алгоритм, который сокращает время сложных расчетов в 1000 раз при той же точности. Когда такие решения станут массовыми (прогноз — 2028-2030 годы), энергопотребление дата-центров может сократиться на 30-40%.

Государственное регулирование становится строже. В 2025 году в силу вступает EU Digital Product Passport — требование указывать углеродный след для всего ПО, продающегося в Европе.

Компании, которые не смогут предоставить эти данные, столкнутся с дополнительными налогами до 7% от оборота. В ответ на это крупнейшие IT-корпорации создали Carbon Neutral Software Alliance — консорциум по разработке единых стандартов измерения.

Не отстает и аппаратная часть. Производители чипов переходят на новые техпроцессы: TSMC анонсировала 2-нм процесс, который на 30% энергоэффективнее предыдущего поколения. А стартапы вроде британской ZeroPoint Technologies разрабатывают память с нулевым энергопотреблением в режиме ожидания — технология может сократить энергопотребление серверов на 15%.

Но главный тренд — децентрализация вычислений. Edge-устройства (от смартфонов до промышленных датчиков) становятся мощнее и берут на себя часть нагрузки. Например, новый алгоритм Apple для обработки фото на iPhone 16 выполняет 90% операций локально, а не в облаке. По оценкам компании, это экономит сотни тысяч тонн CO₂ в год только для пользователей в США.

Однако остаются и проблемы. Бум генеративного ИИ привел к взрывному росту энергопотребления: одна тренировка модели Gemini Ultra потребляет столько же энергии, сколько небольшой город за месяц. OpenAI и Anthropic уже работают над более эффективными архитектурами, но прорыва пока не случилось.

В ближайшие 3-5 лет нас ждет:

• массовый переход на углеродно-нейтральные дата-центры — к 2027 году их доля превысит 60%;
• внедрение AI-оптимизаторов кода, которые автоматически сокращают энергопотребление;
• появление «зеленых» рейтингов для приложений — аналог энергоэффективности для бытовой техники.

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

Технологии будущего уже здесь. Вопрос в том, насколько быстро мы сможем их адаптировать. Как сказал Дженсен Хуанг из NVIDIA на последней конференции GTC:

«Следующее десятилетие определит, станет ли IT частью климатического решения или останется проблемой. Выбор за нами».

Итоги

Экологичность в IT — не благотворительность и не актуальная повестка, а реальная экономия. Плюс работа на перспективу. Оптимизация кода снижает счета за облака и повышает производительность.

С чего начать? Начните с малого:

1. Запустите аудит через Cloud Carbon Footprint.
2. Уберите «мусор» из зависимостей.
3. Выберите хостинг с ВИЭ.

Как говорил Дональд Кнут, автор книги «Искусство программирования»:

«Преждевременная оптимизация — корень всех зол. Но и запоздалая — тоже».

В 2025 году это актуально как никогда.

Давайте представим ситуацию, что нужно запустить код, минуя все эти стадии. Прям в production-среде. На первый взгляд — бред! Но если подумать, то на самом деле, не такая уж редкость. Например, некоторые системы предоставляют своим пользователям возможность расширять функциональность за счет прикладных скриптов. Наш любимый CI/CD-конвейер зачастую построен на пользовательских скриптах.

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

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

Ненадёжный код

Для начала определимся, что же считать ненадёжным кодом? На самом деле ответ зависит от решаемой задачи, правил и процессов, принятых в компании:

• Код, который не прошел CI, review и т.п.
• Код из ненадёжного или неизвестного источника.
• Закрытый (проприетарный) код.
• Код, содержащий уязвимости.
• Код, использующий запрещенные функции.
• Любой код, который написал коллега:)

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

Уровни изоляции кода

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

Уровень 1: тот же процесс

Запуск внешнего кода в адресном пространстве процесса приложения.

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

Примером может служить использование интерпретаторов скриптов (Rhino, IronPython, Jython и т.п.), визуальных языков программирования (workflow-движков) или подключение модулей расширения (плагинов).

Способов защиты на этом уровне не так много. Пожалуй, самым эффективным выступает (self-sandboxing), при котором приложение делает самозапрет на доступ к некоторым ресурсам системы. Например, сразу после инициализации — самозапрет на доступ к файловой системе.

Дополнительно запускаемый код можно подвергать строгому (синтаксическому) анализу, запрещая использование определенных функций, модулей, пакетов и т.п. Некоторые интерпретаторы имеют точки расширения, которые позволяют контролировать процесс исполнения. Если такой возможности нет, можно воспользоваться одной из техник самоизоляции — фильтрацией системных вызовов.

Что же касается плагинов, то они призваны расширять возможности приложения, поэтому их использование изначально не предполагает сильной изоляции. Здесь можно предложить усилить контроль взаимодействия на уровне контракта (API). В идеале — если плагины будут публиковаться в некоторый центральный репозиторий, которому вы доверяете и который может производить дополнительные проверки и тестирование до этапа запуска кода плагина.

Уровень 2: отдельный процесс

Запуск внешнего кода на той же машине, но в отдельном процессе ОС.

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

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

Уровень 3: отдельная машина

Запуск внешнего кода на отдельной машине — песочнице.

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

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

Использование песочницы

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

Пересоздание или переиспользование песочницы

Песочницу требуется пересоздавать перед исполнением каждой задачи, если требуется особенное окружение (например, определенная версия ОС, пакетов или ресурсов) или идентичность этого окружения (для стабильности получаемых результатов). Схожие вопросы возникают, например, при интеграционном тестировании: каждому тесту нужны свои предустановки.

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

Основным преимуществом пересоздания песочницы выступает стабильность получаемых результатов. К недостаткам относится медленный запуск и перерасход ресурсов. На пересоздание песочницы уходят десятки секунд или даже минут, следовательно, большая часть ресурсов будет тратиться именно на это. Существует множество техник ускорения пересоздания, благодаря которым можно сократить время запуска. Прежде всего, сюда можно отнести backup/restore (snapshot песочницы, базы данных и т.п.). Также если поток задач небольшой и ресурсы позволяют, можно попробовать организовать пул песочниц и создавать их заранее.

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

Последовательное или параллельное исполнение

Теперь осталось ответить на вопрос, как именно можно или нужно исполнять задачи: последовательно или параллельно. Последовательное исполнение требуется в следующих случаях:

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

Например, шаги установки и настройки ПО; шаги CI/CD-конвейера; рендеринг изображения на GPU; интенсивные вычисления. Все эти задачи, скорее всего, придётся исполнять последовательно.

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

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

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

Управление песочницами

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

Оркестрация

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

Основное преимущество оркестрации в контексте решаемой проблемы — её простота и ясность. Код легко читается и сосредоточен в одном месте. Однако у этого решения есть и недостатки. Рассмотрим их в порядке от простого к сложному.

• Синхронное взаимодействие. Так или иначе, для результата приложение вынуждено ожидать окончания исполнения задачи. Для продуктивного использования ресурсов приходится прибегать к техникам асинхронного программирования: пока задача исполняется, приложение будет занято полезной работой. Это малозаметный недостаток в языках со встроенной поддержкой концепции асинхронного программирования. Для упрощения работы с асинхронным кодом в Java я создал небольшую вспомогательную библиотеку asynchronizer, снабдив её подробной документацией.

• Отслеживание доступности песочниц. Поскольку хотелось бы, чтобы количество песочниц менялось в зависимости от нагрузки на систему, придётся отслеживать их доступность. Это прямая обязанность оператора песочниц, которую можно выделить в отдельный discovery-сервис (например, на базе Netflix Eureka), либо реализовать как часть приложения с использованием инфраструктурных механизмов (например, Kubernetes API). Важно отметить, что оператор песочниц не имеет отношения к бизнес-логике приложения.

• Отслеживание загруженности песочниц. Оркестратор исполнения должен выбрать подходящую стратегию балансировки, основанную на состоянии песочниц, предоставляемых оператором. На практике наилучшую эффективность демонстрирует алгоритм Least connections, с помощью которого можно выбирать наименее загруженные песочницы. Для этого достаточно вести учёт количества задач, исполняемых каждой песочницей. Конечно, это не серебряная пуля, а лишь частное наблюдение, поэтому в идеале нужно предусмотреть несколько стратегий балансировки и выбрать наилучшую по результатам нагрузочного тестирования.

• Неопределённость результата, если нет ответа от песочницы. Песочница может быть недоступна по различным причинам, включая не только проблемы с сетью, но и падения песочницы из-за ненадёжного кода. К сожалению, в общем случае эта проблема не имеет решения, так как делать повторные запуски (retries) может быть опасно. Всё, что остаётся, это использовать таймауты и откладывать неуспешную задачу на потом.

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

Для отслеживания нагрузки на песочницы экземпляр приложения ориентируется на количество задач в каждой из доступных песочниц. Предположим, что было принято решение увеличить количество экземпляров приложения. Этот экземпляр исполняет 5 задач в двух песочницах (3 процесса в одной и 2 в другой). Известно, что каждая песочница может вынести максимум 4 параллельных задачи.

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

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

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

• Для контроля количества исполняемых задач в песочнице использовать распределённый счётчик (например, на базе Redis). Проблема в том, что распределённый счётчик имеет латентность и на момент запуска задач может выдать устаревшее значение. Кроме того, в системе появляется еще один инфраструктурный компонент, который не несёт бизнес-пользы.

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

Кстати, после доклада на TechLeadConf 2025 мне задали интересный вопрос: Можно ли при балансировке нагрузки на песочницы учитывать не только количество исполняемых задач, но и процент загрузки CPU, памяти и прочих ресурсов? Если у кого-то возник такой же вопрос, то отвечу, что это не имеет смысла, поскольку ситуация в песочнице может поменяться мгновенно. Полученный практический опыт и нагрузочное тестирование показали, что простой подсчёт задач работает эффективно.

Самоорганизация

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

Ключевой момент в архитектуре — это появление двух очередей: очередь задач на исполнение (Task Queue) и очередь результата их исполнения (Result Queue). Все поступающие задачи приложение направляет в первую очередь, а результаты — во вторую. Дополнительно появляется роль агента — микросервиса, который исполняется в рамках узла песочницы и координирует исполнение поступающих задач.

Основной недостаток самоорганизации — распределённый процесс обработки задач. Учитывая простоту алгоритма обработки, это не так существенно. Стоит отметить преимущества этой архитектуры.

• Максимальная изоляция ненадёжного кода. Ненадёжный код, как и в случае с оркестрацией, по-прежнему работает в песочнице в рамках отдельного процесса ОС.

• Скорость и стабильность взаимодействия. Никаких проблем с сетью из-за локальности взаимодействия между агентом и песочницей.

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

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

• Простота масштабирования. Приложение и песочницы масштабируются независимо друг от друга без негативных побочных эффектов.

Запуск процесса ОС

К запуску процесса ОС, в рамках которого будет исполняться ненадёжный код, нужно подойти с особой осторожностью. Здесь важно ответить как минимум на три вопроса.

• Как ограничить права доступа к ресурсам. Самое простое решение — запуск процесса от имени пользователя с ограниченными правами (на доступ к ресурсам ОС).

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

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

Рассмотрим варианты ограничения ресурсов процесса ОС.

Ограничение ресурсов процесса

Ресурсы процесса могут быть ограничены на трех уровнях:

• Лимиты узла. Физические ограничения машины, на которой исполняется процесс. В частном случае можно говорить об инфраструктурных лимитах, определённых для Docker/Kubernetes контейнера.

• Лимиты контейнера. Программные лимиты, задаваемые выбранным инструментом контейнеризации (cgroup, Docker, Bubblewrap, ProcessSandbox и т.п.).

• Лимиты процесса. Программные лимиты, задаваемые средствами ОС. На этом уровне можно осуществлять гибкую настройку вариантов запуска и исполнения.

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

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

Например, для использования cgroup или Docker внутри Kubernetes-контейнера нужно эскалировать привилегии контейнера, что в общем случае небезопасно в контексте исполнения ненадёжного кода. Более того, практика показала, что легковесных rootless-средств, предоставляемых ОС, вполне достаточно, чтобы снять большую часть рисков. В частности, Linux API позволяет не только лимитировать CPU и память, но и блокировать доступ к некоторым возможностям самой ОС. Например, можно наложить фильтр, который запретит вызов определённых системных функций.

Проблемы жёсткого лимитирования

Рассмотренные выше способы лимитирования задают жёсткие границы (hard limit), нарушение которых замедляет исполнение процесса, либо приводит к его принудительному завершению. При этом поведение наблюдаемого процесса и системы сильно варьируется в зависимости от того, какой лимит был превышен. Например, превышение по использованию CPU может привести к троттлингу (throttling), приостановке работы или принудительному завершению; превышение по использованию памяти заканчивается принудительным завершением со стороны ОС (OOM Killer) либо самостоятельным падением процесса (с ошибкой Out Of Memory).

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

Такой подход имеет несколько преимуществ.

• Точное определение причин принудительного завершения. Жёсткие лимиты чуть выше мягких, благодаря чему для исполняемого кода создаётся иллюзия отсутствия каких-либо лимитов. Между тем, если лимиты всё-таки нарушаются, процесс всё равно будет завершен (либо со стороны приложения, либо гарантированно со стороны ОС). Но подобный дополнительный контроль со стороны приложения оставляет для него гораздо больше шансов понять причину принудительного завершения наблюдаемого процесса.

• Возможность гибкого лимитирования ресурсов. Приложение (или агент), ответственное за запуск наблюдаемого процесса, может обратиться к средствам ОС (в частности, к Linux API) и гибко настроить параметры запуска и исполнения. Как минимум, жёстко определить лимиты по CPU и памяти; наложить ограничения на объем I/O; создать запрет на вызов некоторых системных функций (например, запрет использования сетевых операций или файловой системы) и т.п.

Такой подход я назвал watchdog и в целях иллюстрации реализовал его в виде .NET-библиотеки ProcessSandbox. Помимо прочего, на странице проекта подробно рассмотрена проблематика контроля и анализа поведения процесса ОС со стороны прикладного кода.

Итоговая схема лимитирования может выглядеть так, как показано на рисунке ниже. Вместо тяжеловесных инструментов контейнеризации используется легковесный rootless-инструмент (watchdog) на базе средств ОС и только.

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

Многоконтейнерные поды

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

Несмотря на всю заманчивость данной идеи, она несёт ряд недостатков.

• Плохая масштабируемость. Соотношение приложение-песочница всегда один к одному. Однако не исключено, что в некоторых случаях это вполне приемлемо.

• Плохая утилизация ресурсов. Сможет ли приложение достаточно нагрузить песочницу, если количество песочниц будет в избытке; и наоборот, нужно ли столько же экземпляров приложения, сколько и песочниц.

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

• Риск нарушить работоспособность приложения. Выход песочницы из строя скорее всего приведет к перезапуску всего пода. Более того, если приложение и песочница обмениваются файлами через общий раздел (shared volume), это может стать уязвимым местом.

Образ для песочницы

Основные моменты, которые следует учесть при создании (Docker) образов песочниц:

• Заменить init-процесс на tini, чтобы не превысить лимит по PIDs.

• Создать непривилегированного пользователя, ограничив ему права на доступ к ресурсам.

• Регулярно сканировать версии образов и пакетов на наличие уязвимостей.

Инфраструктура исполнения

Основные моменты, которые следует учесть при настройке инфраструктуры исполнения:

• Обеспечить быстрый (пере)запуск песочниц. Нужно быть готовым к тому, что песочницы будут падать. Если речь идет о Kubernetes, то улучшить время запуска может подходящая настройка Image Pull Policy. При этом лучше не использовать тег `latest`, а указывать конкретную версию или хэш-код образа, чтобы не тратить время на попытки определения последней версии при каждом запуске.

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

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

Заключение

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

Я постарался показать последовательность шагов по направлению к целевой архитектуре, которая будет отвечать требованиям бизнеса и справляться с ненадёжным кодом. Если вам интересна данная тематика, подписывайтесь на мой Telegram-канал Архитектоника в ИТ (@arch_and_dev). Буду рад поделиться опытом.

Что такое Cangjie

Cangjie — язык общего назначения, разработанный для HarmonyOS Next. Это та самая операционная система, созданная на замену Android после американских санкций.

По словам HUAWEI, язык подходит для разработки «во всех сценариях», включая мобильные приложения, распределённые системы и ИИ-сервисы.

Особенности Cangjie:

• Нативная поддержка ИИ
• Фокус на безопасности
• Поддержка приложений не только на HarmonyOS, но и на Android с iOS

Таким образом, Cangjie позиционируется как альтернатива Java (в экосистеме Android) и Swift (в iOS).

Как развивается экосистема

Язык разрабатывался почти пять лет и впервые был представлен в июне 2023 года. За несколько недель он привлёк свыше 10 000 заявок на участие в тестировании.

Уже в октябре прошлого года Cangjie стал доступен всем разработчикам HarmonyOS, а к июлю 2025 его используют крупные игроки:

• Meituan — пишет на Cangjie приложение для доставки, релиз которого ожидается в III квартале;
• JD.com — использует язык в мобильных решениях для собственной платформы.

Почему это важно

Cangjie — ещё один шаг в сторону технологического суверенитета Китая. Под американскими санкциями HUAWEI активно выстраивает собственную экосистему — от ОС и чипов до языков программирования и облачных сервисов.

Что дальше

С 30 июля исходный код Cangjie будет доступен всем. HUAWEI рассчитывает, что открытие языка ускорит его адаптацию и создаст альтернативу западным технологиям — в первую очередь в Китае, а затем и за его пределами.

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

Больше новостей — в нашем канале Представляешь

Подробности

MCP уже становится стандартом для корпоративных ассистентов и мультиагентных систем: протокол позволяет гибко управлять маршрутами вызовов между моделями и сервисами, снижает хаос в интеграциях и упрощает масштабирование LLM-приложений. Теперь у инженеров появилась возможность изучить MCP на практике: в курсе представлены готовые проекты и живой код на Python, C#, Java, TypeScript и JavaScript, есть пошаговые инструкции по настройке среды, запуску серверов и клиентов, интеграции с пайплайнами CI/CD, а также подробные объяснения архитектуры и рекомендаций по безопасности.

Что есть в учебной программе

Курс разделён на несколько блоков: от основ MCP и настройки окружения до практического создания серверов и клиентов, работы с потоковой передачей данных и построения мультимодальных систем. Также рассматриваются вопросы масштабирования, интеграции с Azure AI и OpenAI, построения защищённых серверов и развертывания LLM-агентов. Особое внимание уделено тому, как MCP помогает организовать работу с контекстом запросов и объединением нескольких моделей, включая сценарии корпоративного применения.

План следующий:

• Уроки 1–2 — введение в протокол, настройка среды, запуск базового MCP-сервера и клиента, интеграция в существующие пайплайны, безопасность.

• Урок 3 (большой модуль) — создание и развертывание рабочего MCP-сервера и клиента: от локальной разработки и тестирования в Visual Studio Code с AI Toolkit до развертывания сервера с SSE и HTTP-стримингом, а также построения клиентов на Python и TypeScript.

• Уроки 4–5 — практическое применение: от отладки и тестирования до масштабирования, мультимодальности и интеграции с Azure AI Foundry, OAuth2 и системами Entra ID.

• Уроки 6–9 — лучшие практики, вклад сообщества, разбор реальных кейсов ранних внедрений, лабораторные работы.

• Урок 10 — практическая лаборатория: создание MCP-сервера с помощью AI Toolkit для VSCode, демонстрация потоковой передачи данных в реальном времени, интеграции с внешними LLM и корпоративными пайплайнами.

Курс будет полезен как тем, кто только начинает изучать работу с языковыми моделями и строит свои первые ассистенты, так и опытным разработчикам, которым нужны структурированные практики и кейсы. Для старта достаточно базового понимания Python, C# или Java, а также представления о модели клиент-сервер и API.

Учебная программа уже доступна в официальном репозитории MCP на GitHub. Там можно найти SDK с открытым исходным кодом, инструкции по работе с AI Toolkit для VSCode, шаблоны проектов и примеры кода, которые можно запускать и адаптировать под свои задачи.

Протокол MCP становится частью экосистемы OpenAI и Azure AI, и умение работать с ним может дать инженерам конкурентное преимущество в новых проектах, связанных с LLM и корпоративными ассистентами. Новые уроки и примеры будут постепенно добавляться в репозиторий, поэтому курс обещает оставаться актуальным в быстро меняющемся мире ИИ.

Полезные ссылки

• Документация MCP — подробные учебные пособия и руководства пользователя
• Спецификация MCP — архитектура протокола и технические рекомендации
• Репозиторий MCP на GitHub — SDK с открытым исходным кодом, инструменты и примеры кода

Может плодить новые эндпоинты или заставлять мобилку делать несколько запросов вместо одного? Каждый запрос жрёт трафик и батарею!

Элегантное решение — архитектура Backend for Frontend (BFF). Это прослойка между клиентскими приложениями и основным API, которая адаптирует данные под потребности конкретного клиента.

Основная идея backend for frontend

Один API не может эффективно обслуживать разные типы клиентов. Сайт, приложение для iOS, Android, умные часы — у каждого свои потребности в данных, ограничения по производительности и особенности интерфейса.

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

Следуя архитектуре BFF, вы можете создать логику для каждого типа клиента и не засорять основной API. Вместо одного эндпоинта /api/products, который пытается угодить всем, появляются слои:

• один — оптимизирует данные для веба,
• второй — для мобильных устройств,
• третий — для умных часов.

Обычно данные приходят в неудобном виде: несколько связанных сущностей нужно запрашивать отдельно и склеивать на клиенте. BFF берёт эту работу на себя.

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

Каждый клиент получает данные в том виде, в котором может их сразу отобразить. Вместо загрузки 50 полей, из которых используется 5, BFF отдаёт только нужные данные.

«Можете добавить поле user_avatar в ответ?»

— «Это сломает мобилку».

«Тогда сделайте отдельный эндпоинт».

— «У нас нет времени».

С BFF этого диалога нет. Фронтенд-команда получает свой API и крутит его, как хочет.

Мобильное приложение съедает 10к запросов в секунду? Пишите BFF на Go. Веб-версию делает стажёр, который знает только JavaScript? Ставьте Node.js. Никто не заставляет выбирать одну технологию на все случаи жизни.

Как работает backend for frontend (BFF)

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

Архитектура взаимодействия

Классическая схема выглядит так: мобильное приложение обращается к своему BFF, веб-приложение — к своему, умные часы — к третьему. Каждый BFF знает особенности своего клиента и общается с основными сервисами на их «языке».

Когда мобильное приложение запрашивает список заказов, его BFF делает несколько вызовов к микросервисам:

• берёт базовую информацию о заказах,
• подтягивает данные о товарах,
• получает статусы доставки.

Затем склеивает всё в один ответ, отбрасывая ненужные поля и добавляя вычисляемые значения.

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

Обработка и агрегация данных

BFF не просто перекладывает данные из одного формата в другой. Он выполняет бизнес-логику.

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

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

Независимость и масштабирование

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

4 ключевых преимущества BFF

Оптимизация передачи данных

Самое очевидное преимущество — экономия трафика. Приложение не тащит 2 МБ JSON с полным каталогом товаров на мобильное устройство? BFF отдаёт только нужные поля.

Количество запросов тоже сокращается. Например, чтобы показать профиль пользователя, фронтенд делает 5 запросов:

• за основными данными,
• аватаром,
• списком друзей,
• последними постами,
• настройками приватности.

BFF объединяет всё в один запрос, получая данные параллельно от разных сервисов.

Упрощение фронтенда

Половина фронтенд-кода уходит на трансформацию ответов API:

• парсинг дат,
• группировку массивов,
• вычисление производных значений.

BFF может взять эту работу на себя.

Безопасность через изоляцию

BFF создаёт барьер между клиентами и сервисами. Мобильное приложение никогда напрямую не обращается к БД пользователей или платёжке — только через свой BFF.

Можно настроить разные уровни доступа:

• мобильный BFF видит только публичные данные,
• API для партнёров работает в песочнице.

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

Независимое масштабирование

Когда приложение попадает в топ App Store, нагрузка взлетает в разы. Но страдает только мобильный BFF — веб-версия продолжает работать стабильно. Можно быстро поднять дополнительные серверы только для мобильного трафика.

Появляется возможность экспериментировать с технологиями без риска. Хотите попробовать GraphQL для веб-версии? Внедряйте в один BFF. Тестируете новую базу данных? Подключайте к экспериментальной прослойке, не трогая продакшн.

Когда стоит использовать backend for frontend

BFF — инструмент для конкретных ситуаций.

Когда интерфейсы кардинально отличаются

Если ловите себя на мысли: «этот эндпоинт нужен только для веба» или «мобилка использует 10% полей из ответа», — пора задуматься о BFF.

Красный флаг — когда фронтенд-разработчики начинают писать костыли для обработки «неудобных» данных. Если половина JavaScript-кода занимается парсингом и трансформацией ответов API, что-то пошло не так.

Когда интерфейсы эволюционируют быстрее джунов

Стартапы и продукты в активной фазе развития меняют интерфейсы каждую неделю.

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

Без BFF это означает изменения в основном API, которые могут сломать другие клиенты. С BFF — правки только в одном месте.

Когда команды работают независимо

Если у вас несколько фронтенд-команд, которые постоянно конфликтуют из-за API, BFF даст им свободу.

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

BFF распределяет ответственность: каждая команда поддерживает свой слой.

Когда НЕ стоит использовать BFF

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

3 типичные ошибки при внедрении BFF

Дублирование логики

Начинается незаметно: мобильный и веб BFF нуждаются в одинаковой валидации пользователей. Разработчик копирует функцию из одного проекта в другой. Через полгода одинаковый код валидации живёт в четырёх местах, и каждое изменение превращается в квест.

Хуже, когда дублируется бизнес-логика. Расчёт скидок, обработка промокодов, правила доступа — это должно жить в основных сервисах, а не размазываться по BFF-слоям.

Избыточная сложность вместо упрощения

Пример: команда создаёт «универсальный BFF-фреймворк» с конфигурацией через YAML, поддержкой плагинов и собственным DSL. В итоге простое добавление поля в ответ требует изучения документации на 50 страниц.

Другая крайность — микро-BFF для каждой мелочи. Отдельный слой для авторизации, отдельный для форматирования дат, отдельный для валидации.

Неправильная гранулярность

Один BFF на все мобильные платформы может быть слишком общим: iOS и Android имеют разные особенности интерфейса. Но отдельный BFF для каждой версии приложения — явный перебор.

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

Практические примеры использования BFF

Netflix

Компания сделала разные API для веб-версии, мобильных приложений, Smart TV и игровых консолей. Каждый BFF оптимизирован под особенности устройства, например, TV-версия предзагружает больше контента из-за медленной навигации пультом.

Spotify

Используют BFF для разных клиентов: веб-плеер, мобильные приложения, десктопное приложение. Мобильный BFF агрессивно кеширует данные для офлайн-режима, веб-версия работает в реальном времени.

SoundCloud

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

Заключение

Страдают все, когда один API пытается обслуживать веб-версию, мобилки и что-то ещё. Фронтенд получает неудобные данные, бэкенд обрастает костылями, пользователи — медленными приложениями.

Backend for Frontend создаёт слой между клиентами и основными сервисами. Каждый тип устройства получает API, заточенный под его потребности.

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

Ты уже программист, если читаешь это! Больше про кодинг — здесь.

В статье рассмотрим:

- Установку локально и в облаке;

- Интеграцию с Python, Node.js и PHP;

- Примеры автоматизаций;

- Интеграцию с AI Mistral.

Установка n8n

Локальная установка

Нам потребуется Docker, проверьте установку:

Шаги установки:

1. Создайте том данных:

2. Запустите контейнер:

После запуска откройте: `http://localhost:5678`

Установка на удаленном сервере

Развертывание мы произведем в облаке Amvera, так как в нем n8n предоставляется как преднастроенный сервис с бесплатным доменом (он нам нужен), настроенными переменными и проксированием до заблокированных в РФ LLM (OpenAI, Gemini, Claude и др.).

1. Регистрируемся на Amvera;

2. Выбираем n8n в плитке на главной странице;

3. Вводим название для проекта и выбираем тариф.

Готово, через 30 секунд запустится n8n с выделенным доменом и настроенными основными переменными.

Настройка n8n

Первоначальная настройка

1. Откройте n8n (локально: `localhost:5678`, в облаке: ваш домен)

2. Заполните данные администратора:

• Email

• Имя/Фамилия

• Пароль

3. По желанию вы можете получить бесплатный лицензионный ключ:

• Введите email → "Send me a free license key"

• Активируйте в разделе Settings → Usage

Настройка для HTTP

1. Создайте новый workflow → Start from scratc

2. Добавьте триггер: Webhook - On webhook call

3. Настройте:

• HTTP Method: POST

• Path: `/n8n` (пример)

• Respond Mode: Using 'Respond to Webhook' node

4. Добавьте обработчик: Core → Respond to Webhook

5. Настройте ответ:

Примеры использования

Пример на Python

В примере на Python мы сделаем калькулятор. Суть: отправляем выражение через POST, n8n делает вычисление, возвращаем результат.

Workflow:

1. Добавьте Core → Code node между Webhook и Respons:

Клиент (Python):

Запустим код и посмотрим результат:

Пример на PHP

В примере на PHP мы сделаем валидацию данных. Суть: отправляем данные через POST, n8n проверяет данные, возвращает результат.

Workflow (Code node):

Клиент (PHP):

Можем зайти на нашу страницу, все работает нормально:

Пример на Node.js

Примером на node.js будет фильтр запрещенных слов. Суть: отправляем текст, n8n проверяет на наличие плохих слов, возвращает результат.

Workflow (Code node):

Клиент (Node.js):

Перед запуском установим библиотеку командой `npm install axios`

Интеграция n8n с Mistral AI

Мы интегрируем нейросеть Mistral в телеграмм-бота на C# с помощью n8n. Перед тем как начать, нам нужно получить токен.

1. Зарегистрируйтесь на Mistral

2. Создайте агента Сreate an agent

3. Перейдите в раздел API Keys

4. Создайте и скопируйте API-ключ (звездочки наложены):

Теперь нужно создать credentials для работы с созданной моделью. Для этого в правом верхнем углу нажмите Create credentials. В списке найдите Mistral Cloud API. В открывшемся окне вставьте скопированный ключ и сохраните.

Осталось настроить workflow.

1. Добавляем Webhook:

• Method: POST

• PATH: n8n

• Respond: Using 'Respond to Webhook' Node

2. Добавляем AI Agent:

• Source for Prompt: Define below

• Prompt: `{{ $json.body.text }}`

3. Подключаем Chat Model к созданному агенту:

• Credential to connect with: Mistral Cloud API

• Model: mistral-large-2411

4. Добавляем Respond to Webhook

Вот так выглядит готовый workflow:

Можем приступить к созданию бота. Для начала введите эти команды по очередности:

Переходим в папку с кодом и редактируем файл `Program.cs`:

Запустите бота с помощью команды `dotnet run`.

Автоматизируем с помощью n8n

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

Для работы с Telegram Node понадобиться создать credentials Telegram API. Туда вставляем токен бота, полученный в @BotFater. Сохраняем и переходим к настройке workflow.

Создаем новый workflow.

1. Добавляем On form submission. В качестве примера я создам самую простую форму:

Перейдите по ссылке в Producrion URL чтобы заполнить форму.

2. Добавляем Telegram Node:

• Credential to connect with: Telegram account

• Resource: Message

• Operation: Send message

• Chat ID: вставьте свой telegram id

Text:

Готово! При новых заявках бот будет присылать уведомления.

Деплой бота в Amvera Cloud

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

Строго говоря, этот файл проще создать в конфигураторе в интерфейсе.

2. Структура проекта будет такой:

tg-bot/

├── Program.cs

├── tg-bot.csproj

├── amvera.yml

├── bin/

└── obj/

Идем В Amvera Cloud и создаем приложение Приложения — Создать приложение. Вводим название и выбираем тариф.

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

Нажимаем Завершить и ждем когда приложение будет запущено.

Заключение

n8n — мощный инструмент для создания интеграций и автоматизаций. Надеюсь, статья была вам полезна и буду рад обсудить в комментариях любые вопросы!

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

Шутки шутками, но тема действительно важная. Я прошел путь от классических монолитных приложений до сложных микросервисных, проектировал системы, которые работают под большой нагрузкой, и пришел к выводу, что однозначного ответа здесь не существует. И вообще, «монолит или микросервисы» — это неправильная постановка вопроса.

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

Микросервисы: зачем они нужны и в чем их плюсы

Архитектура приложений: немного базы

Под капотом современных приложений обычно скрываются три основные части:

• множество библиотек и зависимостей;
• единый store, в котором живут состояние и данные;
• компоненты, которые нужно собрать, чтобы сделать из них приложение.

Собрать это все можно по-разному. Можно сложить в монолит, а можно попробовать модульный подход.

Монолитное приложение — старое доброе приложение, которое, как правило, создают один или несколько разработчиков, потом его дорабатывает армия джунов, синьоров и всех, кто оказался рядом. Каждый «чуть-чуть поправил», и вот уже никто не понимает, почему оно работает, — но трогать страшно. Монолиты пишут и сейчас — все зависит от бизнеса. Если нужно приложение для небольшого проекта, микросервисы могут и не понадобиться.

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

Масштабировать можно и монолиты, но у них всегда остается какая-то единая точка отказа — например, база данных. Особенно если это реляционная СУБД, завязанная на Oracle или PostgreSQL. Когда база достигает сотен гигабайт или даже терабайт, масштабировать такую штуку становится дорого, больно и ненадежно.

Микросервисы — панацея? Не совсем

Тренд на микросервисный подход появился в начале 2010-х годов, вместе с проникновением интернета в широкие слои населения. Первый iPhone вышел в 2007 году, люди стали гораздо ближе к интернету, к данным, к информации. Бизнес захотел дотянуться до этой аудитории, и тогда началась диджитализация, сложность систем стала повышаться. Особенно остро это почувствовали крупные организации вроде банков: функциональность увеличивалась, и монолит начал «трещать» не только технически по инфраструктуре, но и по возможностям команд разработки, которые с ним работали.

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

Распространение DevOps-культуры и инструменты оркестрации

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

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

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

Проектируем микросервисы без боли: от стандартов до DDD

Стандартизация — наше все

Если каждый микросервис пишет логи в своем формате и использует свои библиотеки, получается зоопарк. Нужно, чтобы были выровнены стек и CI/CD pipeline, существовали одинаковые библиотеки логирования и формат.Микросервисы дают свободу писать на разных языках, но с ней приходит и ответственность: под каждый язык придется придумывать и поддерживать разные инструменты. А это приведет к еще большему увеличению сложности. Так что с языком тоже лучше соблюдать стандартизацию: если пишете на Java, то и решать все проблемы стоит с помощью этого языка.

При этом иногда другой язык вполне оправдан. Например, просто потому, что Java не может работать с такой высокой скоростью, какая нужна. В некоторых случаях даже на Java приходится писать особым образом, либо можно использовать C++, Go или Rust. Но это скорее исключение из правила.

Инженеры — натуры увлекающиеся и любят паттерн CV driven development, когда хочется новую технологию потрогать и внедрить у себя. А потом похвастаться этим на каком-нибудь ивенте по принципу «just because I can» («просто потому что могу»). При этом может оказаться, что бизнесу технология особо и не была нужна. Чтобы избегать таких ситуаций, необходим технологический радар — список того, что можно использовать в компании, а что нет. И исключения из такого радара должны приниматься и допускаться очень взвешенно.

DDD: как правильно нарезать сервисы

Одна из опасностей при проектировании микросервисов — скатиться в очень мелкую гранулярность, когда логика нарезается чуть ли не по отдельной функции на микросервис (на отдельный deployment unit). Это может привести к такой сложности, которой потом будет очень трудно управлять. Такая проблема была, например, у Uber в начале их пути, и им пришлось пересматривать свою архитектуру. Избежать этого помогает Domain-driven design (DDD) — предметно-ориентированное проектирование.

Вместо того чтобы пилить отдельные сервисы для авторизации, логирования и уведомлений, команда может подумать вот над чем: все это части одного бизнес-контекста — пользовательского доступа. И целесообразно оставить их в одном сервисе. Это и есть DDD в действии.

Существует и еще одна проблема, с которой DDD помогает справиться, — неправильная нарезка сервисов с точки зрения бизнесовой функциональности. Если не понимать бизнес-контекста, можно получить «распределенный монолит»: будет много отдельно стоящих сервисов, но профита никакого, только все сложности микросервисов плюс проблемы монолита с масштабируемой базой данных. Особенно остро это проявляется, когда изменения в одной части бизнес-процесса (в одном сервисе) влекут за собой изменения еще в трех-четырех-пяти других сервисах.

DDD помогает выделить bounded context — согласованные по бизнесу участки. Они позволяют более или менее правильно нарезать большой бизнес-функционал на отдельные части.

Еще один важный принцип правильной архитектуры микросервисов — у каждого микросервиса должна быть своя независимая маленькая база данных (если она вообще нужна).

Два эмпирических правила, которые касаются размера сервисов и помогают понять, правильно ли они спроектированы:

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

Внедрение микросервисов: с чего начать?

С микросервисным подходом есть проблема — нет четкого ответа, куда идти и что делать, чтобы научиться его создавать. Это одна из главных сложностей микросервисной архитектуры, особенно когда только начинаешь с ней работать. Если хочется изучить Spring или Oracle, можно почитать официальную документацию. А к такой большой и необъятной теме, как микросервисы, даже и непонятно, с какой стороны подступиться. Туториала к ней нет, есть только куча статей, подходов и практик. Причем одни практики подойдут конкретной команде, а другие — нет.

И вот тут возникает реальная сложность, особенно когда вы только начинаете, — глаза разбегаются. Здесь Kubernetes, здесь ELK, здесь Grafana, здесь observability, здесь всякие паттерны отказоустойчивости, CAP-теорема и прочее. Непонятно, куда бежать. И каждый день появляются новые инструменты, которые так или иначе упрощают жизнь.

Совет: задавайте себе вопрос о каждом инструменте, который вы хотите внедрить (будь то Kubernetes, OpenTelemetry с Jaeger или любой другой) — какую проблему мы решаем, втаскивая его в свою инфраструктуру? Ответ на этот простой вопрос может дать много инсайтов и просветлений.

Чтобы в первом приближении ознакомиться с темой, можно почитать материалы SRE от Google, также будут полезны статьи и книги в блоге Мартина Фаулера, в том числе Microservices Guide. Если вам нужна практика, можно попробовать пойти на тот же Udemy, где есть множество курсов по микросервисной архитектуре с хорошими рейтингами и отзывами.

И вот что важно: при проектировании и внедрении микросервисов лучше избегать «велосипедостроения». Если индустрия уже решила проблему, нет смысла изобретать новое логирование или оркестрацию. Собственное решение вряд ли будет работать лучше, а сил, времени ресурсов на него можно потратить очень много.

Поддержка микросервисной архитектуры

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

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

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

Паттерны отказоустойчивости

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

Еще один хороший вопрос: как мониторить аварии? Необходимо очень быстро находить точку отказа. Для этого, собственно, и нужен observability-подход, трейсинг. Нужно смотреть, где какой RPS (число запросов в секунду), не произошло ли резкого скачка трафика, важно следить за latency (задержками).

Бывали случаи, когда из-за бага в мобильном приложении трафик внезапно удваивался, и системы не выдерживали такой нагрузки. Любая малейшая задержка в самом незначительном компоненте может привести к тому, что по цепочке пойдет отказ, — будут копиться потоки, соединения, и рано или поздно упадет вообще все. Чтобы подготовиться к таким ситуациям, важно изучить хотя бы четыре «золотых сигнала» мониторинга из SRE от Google.

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

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

• Circuit Breaker — если сервис спамит ошибками, лучше временно прекратить попытки до него достучаться. Для клиента ничего не изменится, он как получал ошибки, так и будет получать. Но, по крайней мере, можно дать системе возможность восстановиться. А еще лучше — позволить ей переключиться на какой-то резервный канал, например сходить в кэш с неактуальными данными.
• Rate Limiter — абсолютно банальная, но необходимая вещь. Нужно ограничивать входящий поток на примерно максимальном уровне от того, который ожидается. Чтобы все не развалилось, если произойдет резкий скачок трафика.
• Blue-Green Deployment — значительно снижают на продакшене количество аварий и проблем, связанных с кривыми релизами. Можно не раскатывать новую фичу сразу на все 100 подов, а выкатить ее только на 1% трафика и проверить.

И это только малая часть паттернов.

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

Как эффективно работать с инцидентами

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

Первый уровень — это application-слой, сами сервисы, которые в подах крутятся в Kubernetes. Нужно проверить, все ли у них хорошо по точкам интеграции — нет ли тайм-аутов. Все ли в порядке у них по железу — по CPU, по памяти, по дискам.

Если на первом уровне все нормально, нужно опуститься на уровень ниже — либо на виртуалки, на которых Kubernetes развернут, либо на железки, если он развернут на Bare-metal. Недавно мы столкнулись с интересным случаем: виртуалка показывала нормальную загрузку CPU, но физический гипервизор, на котором она крутилась, был загружен на 99%. Естественно, виртуалка страдала, но уровнем выше этого не было видно.

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

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

Вообще, человеческий фактор — это отдельная боль. Все привыкли менять что-нибудь руками: заходить в виртуалки, поправлять конфиг. Чтобы такого было как можно меньше, важно вкладываться в infrastructure as a code и даже everything as a code. В идеале следует стремиться к zero access production — нулевому доступу к продакшену — и все раскатывать через Git, через конфигурации, включая политики безопасности.

Культура ответственности и изменение ролей в команде

Представим, что происходит инцидент — падают 15 микросервисов. Как должна быть устроена система, которая позволит оперативно справляться с авариями?

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

Подобную конструкцию важно поддерживать в актуальном состоянии. Это часть процесса непрерывности, и в нее надо вкладываться. В крупных компаниях этим занимаются целые отделы, в небольших организациях — отдельный человек, но такая информация всегда должна быть в общем доступе. Иначе время «отскока» после инцидента увеличится кратно.

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

Однако эти организационные моменты еще не гарантируют быстрого решения проблемы. Ключевой фактор — культура компании. На людей часто нападает отстраненность — авария случилась, и все думают: «Кто-нибудь другой разрулит. Я разработчик, ну, что я там сделаю?»

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

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

Проще говоря, есть два варианта взаимодействия с поддержкой: классический, когда она административно отделена, и SRE-подобный, когда сотрудники «второй линии» прямо интегрированы в команду разработки. Могу сказать, что второй эффективнее.

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

Это то самое SRE, о котором пишет Google. Но людей нужно долго обучать такой культуре — это не дело одного месяца. Благодаря такому подходу инженеры, которые раньше были просто разработчиками или аналитиками, глубже осознают свою ответственность за стабильность продакшена. И это действительно правильное направление развития. Потому что и DevOps, и SRE — это в первую очередь культура, а уже во вторую — набор инструментов.

Будущее микросервисов: тренд на AI Ops

Разработчики уже используют AI как copilot — и это очень мощный инструмент в умелых руках. Он не заменяет инженера, но сильно экономит ему время. Эту помощь от нейросетей очень хочется растянуть и на инфраструктуру, и на эксплуатацию, чтобы получить крутой AI Ops.

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

Есть прототипы — например, Big Panda или Moocsoft (который был недавно куплен Dell), но пока это точечные решения. Возможно, на горизонте 5–7 лет (скорее 5, чем 10) они станут серьезной частью индустрии и очень мощным прорывом, который упростит разработчикам жизнь.Кроме того, важно, чтобы развивались и более «приземленные» технологии: инструменты контейнеризации, оркестрации, observability, а также APM — Application Performance Monitoring.

Инженер остается в центре всего

Никакие микросервисы, Kubernetes и AI Ops не спасут, если за системой не стоит инженер, который думает головой, правильно работает руками и отвечает за результат. Важны его навыки, кругозор и культура работы. Именно такие люди превращают набор сервисов в работающий продукт. Все остальное — только инструменты.

P. S. Если интересно, как мы решаем эти задачи на практике, слушайте (и смотрите) наш подкаст «Техно.Логично» — там регулярно обсуждаем самое актуальное в IT-сфере.

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

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

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

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

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

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

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Зачем вообще писать комментарии в коде?

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

Какие задачи они решают ?

1. Пояснить неочевидное

Код показывает «что» делает программа, а комментарий — «зачем».

Такой комментарий не просто поясняет логику — он экономит десятки минут будущего чтения.

2. Предупредить

В коде бывает странное поведение. Иногда это не баг, а фича. И если не предупредить, другой разработчик обязательно «поправит» и всё сломает. Комментарий защитит от этого:

3. Пометить незавершёнку

TODO, FIXME, HACK — это специальные маячки. Их ставят туда, где нужно что-то доделать, починить или переписать по-человечески.

Бонусом, IDE умеют обрабатывать такие заметки, каждая по-своему.

4. Временно отключить код

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

5. Объяснить архитектуру

Иногда важно не только «как» сделано, но и «почему так». Особенно это касается паттернов, нестандартных решений или компромиссов.

6. Генерация документации

Многие языки и фреймворки поддерживают специальные форматированные комментарии для генерации документации. Например, JavaDoc в Java, docstring в Python, XML в C# – предназначены для описания интерфейсов: что делает функция или класс, какие имеют входные параметры и какой результат дают. Такие Комментарии выполняют роль пользовательской документации прямо в коде и могут автоматически собираться в справочник по API.

7. Пошутить

Программисты – тоже люди, и иногда оставляют в коде шуточные либо эмоциональные комментарии, чтобы снять стресс. В открытых исходниках можно встретить комментарии с шутками, сарказмом или даже ругательствами, адресованными сложному коду или «костылям».

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

Когда комментарии помогают

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

1. Когда логика не лежит на поверхности

Есть участки кода, где без контекста трудно разобраться, даже если код написан довольно читабельно. Например, сложная формула, нетривиальный алгоритм или необычная структура данных – всё, что выбивается из обыденного опыта разработчиков. В таких случаях пара строк комментария, резюмирующих подход, или объясняющих, что происходит, сэкономят часы на анализ. Это особенно важно для командной работы: коллегам, незнакомым с модулем, не придётся разбираться «с нуля».

2. Когда нужно документировать контракты и условия

Комментарии могут использоваться для обозначения контрактов – предусловий и постусловий функций, инвариантов и т.д. (подход Design by Contract). Хотя современные языки позволяют выразить многое (например, через assert или декораторы), комментарии могут дополнять код уточнениями вроде:

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

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

3. Когда нужно предоставить контекст и ссылки

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

4. Когда нужно облегчить ревью

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

В PEP 8 (стиле кодирования Python) прямо приводится пример: комментарий “Compensate for border” – полезный, в отличие от банального “Increment x”, который не даёт новой информации.

5. Когда нужна поддержка самодокументируемости через структуру

Иногда хочется написать: # Этап 1: авторизация пользователя, и в этот момент приходит мысль — а почему бы не вынести это в функцию authorize_user()? И комментарий уже не нужен. То есть сам порыв объяснить словами часто указывает, что код пора расчленить и упростить.

6. Когда нужно кого-то обучить программированию или корпоративным стандартам оформления кода

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

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

Когда комментарии вредят

Худшее, что может случиться с комментариями – когда они вводят в заблуждение или засоряют код впустую. Рассмотрим подробнее:

Дублируют очевидное

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

А вот так — лучше вообще без пояснений:

Комментарий должен объяснять, зачем что-то делается, а не что именно:

Врут и вводят в заблуждение

Классика: код переписали, а про комментарий забыли.

Спустя некоторое время код могли переписать, и old_api_call() заменили на new_api_call(), но комментарий остался от прежней версии и стал источником дезинформации: разработчик, читающий код, может принять заведомо неверное решение, доверившись устаревшей заметке. По этой причине крайне важно понимать: если уж пишете комментарий, держите его в актуальном состоянии вместе с кодом.

Показывают, что код плохой

Когда код плохо читается, и его пытаются «объяснить» словами, вместо того чтобы переписать:

Вместо этого — понятный код:

Плодятся бесконтрольно

Иногда встречается код, где каждое действие сопровождается избыточными пояснениями:

Здесь нет ни одной неочевидной строки. Лучше оставить так:

Представляют собой мёртвый код

Когда в коде остаются большие мёртвые блоки, которые просто закомментированы:

Может быть, раньше это что-то значило, но сейчас — просто мертвый груз. Если код не нужен — удаляй. История останется в git.

Запутывают и размывают смысл

Что значит «временное»? Когда переделывать? Почему не постоянное?

Лучше так:

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

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

Самодокументируемый код vs комментарии

Есть мечта у программистов — писать код, который объясняет сам себя. Без сносок, без подсказок, без комментариев. Такой код читается как инструкция: открыл — понял. Это и называется самодокументируемым стилем.

Как его достигают?

• Говорящие имена. Не x и a, а temperature, retryLimit, userProfile. Лучше сразу по имени понять, что перед тобой — массив с ID или словарь с настройками.
• Функции с характером. У функции должно быть имя-глагол, в котором есть ответ на вопрос “что делает этот код?”. Например: parseInvoice(), sendEmailReminder(), fetchUserByToken().
• Использовать названия для константных значений. Вместо if (status == 4) — if (status == ORDER_CONFIRMED). Вместо 3000 — RETRY_TIMEOUT_MS.
• Структура — как абзацы в тексте. Пустые строки, логические блоки, отступы — чтобы этапы выделялись сами собой.

Посмотрим например, где простой код поясняется ненужным комментарием:

Другой пример:

Комментарий уже не нужен. Из имён всё понятно: считаем среднюю температуру. Здесь самое интересное — само документируемость имеет границы. Потому что:

• Код объясняет «что», но не всегда «почему».

Вот есть строка:

А почему 5? Почему не 3, не 10? Если причина — ограничение API, бизнес-логика или чья-то странная прихоть — код не расскажет. А вот комментарий может:

Неочевидные решения и компромиссы

Иногда приходится делать что-то нестандартное. Например:

Такой кусок кода без пояснений вызовет недоумение: А почему не сортируем?

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

Влияние ИИ и новых инструментов на подход к комментариям

В последние годы в распоряжении разработчиков появились мощные ассистенты на базе искусственного интеллекта — такие как GitHub Copilot (автодополнение кода на основе ИИ) и большие языковые модели вроде ChatGPT. Эти технологии начинают влиять и на практики комментирования кода.

Во-первых, автогенерация кода по комментариям стала реальностью.

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

Copilot тут же может подставить реализацию:

Такой подход превращает комментарий в своего рода промпт — описание задачи для ИИ. Это приучает писать коротко и по делу. Хотя такие комментарии потом часто удаляют, их роль в генерации кода становится всё важнее.

Во-вторых, ИИ сам пишет комментарии.

Можно просто показать код:

…и попросить ИИ: прокомментируй. В ответ он выдаст:

Или даже более детальный:

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

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

Раньше приходилось часами вчитываться, сегодня — можно просто спросить:

Запрос в ChatGPT: что делает эта функция?

Ответ: Она возвращает новый список, содержащий удвоенные значения тех элементов исходного списка, которые делятся на 3.

ИИ не волшебник, но в 90% случаев — удобный переводчик с машинного на человеческий. Это снимает часть нагрузки с необходимости документировать тривиальные вещи.

В-четвертых, новый тип комментариев: инструкции для ИИ

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

Если вы используете Cursor или Replit, это может очень полезным.

Заключение

Так всё-таки, комментарии – зло или спасение?

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

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

Эта статья предназначена для программистов, которые хотят понять, что такое FSM и как их строить, используя практический пример на JavaScript.

Что такое FSM?

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

Давайте представим обычный светофор

Какие бывают состояния у светофора?

1. Красный
2. Желтый
3. Зеленый

Какие бывают события у светофора?

1. Прошло определенное время (таймер сработал).

Какие бывают переходы (транзакции) у светофора?

1. Из «Красный» по событию «таймер_красного_истек» -> в «Желтый» (или «Красный+Желтый»).
2. Из «Желтый» по событию «таймер_желтого_истек» -> в «Зеленый».
3. Из «Зеленый» по событию «таймер_зеленого_истек» -> в «Желтый» (мигающий или постоянный).

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

Основные компоненты FSM

Состояния (States): Конкретные режимы, в которых может находиться система (например, idle, loading, active, error).

События (Events): Триггеры, которые инициируют изменение состояния (например, buttonClick, dataLoaded, timeoutOccurred).

Переходы (Transitions): Правила, определяющие, из какого состояния в какое можно перейти при наступлении конкретного события.

Действия/Коллбэки (Actions/Callbacks): Фрагменты кода, которые выполняются при входе в состояние, выходе из него или во время перехода.

Разбираем код на части: Класс HFSM для создания автоматов

Для построения FSM мы будем использовать предоставленный JavaScript класс HFSM (Hierarchical Finite State Machine). «H» означает «иерархический», что позволяет вкладывать одни автоматы в состояния других, но об этом чуть позже.

Ключевые моменты конструктора constructor() HFSM:

• config.initial: Имя начального состояния, в котором автомат находится сразу после создания.
• config.transitions: Объект, где ключи — это имена состояний, а значения — массивы объектов, описывающих возможные переходы. Каждый объект перехода имеет вид { event: “имя_события”, to: "имя_целевого_состояния” }.
• config.callbacks: Объект с функциями, которые будут вызываться в определенные моменты жизненного цикла FSM (например, onAfterLogin после успешного события login, или onStateChange при любом изменении состояния).
• config.states: Используется для определения вложенных FSM, делая автомат иерархическим.

Важные методы:

• trigger(event, …args): Основной метод для взаимодействия с FSM. Он принимает имя события и опциональные аргументы. Если для текущего состояния и указанного события есть разрешенный переход, автомат меняет свое состояние и выполняет связанные коллбэки.
• can(event): Позволяет проверить, допустимо ли указанное событие в текущем состоянии FSM.

FSM в действии — Примеры

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

1. Управление логикой звонков callFSM

Этот FSM описывает состояния и переходы, связанные с процессом звонка в приложении.

Предположим, пользователь инициирует исходящий звонок контакту «Alice». Код приложения вызовет:

1. callFSM находится в состоянии idle.
2. Он находит переход для события outgoingCall, который ведет в состояние checkCamera.
3. Состояние изменяется на checkCamera.
4. Выполняется коллбэк onAfterOutgoingCall(«idle», «checkCamera», «Alice»).
5. Внутри коллбэка выполняем свою логику

2. Управление состоянием камеры cameraFSM

Это более простой FSM, отвечающий исключительно за логику работы камеры.

Таким образом мы можем создавать сколько угодно fsm конструкции.

Преимущества использования FSM

• Наглядность и читаемость: Структура состояний и переходов четко описывает логику.
• Уменьшение количества ошибок: Явное определение состояний и переходов снижает риск непредвиденного поведения.
• Простота расширения: Добавление новых состояний или событий обычно не требует значительной переработки существующего кода.
• Улучшенная тестируемость: Каждое состояние и переход можно тестировать изолированно.
• Управление сложностью: Особенно полезно для систем с множеством взаимосвязанных состояний.

Заключение

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

В этой подборке — 7 курсов, после которых реально получить первую работу в IT за 3–6 месяцев.

Почему в 2025 попасть в IT и легче, и сложнее одновременно

Войти в IT в 2025 реально, но рынок сильно изменился. С одной стороны, спрос на junior-специалистов вернулся: компании снова набирают новичков, открывают стажировки и гибридные программы. Но конкуренция стала выше, а фильтры — жёстче.

Что легче

• После карьерного спада 2022–2023 спрос на junior-специалистов начал восстанавливаться. Появилось больше стажировок и вакансий для начинающих. Согласно отчёту Robert Half, начать успешную карьеру могут инженеры по данным, DevOps-инженеры и разработчики ПО. Однако конкуренция остаётся высокой, и работодатели ожидают от кандидатов не только базовых знаний, но и быстрой адаптации к новым инструментам.
• Образование и работа в IT всё чаще переходят в гибридный формат: можно совмещать онлайн- и офлайн-обучение, работать удалённо и периодически встречаться в офисе.

Что сложнее

• Конкуренция выше, чем раньше. Даже на стартовые позиции часто подаётся по сотне кандидатов.
• Работодатели ждут не просто знаний или диплома, а быстрой адаптации.

Что изменилось в 2025 по сравнению с 2020–2024

Во-первых, образование стало прагматичнее. С 2020 по 2022 год рынок был наводнен короткими курсами «на джуна». В 2025-м большинство таких школ либо закрылись, либо переформатировались: люди устали платить за теорию без практики. Сейчас ценятся программы, в которых есть командные проекты, ревью от наставников, работа с Git и проектный пайплайн, близкий к реальному.

Во-вторых, работодатели всё чаще оценивают кандидатов по их реальным навыкам и опыту, а не по формальному образованию. Согласно прогнозам, 39% текущих навыков работников устареют к 2030 году, что подчеркивает необходимость постоянного обновления и адаптации.

Так, расширяются границы образования. А вместе с ними – появляются онлайн-курсы.

7 курсов, с которых начинают карьеру в IT

1. Kata Academy — GO-разработчик

Ссылка на курс

Go (Golang) — это билет в backend-разработку, где в 2025 году крутятся большие деньги и хардовые задачи. Язык, созданный Google, ценят за скорость и простоту, а компании от стартапов до гигантов вроде Яндекса выстраиваются в очередь за Go-разработчиками. Курс от Kata Academy учит писать серверный код, работать с SQL, Git, Linux и Docker, чтобы выпускники могли строить масштабируемые приложения.

📚Что получают выпускники

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

• Есть карьерная поддержка: резюме, собеседования, вакансии;
• В договоре — гарантированная зарплата от 120 000 ₽ (может быть выше).

🎓Длительность и формат

Курс проводится полностью онлайн. Длительность обучения — 9 месяцев, включая подготовку к собеседованиям. Нагрузка: от 25 часов обучения в неделю (3-4 часа в день), есть дедлайны. Выпускник устраивается на работу после курса, в течение 1-2 месяцев (в среднем).

👥Кому подойдет

• Новичкам без опыта в программировании;
• Студентам и начинающим разработчикам, которые хотят освоить Go;
• Может быть интересен тем, кто работает во фронтенде или техподдержке и хочет сменить направление.

Не требует знаний математики и программирования — рассчитан на обучение с нуля.

🏆Возможности после курса

На сайте указано, что выпускники устраиваются в компании, такие как Яндекс, Альфа-Банк и Kaspersky, часто в течение первого месяца после завершения основной программы курса. Если выпускник не найдет работу с зарплатой от 120.000 рублей, то оплачивать обучение не придется.

💸 Стоимость и условия участия

Есть два варианта обучения:

• Интенсивное (стоимость — 110 000 рублей во время учебы плюс 20% от зарплаты в первый год работы). Для тех, кто живет в Москве или Санкт-Петербурге, или готов туда переехать.
• Асинхронное (стоимость — 262 000 рублей). Обучение в своем темпе, нет дедлайнов. Можно искать работу в любом городе-миллионнике, если не получится устроиться — есть гарантия возврата денег.

2. CyberEd — Пентестер

Ссылка на курс

Пентест (тестирование на проникновение) — это процесс поиска уязвимостей в IT-системах путем имитации атак хакеров.

Курс обучает анализу защищенности веб-приложений, сетей и инфраструктуры, а также использованию инструментов вроде Nessus и Nmap.

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

📚Что получают выпускники

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

🎓Длительность и формат

Обучение длится 24 недели (365 академических часов) и проходит полностью онлайн. Есть два формата:

• Синхронный формат — с расписанием и онлайн-занятиями в группе. Включает 24 онлайн-семинара по 4 часа, регулярную обратную связь от наставников и карьерные консультации.
• Асинхронный формат — без привязки ко времени: обучение проходит в удобном для студента темпе. Доступ ко всем материалам курса, заданиям и модулям открыт сразу.

Оба формата включают более 100 практических заданий, поддержку менторов и итоговый проект.

👥Кому подойдет

• Айтишникам, которые хотят научиться пентесту или прокачаться в кибербезопасности.
• Системным администраторам, веб-разработчикам, специалистам по ИБ, а также джунам и миддлам из пентеста, Blue Team или AppSec.

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

🏆Возможности стажировки и трудоустройства

Выпускники устраиваются на позиции инженеров по безопасности или пентестеров, в том числе в крупные IT-компании. По отзывам студентов, некоторые находят стажировку уже на 4 месяц обучения, а часть получает постоянные позиции в течение 1 года после финала курса.

💸 Стоимость и условия участия

138 000 рублей за синхронный формат, 74 000 рублей за асинхронный. Доступна рассрочка на 2 года — 6 900 рублей в месяц.

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

3. Яндекс Практикум — Инженер по тестированию

Ссылка на курс

Инженер по тестированию (QA-инженер) проверяет качество программных продуктов: ищет ошибки в веб-приложениях, мобильных приложениях и API.

В программе курса Яндекс Практикума будут основы ручного тестирования, работа с тестовой документацией и инструментами, базовые навыки автоматизации, а также отдельные модули по информационной безопасности, Figma, Python и SQL.

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

📚Что получают выпускники

• В финале курса Практикум выдаёт диплом о профессиональной переподготовке.
• Также у выпускников остаётся портфолио из 7 учебных проектов (в расширенной версии курса — из 9). Среди них, например, — итоговая работа над сервисом Яндекса (тестирование Яндекс.Маршрутов и т.д.).
• Дополнительно открывается доступ к модулю по YandexGPT и YandexART.
• В течение семи месяцев после окончания обучения доступна карьерная поддержка. При желании можно набираться опыта в Мастерской Практикума — это агентство внутри Практикума, где выпускники работают над задачами реальных заказчиков.

🎓Длительность и формат

• Курс рассчитан на пять месяцев — это 318 академических часов, в среднем около 20 часов в неделю. Обучение проходит онлайн.
• Теоретическая часть будет в виде интерактивного учебника, а практические задачи выполняются по спринтам: каждые три недели — новый проект.
• Воркшопы и консультации с наставниками проходят по расписанию. У студентов есть дедлайны по проектным заданиям.

👥Кому подойдет

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

🏆Возможности стажировки и трудоустройства

После завершения программы карьерный центр помогает в трудоустройстве (доступны карьерная поддержка в течение 6+ месяцев после обучения, фриланс-трек для тех, кто хочет работать на себя, вакансии и стажировки от партнёров и мастерская проектов). В среднем, стажёры зарабатывают около 52 000 рублей, джуниоры — 76 000, мидлы — 142 000 рублей.

💸 Стоимость и условия участия

• Junior-трек. Подходит для старта в тестировании. 77 000 ₽ — при полной оплате; 16 500 ₽/мес. × 5 месяцев — при рассрочке.
• Расширенный трек. Тут больше практики и навыков, чтобы быстрее вырасти до мидла. 148 000 ₽ — при полной оплате; 18 500 ₽/мес. × 9 месяцев — при рассрочке.
• От новичка до автоматизатора. Сразу две профессии: ручное и автоматизированное тестирование. 156 000 ₽ — при полной оплате. 20 000 ₽/мес. × 9 месяцев — при рассрочке.

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

4. Rebrain — Мини-практикум Golang с нуля

Ссылка на курс

Мини-практикум от Rebrain знакомит с основами Go, включая синтаксис, работу с каналами, контекстами и микросервисами. Программа ориентирована на практическое освоение языка через выполнение задач, моделирующих реальные сценарии backend-разработки.

📚Что получают выпускники

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

Доступ к комьюнити и онлайн-мероприятиям Rebrain позволяет продолжать обучение и налаживать профессиональные связи. Теоретические материалы остаются доступными навсегда.

🎓Длительность и формат

• Курс длится около 2 недель, но продолжительность зависит от темпа студента.
• Программа полностью онлайн и асинхронная, что позволяет учиться в удобное время без привязки к расписанию.
• Формат текстовый, без видеолекций, с акцентом на практику (90% времени).

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

👥Кому подойдет

• Студентам с потенциалом для Go;
• Начинающим разработчикам без практического опыта;
• Специалистам из смежных IT-направлений.

Здесь нужны минимальные навыки работы с системами контроля версий (GitHub/GitLab), но глубокие знания программирования не требуются.

🏆Возможности стажировки и трудоустройства

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

💸 Стоимость и условия участия

Стоимость курса — 14 990 рублей при полной оплате или 1 249 рублей в месяц при рассрочке на 12 месяцев. Для поступления достаточно подать заявку через сайт; специальных требований, кроме базового понимания IT, нет. Курс подходит для самостоятельного обучения, но требует дисциплины из-за асинхронного формата.

5. Systems.Education — Системный аналитик / Проектировщик корпоративных информационных систем

Ссылка на курс

Цель программы — получить профессию системного аналитика, которая соответствует актуальным требованиям вакансий на рынке.

На курсе от Systems.Education вы за 3 месяца пройдёте реальный кейс за счёт работы с:

• Формальным моделированием бизнеса и бизнес-проблемы: Event Storming, BPMN, Opportunity canvas.
• Разработкой пользовательских требований: Impact map, User story map, Use case diagram, Use case scenario.
• Концептуальным проектированием ИТ-решений: моделирование предметной области, UML диаграмма состояний, Контекстная диаграмма, Концептуальная модель данных, Макеты приложений.
• Спецификацией требований к системе: Функциональные требования к системе, Нефункциональные требования к системе, Требования к информационной безопасности, Системные алгоритмы.
• Техническим проектированием ИТ-решений: Диаграмма взаимосвязи объектов, диаграммы в нотации С4, Требования к интеграции, UML диаграмма последовательности, Data flow diagram.

📚Что получают выпускники

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

🎓Длительность и формат

Курс длится 3 месяца (200+ академических часов) и проводится полностью онлайн: 8 часов в неделю — занятия с преподавателем в Zoom, дополнительно — командные и индивидуальные созвоны с ментором. Процесс обучения осуществляется в командах, в которых участники работают над реальным кейсом.

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

👥Кому подойдет

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

🏆Возможности стажировки и трудоустройства

• Защитите итоговый проект прямо перед HR и техспецами из компаний.
• Получите портфолио из настоящих проектных документов (артефактов) — всё, что требуют работодатели на позиции младшего системного аналитика.
• В течение всего обучения вас будут сопровождать менторы-практики: помогут с проектом, дадут фидбек, подготовят к собеседованиям.

По статистике школы, выпускники за год могут дорасти до уровня Middle-аналитика.

💸 Стоимость и условия участия

• 205 000 рублей для физических лиц
• 255 000 рублей для юридических лиц.

Действует скидка на раннее бронирование. Потоки стартуют раз в три месяца. Для поступления требуется подать заявку через сайт. Базовые знания IT-процессов желательны, но специальных тестов нет. Гарантируется 100% возврат средств при отказе до начала обучения.

6. Karpov.Courses — Аналитик данных

Ссылка на курс

Курс от karpov.courses учит работать с Python, SQL, Power BI и другими нужными инструментами для анализа, визуализации и автоматизации. В программе много практики: решаете реальные задачи — A/B-тесты, расчёт метрик, анализ больших данных, работа с хранилищами.

📚Что получают выпускники

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

Материалы курса остаются доступны бессрочно.

🎓Длительность и формат

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

👥Кому подойдет

• Новичкам без опыта в IT, студентам, чтобы освоить аналитику данных.
• Маркетологам и менеджерам, чтобы рассчитывать метрики бизнеса и их эффективность.
• Специалистам с релевантным опытом (джуниорам и выше).

Базовые навыки работы с данными (например, Excel или SQL) полезны, но не обязательны.

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

🏆Возможности стажировки и трудоустройства

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

Выпускники могут стать младшими аналитиками данных или Data Scientist с медианной зарплатой на старте 100–120 000 рублей, а если уровень мидл — от 180 000 рублей. По данным школы, 3 месяца — средний срок успешного трудоустройства.

💸 Стоимость и условия участия

Стоимость базового тарифа — 80 000 рублей при единовременной оплате. Доступна беспроцентная рассрочка на 24 месяца (платёж примерно 4 408 рублей в месяц).

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

7. Нетология — Инженер по тестированию

Ссылка на курс

Инженер по тестированию (QA-инженер) отвечает за проверку качества программного обеспечения, выявляя ошибки в веб-приложениях, мобильных сервисах и API. Курс от Нетологии обучает ручному и автоматизированному тестированию, включая работу с инструментами и языками программирования (Python, Java, JavaScript).

Программа предлагает три трека:

• «Ручное тестирование» для новичков;
• «QA-инженер уровня Junior» с основами автоматизации;
• «QA-инженер уровня Middle» с углубленным изучением JavaScript, мобильного и нагрузочного тестирования.

Студенты работают над реальными кейсами от партнеров — Dragons, OneTwoTrip и GOD.

📚Что получают выпускники

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

Материалы курса доступны в личном кабинете навсегда.

🎓Длительность и формат

• Курс проводится полностью онлайн, длительность зависит от трека: в среднем, 4–6 месяцев.

• Занятия включают вебинары по расписанию (не чаще 2 раз в неделю после 19:00 МСК), видеолекции, тесты и практические задания.

• На обучение требуется 8–10 часов в неделю. Формат сочетает синхронные вебинары с асинхронной работой через личный кабинет.

👥Кому подойдет

• Новичкам без опыта, студентам и специалистам из смежных сфер.

• Трек Junior подходит для начинающих, интересующихся автоматизацией, а трек Middle — для тех, кто хочет углубить навыки и претендовать на более высокие позиции. Базовый английский полезен, но программирование не обязательно для старта.

🏆Возможности стажировки и трудоустройства

Программа позволяет начать карьеру в ручном тестировании уже через 2 месяца обучения, на фрилансе или в найме.

Выпускники трека Junior могут начать карьеру младших QA-инженеров (медианная зарплата около 76 000 рублей), а трека Middle — на более сложные роли с зарплатой от 142 000 рублей.

💸 Стоимость и условия участия

Стоимость зависит от трека (цены указаны с учетом скидки 40%):

• Ручное тестирование: 56 700 рублей (или 2 487 рублей/мес. на 24 месяца)
• QA-инженер уровня Junior: 105 000 рублей (или 3 070 рублей/мес. на 36 месяцев).
• QA-инженер уровня Middle: 130 500 рублей (или 3 816 рублей/мес. на 36 месяцев).

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

Как выбрать правильный курс под себя?

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

FAQ: частые вопросы от новичков

Можно ли войти в IT без высшего образования?

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

Реально ли устроиться после курсов?

Да, но результат зависит от трёх факторов: качества курса, вашей активности и текущего спроса на рынке труда.

Что выбрать: универсальный курс или узкую специализацию?

Зависит от вашей подготовки:

• Универсальный курс: подходит новичкам. Дает обзор направлений, помогая выбрать специализацию. Минус — знания менее глубокие.
• Узкая специализация: для тех, кто знает, чего хочет. Дает глубокие навыки для конкретной роли, но требует начальной базы или четкой цели.

Так НЕ надо:

• Брать узкую специализацию «потому что все советуют», без анализа своих склонностей (например, идти в кибербезопасность, хотя нравится работа с данными).
• Выбирать универсальный курс в надежде потом определиться — это растягивает сроки выхода на рынок.

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

Мы в Smart Engines занимаемся разработкой софта для распознавания самых разных документов — начиная от паспорта РФ, свидетельства о рождении и заканчивая первичкой вроде УПД или ТОРГ-12, а также банковских карт, номеров телефона и баркодов. Наши библиотеки написаны полностью с нуля (на плюсах), мы уделяем огромное внимание скорости алгоритмов, нейросетям (новым архитектурам, размеру и правильному применению) и оптимизации, за счет чего наш софт портируется на любые архитектуры и может быть использован на любой платформе.

Сегодня продолжим знакомиться через рассказ о нашем софте, на очереди вторая библиотека — Smart Document Engine и ее возможности работы с жесткими и гибкими формами.

Гибкие и жесткие формы

Вначале про сами формы: они могут быть «жесткими» и «гибкими». Жёсткие формы подразумевают, что положение всех объектов на форме может быть задано прямо в виде координат на шаблоне. Самое простое определение для жестких форм — они совпадают «на просвет». Возьмите пару листов А4 с распечатанной жёсткой формой, наложите друг на друга, и места расположения полей точно совпадут. Гибкие формы устроены гораздо сложнее, но все равно имеют свою характерную структуру и топологию.

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

Кстати, иногда вместо распознавания текста целиком достаточно просто ответить на вопрос «есть ли текст в выбранной области, и, если есть, то где»

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

Также существуют общие для подобных форм проблемы. Правильно интерпретировать галочки в чекбоксах, найти штрихкоды, правильно разметить табличные данные — есть куча проблем, каждая из которых имеет своё state-of-the-art решение и набор алгоритмов, над которыми нужно ломать голову.

Почему не LLM, хотя казалось бы

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

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

В прошлом году на одной из ключевых конференций в области анализа и распознавания документов — ICDAR — учёные традиционно задались вопросом о будущем OCR. И сошлись во мнении, что OCR нисколько не устарела, благополучно развивается и остается наиболее надежным инструментом распознавания. Обеспечить требования консистентности (и ещё всякого такого) информации, извлекаемой из изображения, все равно сможет только старый добрый OCR и прочие детерминированные алгоритмы. И именно их разработкой (и доведением до совершенства) мы и занимаемся.

Вернёмся к библиотеке Smart Document Engine. Как уже говорилось выше, гибкие формы на то и гибкие, что исключительно геометрией на них не обойдёшься — вопрос местонахождения полей решается «на лету». На процесс взаимодействия с библиотекой это влияет в самом конце, на моменте работы с результатом. Перейдем к знакомству с интерфейсом на примере всё того же встраивания в андроид.

Встраивание

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

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

Как правило, результат распознавания представляют в виде json-объекта, но для наглядности лучше всего пользоваться html — особенно в случае, когда логические и физические поля имеют больше одного соответствия. Вот простенький генератор html на основе документа:

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

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

На этом мы не заканчиваем, ждите новых статей!

Откуда возник CORS

Всё началось в начале 2000-х, когда веб-приложения становились всё сложнее, а разработчики чаще нуждались в данных с других доменов. Однако браузеры строго придерживались политики одного источника (Same-Origin Policy, SOP), запрещавшей доступ к сторонним ресурсам. Эта политика появилась ещё в 1995 году в Netscape Navigator 2.0 и была призвана защитить пользователей от атак вроде XSS. Проблема в том, что SOP блокировала не только вредоносные, но и вполне легитимные запросы, например, к внешним API. Разработчики пытались обойти ограничения с помощью JSONP или iframe, но такие решения были небезопасными и нестабильными.

В 2005 году инженер Мэтт Ошри предложил идею более надёжного и безопасного механизма, который в дальнейшем стал основой CORS. А в 2008-м Анн ван Кестерен подготовила черновик спецификации для W3C. В 2014 году CORS официально вошёл в стандарт Fetch API и с тех пор стал ключевым элементом работы с кросс-доменными запросами. Он помогает контролировать доступ к ресурсам, сохраняя баланс между открытостью веба и безопасностью пользователей.

Как устроен CORS

CORS работает как диалог между браузером и сервером, основанный на HTTP-заголовках. Когда фронтенд-приложение (например, на сайте frontend.com) запрашивает данные с другого домена (api.com), браузер автоматически добавляет к запросу заголовок Origin: https://frontend.com. Этот заголовок сообщает серверу, откуда пришёл запрос.

Сервер в ответ решает, разрешать ли доступ. Если он включает в ответ заголовок Access-Control-Allow-Origin и указывает там адрес запроса (например, https://frontend.com) или символ * (разрешение для всех доменов), то браузер пропускает ответ. Если такого заголовка нет или значение не совпадает, браузер блокирует ответ — даже если сервер технически его отправил.

Для так называемых «сложных» запросов, например, с методом POST или нестандартными заголовками, браузер сначала отправляет предварительный (OPTIONS) запрос, чтобы уточнить у сервера, допустим ли основной. В ответе сервер указывает, какие методы (Access-Control-Allow-Methods) и заголовки (Access-Control-Allow-Headers) разрешены.

Пример ответа сервера с разрешением:

Топ-7 самых частых ошибок в CORS и как их исправить

Для того чтобы определить оптимальные методы работы, лучше учиться на ошибках. Хорошая новость в том, что почти все CORS-ошибки легко понять и исправить — если знать, где искать. Ниже собрали 7 самых распространённых ошибок CORS, с которыми сталкиваются разработчики, и рассказали, как можно с ними справиться без боли и паники.

Нет заголовка Access-Control-Allow-Origin

Сообщение об ошибке:

"No ‘Access-Control-Allow-Origin’ header is present on the requested resource"

Когда ваш JavaScript-код пытается получить данные с другого домена, браузер ожидает, что в ответе будет заголовок Access-Control-Allow-Origin. Если его нет — браузер блокирует ответ, считая его небезопасным.

Решение 1: Настроить сервер на разрешение CORS

Если вы контролируете сервер, добавьте в ответ заголовок:

Access-Control-Allow-Origin: *

* — разрешение запросов с любого домена

Но для безопасности лучше указать конкретный домен:

Access-Control-Allow-Origin: http://example.com

Решение 2: middleware CORS в Express.js

Если вы используете Node.js с Express, добавьте:

Браузер блокирует preflight-запросы (OPTIONS)

Сообщение об ошибке:

"CORS policy preflight request did not succeed" или что-то похожее.

Иногда перед настоящим запросом браузер сначала отправляет preflight-запрос методом OPTIONS, чтобы проверить, разрешен ли основной запрос. Это происходит, если:

• Метод запроса не GET или POST (например, PUT, DELETE).

• В заголовках есть что-то нестандартное (например, Authorization или Content-Type: application/json).

Если сервер не умеет обрабатывать OPTIONS — все ломается.

Решение: Обработать OPTIONS-запросы на сервере

Пример для Express.js:

app.options('*', cors()); // Разрешаем preflight-запросы

Или настройка CORS с поддержкой OPTIONS:

Запросы с учётом сессий (credentials) блокируются

Сообщение об ошибке:

"The value of the ‘Access-Control-Allow-Origin’ header in the response must not be '*' when the request's credentials mode is 'include'"

Вы отправляете запрос с куками или авторизацией (credentials: 'include'), но сервер разрешает доступ всем (Access-Control-Allow-Origin: *). Это запрещено — нельзя слать credentials, если разрешено всем.

Решение: Указать конкретный домен и разрешить credentials

На сервере также добавьте:

Access-Control-Allow-Credentials: true

Смешанные протоколы — HTTP и HTTPS

Сообщение об ошибке:

"Mixed content: The page at 'https://...' was loaded over HTTPS, but requested an insecure resource 'http://...'."

Ваш сайт работает по HTTPS, а API — по HTTP. Браузеры считают, что это опасно, и банально блокируют запросы.

Решение:

• Переведите API на HTTPS.
• Обновите все ссылки с http:// на https://.

• Если работаете локально и сервер только HTTP, используйте ngrok, чтобы создать HTTPS-туннель.

CORS блокирует редиректы

Сообщение об ошибке:

"Redirect from '...api' to '...login' has been blocked by CORS policy."

API делает редирект, но в ответе на редирект нет CORS-заголовков. Браузер не знает, можно ли доверять редиректу, и блокирует.

Решение:

Убедитесь, что редирект тоже возвращает правильные заголовки:

Access-Control-Allow-Origin: http://example.com

Если используете fetch, добавьте:

Неверно настроен Access-Control-Allow-Headers

Сообщение об ошибке:

"Request header field <X> is not allowed by Access-Control-Allow-Headers"

Ваш запрос содержит нестандартный заголовок (например, Authorization), а сервер не пропускает его.

Решение:

На сервере укажите, какие заголовки разрешены:

Метод запроса запрещён сервером

Сообщение об ошибке:

"Method PUT is not allowed by Access-Control-Allow-Methods"

Вы отправляете запрос методом PUT, PATCH, DELETE, а сервер разрешает только GET и POST.

Решение:

На сервере явно разрешите нужные методы:

Вместо успеха — выгорание, фатальный рефакторинг и отсутствие дисциплины. Ниже — краткий пересказ его откровения и важных уроков.

Как все начиналось

Sandpolis задумывался как универсальный инструмент для системных администраторов. Идея пришла в университете, энтузиазма хватало. Уже в 2019 году у проекта была рабочая Java-серверная часть (~50 000 строк кода) и небольшой iOS-клиент на Swift (~10 000 строк).

Но затем случился «переписон» — автор решил, что все нужно перевести на Rust, «язык будущего». Так началась вторая жизнь проекта. К сожалению, безрезультатная.

Почему за 7 лет не получилось даже MVP

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

• Переписывание ради языка. Rust стал увлечением, и проект превратился в площадку для экспериментов, а не развития продукта.
• Фокус на «интересном», а не важном. Вместо ключевых проблем (например, проработки модели данных) автор занимался второстепенными деталями: паролями, мелкой оптимизацией.
• Дыры вместо структуры. Поскольку сложные задачи откладывались, проект обрастал кусками кода, которые не складывались в единую систему.
• Отсутствие дисциплины. Основной диагноз: нежелание делать трудное и скучное. Работа велась по принципу «где интересней» — но не «где нужней».

Что автор понял спустя 7 лет

Дисциплина — это то, чего в инженерии сегодня не хватает так же сильно, как хорошего вкуса.

Основные выводы:

• Делай приоритетное — даже если оно скучное. Не отвлекайся, пока не решишь главную задачу.
• Чем дольше код сломан — тем сложнее его починить. Правки должны возвращать проект в рабочее состояние как можно быстрее.
• Не переписывай без причин. Переписка кода на новом языке может уничтожить весь прогресс.
• Ранние ошибки становятся дорогими. Лучше «заплатить» временем сразу, чем страдать потом.
• Идеи без реализации — это просто мечты. Рабочий код важнее красивых концептов.

Что дальше

Разработчик пообещал, что в 2025 году он сосредоточится только на одной вещи: идеальной модели данных для Sandpolis. А уже после — будет строить вокруг нее приложение.

Больше новостей в нашем тг-канале Представляешь

Как это происходило

Пользователь заходил на сайт с установленным Meta* Pixel или Яндекс.Метрикой, и в этот момент JavaScript-скрипт пытался установить соединение с приложением через локальные порты. Через WebRTC (в случае Meta*) или HTTP (в случае Яндекса) передавались cookies, Android Advertising ID и другие идентификаторы. Это позволяло деанонимизировать пользователя, даже если он не был авторизован, использовал режим инкогнито или регулярно очищал cookies. Сессии с разных сайтов можно было связать в одну, а история посещений становилась доступной для дальнейшего анализа.

Уязвимость заключалась в том, что другие приложения, установленные на том же устройстве, могли подключаться к тем же портам и перехватывать передаваемую информацию. Это нарушало не только пользовательскую приватность, но и фундаментальные ожидания безопасности, встроенные в браузеры. Chrome, Firefox и Edge оказались уязвимы, а Brave и DuckDuckGo блокировали такие попытки благодаря собственным механизмам защиты.

Методика отслеживания, по данным исследователей, действовала минимум с 2017 года. Meta использовала WebRTC STUN с ноября 2024-го, затем перешла на TURN в мае 2025-го. Только 3 июня компания полностью отключила отправку данных на localhost, удалив соответствующий код. Яндекс использовал HTTP-метод с 2017 года и перешёл на HTTPS в 2018-м. Трекинг через порты также подтверждён и со стороны Яндекса. Оба вендора не документировали эти механизмы, и пользователи не были о них информированы.

По информации BuiltWith, Meta* Pixel встроен на 5,8 миллиона сайтов, а Яндекс.Метрика — почти на 3 миллиона. При сканировании топ-100 000 доменов Meta* пыталась установить соединение с localhost более чем на 13 тысячах сайтов в США и почти на 12 тысячах в Европе. Яндекс зафиксирован на более чем 1000 сайтов в каждом из этих регионов.

Стало известно, что эти механизмы отслеживания работали даже без входа в учётные записи, при активном режиме инкогнито и при удалении всех cookie. Это делает обнаруженные схемы особенно тревожными — обходятся ключевые инструменты защиты приватности и поднимаются серьёзные вопросы о допустимости подобных практик.

* Компания Meta и её продукты признаны экстремистскими, их деятельность запрещена на территории РФ