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

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

Большинство .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 и почему он так устроен.

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

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

Это не критика. Ядро у Jasper мощное, просто он наследник другой традиции — той, где отчёт является самостоятельным приложением, а не частью вашего.

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

Обычно я пишу здесь разборы научных статей про LLM и ИИ в целом. В этот раз жанр другой: расскажу о MWS AI Agents Platform, платформе, которая как раз берет на себя обвязку, превращающую LLM и теорию из статей в работающие проекты.

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

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

Первый: 50 человек персонала, результата практически нет, еле успели доделать всё за год.

Второй: людей втрое меньше, и по успешности всё сильно лучше, чем в первом проекте.

Давайте посмотрим на суровую реальность. График роста численности персонала в первой компании летит вверх по экспоненте. Они нанимают, нанимают, нанимают. А рядом — график продуктивности (Time-to-Market), который падает с каждым релизом. Фонд оплаты труда растёт, а скорость поставки фич снижается.

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

Очень часто это проблема архитектуры.

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

Сказать это очень просто, а вот сделать на практике — ГОРАЗДО сложнее. Сложнее не технически, а именно с точки зрения внутренней дисциплины команды и осознания важности проектирования.

Как я отдал агенту четыре репозитория и увидел то, что в коде не видно в принципе.

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

255 — столько у нас было пар «экран × язык» в телеграм-боте, и каждая строчка текста лежала внутри PHP-класса. Чтобы поправить запятую в немецком, нужен был PR, ревью и деплой.

Рассказываю, как мы выносили экраны и переходы бота из кода в YAML на живом проде, без окна обслуживания: почему \n в PHP не равен \n в YAML, зачем понадобилось экранирование поверх экранирования, как 64 байта callback_data определили схему базы и почему стек навигации из JSON-колонки пришлось мигрировать совместимостью, а не конвертацией. Плюс чеклист из 12 пунктов.

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