Проектирование и рефакторинг *

Привет, Хабр! Меня зовут Егор Смирнов, я руководитель команды Backend for Frontend в VK. Одна из зон нашей ответственности — поддержка и развитие инфраструктуры для фронтенда ВКонтакте. 

Веб-версии ВКонтакте в 2026 году исполнилось 20 лет. За это время наш фронтенд прошёл путь от AJAX до современного веб-приложения. Раньше мы вручную манипулировали DOM, сборка иконок превращалась в приключение, а деплой и откат занимали по полчаса. К середине 2026 года мы выстроили масштабируемую архитектуру, в которой компоненты, сборка и деплой работают как единая система.

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

В собственном маркетплейсе я однажды обнаружил ошибку в обработчике платежей. Логика выглядела правильной: проверить статус PENDING, перевести операцию в SUCCESS и начислить баланс. Но при одновременной обработке двух webhook’ов оба запроса могли пройти проверку и начислить деньги дважды. Этот код я написал сам, без AI.

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

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

В цифровую эпоху приватность и надёжность хранения данных важны как никогда.

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

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

Наблюдается кризис доверия к софту и запрос на импортозамещение.

Техно-гильдия Giper.Dev приняла этот вызов, и вот что у нас получилось...

Как опубликовать внутренний API из DMZ, если соединения в LAN запрещены: пять подходов, которые мы проверили

Все пять схем мы собирали на NEOMSA APIM, российской платформе управления API от Neoflex. Сводка по вариантам:

Клиент оплатил доступ на сутки в 01:00, а первый ответ получил в 10:00. Если срок отсчитывается от оплаты, на переписку осталось 15 часов.

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

В первой части мы рассмотрели теорию, лежащую в основе концепции луковой архитектуры. Теперь предлагаю рассмотреть практическое применение. Будет МНОГО кода.

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

Большинство .NET-разработчиков знакомятся с этими тремя архитектурами в одном и том же порядке: N-tier — в первых проектах, Clean Architecture — когда её приносит команда или шаблон, и Vertical Slice — когда о ней упоминают на код-ревью или в докладе на конференции. Каждую из них подают как улучшение предыдущей. На практике они отвечают на несколько разные вопросы, и правильный выбор зависит скорее от проекта, чем от того, какая из них новее.

Можно ли описать архитектуру на Python, а получить работающий каркас сервиса на Go, C++, Rust или TypeScript? Причём так, чтобы схема не становилась отдельной документацией, которую все забывают обновлять.

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

Одна из участниц команды, с которой сейчас я веду разработку очень крутого ПО для создания интерактивых сцен и анимаций (в следующих статьях об этом будет), сказала мне про то, что не воспринимает светлую тему и всегда переключает на тёмную – и отдаёт предпочтение тем программам, где реализовано переключение на тёмную тему. Это не могло не навести меня на мысль, что стоило бы добавить и в мой музыкальный редактор 3BIT тёмную тему, чем я и занялся по приходу домой. Каково было моё удивление от осознания, что отсутствие выделения основных функций, касающихся стиля пользовательского интерфейса, в отдельный файл и последовательного описания там основных констант может вылиться в невозможность разработки более сложной архитектуры UI. И проблема болезненная, ведь проект большой, разные элементы были распределены по разным уголкам кода.

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

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

Наивность, fail-fast, fallback, failback, оптимизация и стратегия — на слизне, на кухне и на JavaScript

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

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

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

Дальше — про две версии движка: шаблоны у шестой и седьмой несовместимы, и одного файла на обе не бывает. Плюс пример целиком, переход с 2.0.x и честный список шероховатостей: где подход неудобен, где он не работает и кому он не подходит вовсе.

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

Что бы вы ни думали о программировании с привлечением ИИ, сейчас подходы к созданию ПО меняются. Все задумываются: «Что останется важным»? Сколько людей — столько мнений, но выскажу моё: большинство идей из области предметно‑ориентированного проектирования (DDD) сейчас важны как никогда, поскольку парадигма DDD никогда не ограничивалась кодом как таковым. Чем активнее развивается агентное программирование, тем лучше требуется понимать предметную область, хорошо её моделировать и осваивать командную работу. Давайте поговорим о том, чему такому нас по‑прежнему может научить DDD, чего не в состоянии заменить ИИ.

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

Свой корпоративный мессенджер на FastAPI и React: зачем он нам понадобился, что в нём есть и что ломалось по дороге.

Я запустил проект создания системы управления корпоративной архитектурой, в которой объекты и связи живут с полной историей изменений, как код в git: ветки, коммиты, сравнение состояний, слияние. Работаем вдвоём: я и ИИ‑агент. Я ставлю задачи, принимаю решения и отвечаю за результат; он пишет документы и код — и он же был соавтором архитектуры, которую я собрал в диалоге с ним ещё до того, как завёл репозиторий. Начну с постановки задачи: именно она связала мне руки сильнее, чем любое последующее архитектурное решение.

Привет, Хабр. Меня зовут Виктор Жабин, я архитектор в Т1. Эта статья — начало большого руководства по созданию луковой архитектуры своими руками.

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

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

Но если мы говорим о фронтенде, то луковый подход обретает свои особенности. Здесь слои чаще всего выглядят как UI‑компоненты (внешний слой), бизнес‑логика (внутренний слой) и API‑клиенты (внешний слой). И хотя топология остаётся той же — ядро в центре, адаптеры снаружи, — конкретные инструменты и практики сильно отличаются от бэкенда, а принцип изоляции бизнес‑логики от внешних технологий работает так же.

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

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

19 сентября в одной папке src/ лежало 29 тысяч строк, около шестидесяти файлов, и ни одного пакета. pyproject.toml с пустым списком модулей, всё запускается из репозитория. Я сел писать план.

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

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

По плану переезд занимал один день. Ушло восемь дней, переехало восемь модулей.

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

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

Третья часть серии — практическая. Как подключить библиотеку к Maven-проекту, написать первый модульный отчёт и что после этого происходит с шаблоном при сборке.

Субрепорт — это класс, отчёт — тоже класс, а поля класса и есть содержимое отчёта. Имена параметров шаблона берутся из имён полей, поэтому один и тот же модуль можно поставить в отчёт дважды и получить два независимых субрепорта со своими данными. Аннотационный процессор при компиляции находит существующий JRXML, дописывает в него недостающие параметры, датасеты и банды субрепортов и кладёт результат в target/generated-sources. Шаблон в src он не трогает никогда.

Отдельно — про то, кто владеет шаблоном, когда в один файл пишут и кодогенератор, и человек в Jaspersoft Studio, и где у этой схемы слабое место.

Первая часть — откуда взялся Jasper и почему он так устроен, вторая — один стандарт и три идеи.

Во второй части серии — чего ждёт от инструмента отчётов современный Java-разработчик и на каких идеях я собрал свою надстройку над JasperReports — не переписывая движок и не отказываясь от Jaspersoft Studio.

Один стандарт вместо нескольких способов передать данные: в отчёт едут обычные Java-объекты. Дерево вместо плоской сетки банд: отчёт собирается из модулей, вложенных друг в друга, включая повторяющиеся. Слои: данные добывает Java, вёрстка остаётся в JRXML и в Studio. И объект как единый носитель структуры, данных и имён — вместо одного и того же смысла, продублированного и в XML, и в коде.

Отдельно — ответ на возражение из комментариев к первой статье: зачем вообще выносить выборку данных из шаблона, если Jasper умеет ходить в базу сам.

Первая часть серии — откуда взялся Jasper и почему он так устроен.