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

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

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

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

Когда у вас появляется продукт с активными процессами и большим количеством пользователей, объём данных начинает расти быстрее, чем ожидалось. На старте всё выглядит достаточно просто: есть 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 как основного автора кода.

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

Вступление: Финал эксперимента и ответ скептикам. Как мы с ИИ написали Open-Source убийцу SaaS-ботов на 280 000 строк кода, и почему я отдаю его даром.

В своих прошлых статьях я рассказывал, как научился использовать ИИ вместо команды сеньоров («Почему для одних ИИ — гений, а для других — идиот») и почему классическая команда сегодня только тормозит разработку из-за бюрократии и потери контекста («Парадокс инвестиций: Почему $1,000,000 и команда сеньоров убили бы мой стартап»).

В комментариях на меня вылили ушат холодного и вполне обоснованного скепсиса. Мне писали: «Где метрики? Кому нужен твой пет-проект?».

И знаете что? Вы абсолютно правы. ©

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

Вначале, наверное, каждый попадал в эту ловушку на собеседовании: кандидат открывает экран, уверенно запускает draw.io и бодро начинает рисовать. Бац — микросервисы! Бац — брокеры сообщений между ними! Redis-кеш сверху, базы данных снизу. Даже стрелки вызовов нарисованы в правильном стиле. Интервьюер кивает, видя техническую беглость. Кандидат чувствует уверенность, ждёт похвалы.

— Отлично, — говорит интервьюер, — а откуда берутся данные для этого отчёта? 

Кандидат на секунду замешкается. «Откуда?.. Ах да, из базы данных, наверное... или из очереди?..» Он смотрит на схему, где слева — пустое место перед микросервисами.

— И кто потребитель этого события? — продолжает интервьюер. — Кто его забирает и что делает с результатом?

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

Проблема не в отсутствии знаний, а в отсутствии целостной картины.

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

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

Сколько раз вы реально меняли базу под приложением? Generic Repository – первое, что тащат в проект, и последнее, в чём сомневаются, – держат ровно ради этого. У меня за карьеру смена базы случилась дважды, и оба раза репозиторий полетел в корзину вместе со всем слоем. Это лишь первое из трёх обещаний, которое он не сдержал, а по дороге тихо забрал доменную модель. Как именно – на реальном кейсе с Mongo, и чем мы его заменили.

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

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

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

Собственно, давайте с DNA и начнём.

Заходят как-то две машины Тьюринга в одну диаграмму… а у них имена одинаковые.

Я говорю «машины», а на деле — два разных экземпляра State @turing-machine-js/machine, сконструированные по-разному, с разным поведением во время исполнения, и со строго одинаковым state.name. Это происходило в библиотеке, которую я разрабатываю в качестве хобби с 2019 года, и я этого не замечал семь лет.

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

Инкапсуляцию и наследование часто преподносят как две неотъемлемые опоры объектно-ориентированного программирования, однако на деле между ними существует глубокое внутреннее противоречие. Статья Алана Снайдера, опубликованная по итогам его выступления на OOPSLA’86, стала одним из первых программных текстов, вскрывших эту проблему на уровне языковых конструкций, и показала, как неаккуратно реализованное наследование способно разрушить инкапсуляцию, а вместе с ней — преимущества модульного проектирования. Работа во многом предопределила дальнейшие дискуссии о хрупком базовом классе, роли контрактов между классами и их потомками и о том, каким должен быть внешний интерфейс класса в условиях наследования.

В своей программной статье, опубликованной по итогам выступления на OOPSLA '89, Ребекка Вирфс-Брок и Брайан Уилкерсон излагают основы ответственностно-ориентированного подхода. Отталкиваясь от модели клиент/сервер и идеи контракта, авторы показывают, что концентрация на поведении и ответственностях, а не на структуре данных, позволяет максимально раскрыть потенциал инкапсуляции, делая систему более гибкой и устойчивой к изменениям.

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

Под внешним периметром обычно понимают всё, что доступно из интернета: публичные IP-адреса, домены, поддомены, облачные или VPS-серверы, а также сервисы, которые слушают внешние порты.

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

В первой части я показал, как ИИ из «уверенного галлюцинатора» превращается в управляемого исполнителя: разбор задания перед генерацией, три специализированных агента (R2-PLCGen, Agents4PLC, truST Platform), проверка кода в программном симуляторе (Tier S) и в настоящем компиляторе matiec (Tier H), детерминированный ремонт типовых ошибок и финальное слово всегда за инженером.

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

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

Многие разработчики механически переносят архитектурные привычки из строго типизированных языков в Python, создавая переусложненный неидиоматичный код. В этой статье мы возьмем классические правила SOLID и переведем их на язык динамической типизации (Pythonic way). Разберем на реальных примерах, где принципы спасают проект, а где слепое следование им скатывается в карго-культ.