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

Привет, Хабр! На связи Дмитрий Бондарев, я backend-разработчик Авито — занимаюсь проектами на стыке разработки и машинного обучения. В первой части этого материала мы обратились к истокам API и существующим ограничениям интерфейса в работе с агентами.

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

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

Для нас в QIC digital hub это особенно заметно на фоне миграции на новый Go-бэкенд. Исторически платформа развивалась на разнородном стеке: разные части системы были написаны на разных технологиях. Сейчас мы постепенно переезжаем на Go. Часть сервисов уже в проде, часть ещё на пути. Именно в такой момент легко создать новый слой техдолга поверх старого: переписать поведение на новом языке, но оставить команды один на один с десятками одинаковых инфраструктурных задач, которые каждая решает по-своему.

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

- go-kit — общая библиотека с переиспользуемыми инженерными решениями;

- go-service-template — шаблон, который делает эти решения стандартным способом запуска нового сервиса;

- shared-renovate-config — общий Renovate-конфиг с единой политикой обновления зависимостей для всех репозиториев.

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

Привет, Хабр! Говорит AvitoTech. Меня зовут Дмитрий Бондарев, я backend-разработчик, в Авито занимаюсь проектами на стыке разработки и машинного обучения. 

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

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

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

В этой статье разберём, как на ArchiMate 4.0 собрать первую рабочую модель предприятия с нуля — на примере интернет‑магазина, с понятной логикой доменов, связей и проверок, которые помогают не превратить диаграмму в клубок стрелок.

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

В стандартных клиентах, таких как v2rayN, используются специальные (geo) файлы, которые позволяют проксировать, блокировать трафик, а также пропускать его напрямую в зависимости от домена/IP адреса назначения. Пользователь @runetfreedomсоздал такие файлы для российских пользователей, за что ему большое спасибо. В теории, настроив маршрутизацию с этими файлами один раз, не нужно постоянно включать/выключать VPN или прокси при пользовании интернетом, так как клиент вроде v2rayN проксирует только заблокированные сайты. На практике же...

Делюсь опытом: собрал прод-агента на Claude для небольшой студии дизайна интерьера. Чат отвечает на Haiku 4.5, генератор концепций — на Sonnet 4.6, фото из Pexels вместо DALL-E. Без LangChain, без векторной базы, без RAG-фреймворка. Один файл main.py на 712 строк, два промпта. В статье разбираю развилки: почему именно так, на каких граблях постоял (порог кэша 4096 у Haiku, парсинг JSON-обёртки от Sonnet), где этот подход начнёт ломаться. Не «гайд от эксперта» — скорее дневник развилок.

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

Обычный летний день на проекте: ruff зелёный, mypy зелёный, тесты проходят. А domain при этом тихо импортирует adapters. Слоистая архитектура, которую рисовали на старте, теперь осталась только на схеме.

Линтер ловит неиспользуемый импорт и кривой отступ. Типизатор - что вместо int передали str. А то, что бизнес-логика потащила в себя SQLAlchemy или Redis, не видит никто. Кроме ревьюера, у которого в пятницу вечером открыто восемь PR.

Ниже - как отдать эту проверку машине. Инструмент называется import-linter, ставится за пять минут и встаёт в один ряд с ruff и mypy.

Вайб-кодер в чистой форме — человек, который вообще не имеет отношения к разработке — физически не способен оценить код. Для него работает = работает. А я утверждаю: код, сгенерированный нейронкой, всё равно будет более плоским, более ущербным и менее оптимальным, чем код живого разработчика. Проблема в том, как это доказать человеку, который код читать не умеет. Поэтому зайдём через аналогию, которую может проверить КАЖДЫЙ — через тексты.

Луковичную (onion) архитектуру обычно продают аргументом «легко поменять БД или фреймворк». Только базу в проде меняют раз в пятилетку, а чаще вообще не меняют — ради этого городить слои не выгодно.

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

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

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

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

Для начала вспомним что такое средовой подход и чем он отличается от системного

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

Но со временем появляются новые вопросы. Команде становится недостаточно просто посчитать количество записей или получить текущее состояние объекта. Хочется понять, что происходило в системе: какие события привели к изменению состояния, какие действия выполнялись, где возникла проблема и на каком этапе произошёл сбой.

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

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

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

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

Меня зовут Александр Козуб, в симптомах вижу систему, об этом и пишу. Ранее я уже разбирал, как лучшие практики сужают рамку продакта, и собирал методики оценки пользователя в одну систему. Сегодня про метрики.

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

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

Недавно в интернете начал работу сервис рефакторинга Malus.sh по «очистке кода от опенсорсных лицензий». Он позиционирует себя как «чистая комната», где софт очищается от лицензионного бремени. Туда загружается манифест свободного проекта, а LLM за небольшую плату переписывает код с сохранением функциональности. Идея в том, что новый код можно использовать как угодно, без соблюдения требований свободных лицензий APGL, MIT, Apache и др., под которыми опубликован оригинал.

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

За последний месяц я насчитал минимум семь свежих статей с заголовком в духе "Playwright быстрее Selenium на N%". Проблема в том, что N у всех разный: 23%, 42%, 63%, "1.85x". Методология почти нигде не раскрыта дальше фразы "controlled environment". Для решения, которое определяет CI-бюджет и архитектуру тестов на годы вперёд, это не цифры — это шум.

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

Я изучил записные книжки шести писателей-классиков и обнаружил, что ни один из них не вёл "систему управления знаниями". Их тетради были хаотичны, а сам подход не навязывал структуру. В результате исследования я сделал свою полноценную "тетрадь писателя" на Go в 3253 строки с нулём фреймворков и минимумом зависимостей.

Под катом — пространное эссе о том, почему "удобно" и "просто" — разные вещи.

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

Лет двенадцать назад создание большого монолита было обычной практикой. Семь лет назад многие подсели на микросервисную архитектуру. Причем микросервисами часто называли все подряд: и сервисно-ориентированный подход (SOA), и набор крупных сервисов, и распределенный монолит. Главное было быть в тренде.

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

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

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