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

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

В статье рассказываю, как я перестроил процесс проектирования фич через связку:

— чата с агентом бизнес‑аналитиком;
 — графовой модели изменений;
 — MCP‑доступа к модели;
 — агентского бутстрапа;
 — формализованного техпроцесса.

На примере разработки агентской памяти показываю, как User Story превращается в граф ролей, целей, мотивов, API и зависимостей, а агент перестаёт быть «чатиком сбоку» и становится участником инженерного процесса.

Это не история про «ИИ пишет код».
Это история про то, как инженерное знание начинает работать как код.

Привет всем, на связи снова Дарья Борисова, системный аналитик из ПСБ. Продолжаю развеивать мифы о REST API. Если вы пропустили первую и вторую часть, то советую заглянуть туда: ведь мы уже разобрали некоторые заблуждения о природе REST. Сегодня мы разберем нюансы транспортных и бизнес-ошибок, погрузимся в кеширование и узнаем, действительно ли REST должен быть прокси для базы данных.

Переходите под кат, начинаем!

Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья — продолжение предыдущей: Мой справочник по Feature-Sliced Design. На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD.

Air Canada проиграла суд за слова чат-бота. Дилер Chevrolet «продал» Tahoe за доллар. Корень один: LLM одновременно решает что сказать и как. Под давлением точность проигрывает беглости. Разбор паттерна, который это чинит.

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

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

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

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

Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».

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

Я обещал публиковать честно: и где всё идёт по плану, и где разбиваешься о реальность. Вот статья про и то, и другое.

Три итерации — ровно. Четвёртая — ветка feat/iter-4 удалена, откат на main. Причина не в технических проблемах. Причина в том, что я наконец честно посмотрел на то, что построил, и понял: модель диалога слабая.

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

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

Захожу в проект. Стек: FastAPI, PostgreSQL, Redis как Celery broker, Celery workers, Docker, Web3. Стартап на хайпе, деньги реальные, архитектура собрана на коленке. Смотрю на архитектуру платёжного процессинга и первая мысль: ребята, вы серьёзно? Финансовые операции с реальными деньгами, без idempotency вообще, Redis как брокер без persistence, Web3.py синхронные вызовы внутри Celery тасков.

Разговор был короткий: задача такая, чини что есть. Сроки горели.

Меня зовут Александр Сахаров, я директор по партнерствам в компании Диасофт. И тезис, с которого начну, довольно дерзкий: старый айтишный треугольник «быстро, дешево, качественно, выберите два» в 2026 году можно закрывать. Правда, с одним условием, о котором почему-то  практически не говорят.

На днях мы собрались с коллегами обсудить мифы вокруг искусственного интеллекта. Поговорили про AGI и массовые увольнения из-за внедрения ИИ, но с определенной долей скепсиса. И вот почему. Дело в том, что по свежим данным 56 процентов CIO в мире за последний год не получили от ИИ ни роста выручки, ни снижения затрат. Удивлены?

Привет, Хабр!

На протяжении нескольких лет одной из наиболее популярных и важных книг в нашем арсенале остаётся книга Влада Хононова «Изучаем DDD предметно‑ориентированное проектирование». Мы регулярно контактируем с Владом и надеемся, что вскоре сможем опубликовать здесь и развёрнутое интервью с ним. А сегодня хотим предложить вам подробный и несколько критический обзор его книги, найденный в одном англоязычном блоге. Автор статьи не скрывает, что книга Влада не вполне подошла под конкретные задачи, которые автор надеялся с её помощью решить и упростить. Но при этом он настолько толково описывает саму парадигму, а также как именно и для каких целей её лучше использовать, что мы сочли её отличной и честной рекламой нашего бестселлера. Далее — авторский обзор от сеньора Факундо Оланы из Аргентины.

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

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

Рассмотрим модель данных application model, которая потребуется в дальнейшем изложении и которая используется в паттерне CQRS.

Реализация архитектурного паттерна CQRS, используемого в приложении для функционала application logic, представляет собой набор классов наследников базовых классов QueryHandler / CommandHandler и набор классов данных, которые являются наследниками базовых классов Query / Command. Классы наследники Query / Command представляют собой модель данных application logic. Такую модель данных логично назвать application model.

Используя application model и другие известные модели данных слоёв приложения можно построить полную схему моделей данных многослойной архитектуры приложения.

Всем привет. В последнее время в одной профессиональной соцсети я все чаще стал натыкаться на посты, связанные с dotnet C# тематикой. К сожалению, эти посты в большинстве своем не содержат полезной информации. Скорее всего они создаются для охвата аудитории с целью привлечения трафика на сторонние платформы по продаже курсов для разработчиков. По-моему, этот способ называется "воронка продаж" (поправьте, если я ошибаюсь). Как правило, эти посты затрагивают какую-то не очень сложную тему и содержат примеры кода. Недавно мне попался очередной пост, в котором автор пытался показать пример использования новой фичи labeled break and continue. Это новая фича, которую добавили в C# 15 (dotnet 11). На момент написания она была принята в Working Set, но финального релиза ещё не было. Ниже код, похожий на оригинал из поста. Он разделен на 2 секции: "как делали раньше" и "как сделать используя новый подход":

Стандартный способ:

Привет! Меня зовут Марк Каширский, я работаю DS-инженером в команде LLM Авито. Создаю инструменты для разработчиков, чтобы им было легче и удобнее работать. В статье рассказываю, как мы автоматизировали процесс Code review при помощи больших языковых моделей.

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

В какой-то момент у нас один платеж начал жить с тремя курсами валют: checkout показывал сумму из Redis, payment-service ходил в API, а ledger писал проводку по снапшоту из Postgres. Расхождения были 2-5 тенге, иногда до 180. Разбираю, как это дебажили, какие костыли ставили и где DDD реально помог, без красивых схем.

Друзья, написал текст как пародию на переводные бравурные статьи про Artemis. Улыбки ради.

Представьте, что в наше время попал материал, написанный в 2126 году к столетию полета Arthemis II.

Сто лет назад, в апреле 2026 года, Artemis II облетела Луну. Тогда это подавали как начало новой эпохи. Теперь, с расстояния в век, видно другое: именно тогда началась не новая лунная гонка в духе Apollo, а длинная эпоха согласований, комиссий, переходных интерфейсов, «полезных для бюджета» архитектур и превращения красивых схем в то, что хотя бы не разваливается на глазах.

На дворе 2126 год. Я инженер NASA, почти сорок лет отдавший детской мечте о полёте к звёздам. Не историк и даже не человек, заставший Apollo. Про ту эпоху я знаю из учебников, внутренних обзоров, старых страниц NASA, кусков документации, которые спасли не архивисты, а чужая лень, и по мемуарам старых астронавтов, для которых космос ещё был временем, когда можно было подъехать к стартовому комплексу на своём Corvette, надеть скафандр, сесть в кресло и улететь к звёздам. Нам после ранней Artemis досталось уже другое наследство. Его мы разгребали десятилетиями. Поэтому позвольте говорить не от лица пресс-службы, а языком человека, которому потом пришлось видеть архитектуру изнутри.

Один вопрос про pgx — и три инструмента которые легко перепутать. QueryTracer не замена декоратору, декоратор не устарел, а выбор драйвера — неожиданно важное решение для observability. Какую комбинацию драйвера и обёртки выбрать — зависит от того что вы хотите видеть. В статье взгляд на комбинации драйверов и оболочек для анализа запросов в PostgreSQL. Разбираем на реальном проекте — с кодом, ошибками и выводами.

Лучше один раз разобраться, чем каждый раз сомневаться в выборе.