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

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

Что считаем техдолгом

Чтобы посчитать ROI рефакторинга, сначала нужно определить, что именно команда считает техническим долгом. Без этого в один список попадут баги, старые библиотеки, слабые тесты или желание сменить стек. У таких задач разные причины, цена и источники бюджета, поэтому их нельзя приоритизировать как одну категорию.

Термин «технический долг» ввёл программист Уорд Каннингем в 1992 году. Он использовал финансовую метафору: команда может выбрать более быстрое техническое решение, получить выгоду сейчас, а позже заплатить за это доработкой и дополнительными расходами.

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

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

1. Баг — это ошибка в реализации. Техдолга здесь нет: никто не принимал осознанного решения сделать хуже. Поэтому баги относятся к дефект-менеджменту и финансируются из бюджета на поддержку, а не из бюджета на рефакторинг.
2. Желание применить новую технологию — это новое требование к продукту. Команда хочет заменить PostgreSQL на что-то другое или перейти с REST на gRPC. Если это обосновано и полезно — отлично, но это отдельная задача со своей оценкой и своим источником финансирования.
3. Устаревший код без измеримых последствий — тоже не долг. Если модуль написан пять лет назад, но команда работает с ним без дополнительных затрат времени, он никого не тормозит и не создаёт рисков — переписывать его ради переписывания не нужно. Техдолг возникает в момент, когда команда признаёт: вот это решение замедляет нас, и мы можем точно сказать, как именно.

У каждой категории своя логика и бюджет. Баги относятся к дефект-менеджменту, новые технологии — к развитию продукта, обучение — к развитию команды. Если всё сложить в один бэклог и назвать техдолгом, ресурсы будут расходоваться непрозрачно, а разговор с бизнесом снова сведётся к просьбе выделить время на внутренние задачи.

Как техдолг превращается в расходы

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

Объём работ — это всё, что нужно сделать, чтобы вернуться в целевое состояние. Раздробить монолитный модуль, заменить самописную библиотеку на поддерживаемую, переписать слой работы с БД. Объём работ оценивается в часах или стори-поинтах — это конечная сумма, которую команда выплатит один раз.

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

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

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

Какие задачи по техдолгу считать через ROI

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

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

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

Отдельно стоят системные решения — их нельзя решать на уровне одного спринта. Для них нужна отдельная оценка, архитектурное решение и согласование с бизнесом. Например:

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

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

Где искать расходы в легаси перед расчётом ROI

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

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

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

Как считать ROI

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

Шаг 1. Посчитайте текущие потери. Зафиксируйте, сколько дополнительного времени команда тратит из-за конкретной проблемы прямо сейчас. Медленная сборка — сколько минут в день суммарно по команде. Сложный для понимания модуль — сколько часов уходит на оценку задач в нём. Отсутствие тестов — сколько времени занимает ручная проверка перед каждым релизом. Переведите это в деньги через стоимость часа работы команды.

Шаг 2. Оцените объём работ. Сколько займёт исправление — в часах, с буфером на непредвиденное. Это тоже деньги: стоимость часа умножить на объём.

Шаг 3. Посчитайте горизонт окупаемости. Если текущие потери составляют 20 000 рублей в неделю, а объём работ стоит 80 000 рублей, рефакторинг окупается за четыре недели. Дальше каждая неделя — чистая экономия. Если горизонт окупаемости укладывается в срок, на который планируется развитие продукта, рефакторинг финансово обоснован.

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

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

Как обосновать рефакторинг бизнесу

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

Аргумент «там плохой код» не работает, потому что для бизнеса это не проблема — проблема это замедление или остановка поставки фич. Поэтому аргументы должны быть на том же языке.

1. Скорость поставки. Покажите данные из трекера: сколько времени уходило на задачи в конкретном модуле полгода назад и сколько уходит сейчас. Если время выросло в полтора раза при сопоставимой сложности задач, это измеримое замедление с понятной причиной.
2. Предсказуемость оценок. Команда с накопленным техдолгом не может точно эстимировать: задача на три дня превращается в две недели, потому что в процессе обнаруживаются связанные проблемы. Для бизнеса это означает срыв сроков и невозможность планировать релизы. Покажите расхождение между оценками и фактом за последние несколько спринтов.
3. Риски. Неподдерживаемые зависимости, отсутствие покрытия тестами на критических участках, архитектура, которая не выдержит роста нагрузки при следующем масштабировании. Риски переводятся в деньги через вероятность и стоимость инцидента.

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

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

Итого

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

По факту, это обычное инженерно-финансовое решение: либо команда закрывает объём долга сейчас, либо продолжает оплачивать его через более дорогие фичи, поддержку, регресс и риски в проде.

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

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

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

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

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

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

Через восемь месяцев проект всё ещё не был готов к выкатке, а к десятому месяцу команда откатила миграцию полностью. Причин было несколько.

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

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

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

Представим старый монолит интернет-магазина. Внутри него есть каталог, корзина, заказы, платежи, скидки, личный кабинет и уведомления. Переписать всё сразу — рискованно. Но можно начать с относительно изолированного участка, например с уведомлений.

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

Feature toggles, или фича-флаги, — один из главных инструментов безопасной миграции. Они позволяют включать и выключать новую логику без деплоя.

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

Последний пункт особенно важен. Если флаги не удалять, система быстро превращается в набор ветвлений, где никто уже не понимает, какая логика актуальна.

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

Для критичной доменной логики — платежей, биллинга, расчета тарифов — допустимый уровень расхождения должен быть около нуля: цель в shadow-режиме не «как можно меньше различий», а «понимаем каждое расхождение». Для менее чувствительных доменов (рекомендации, ранжирование результатов поиска) можно жить с расхождением в долях процента, но и там расхождения нужно классифицировать, а не игнорировать. Возможно, это баги новой реализации. А возможно, старая система содержит устаревшую логику, которую нужно отдельно обсудить с бизнесом.

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

Технических метрик недостаточно. Если команда переносит оформление заказа, важно смотреть не только на 500 ошибки и время ответа, но и на конверсию в оплату, количество брошенных корзин, повторы запросов, обращения в поддержку.

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

Откатить миграцию, в которой ещё не было записи в БД, легко: достаточно переключить фича-флаг, и трафик снова идёт через старую реализацию. Откатить миграцию, в которой новая система уже неделю писала данные в новые таблицы, — отдельный, гораздо более тяжёлый разговор.

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

Базовое правило: ни один шаг миграции не должен уходить в продакшен, если у команды нет письменного ответа на вопрос «как мы откатываемся в случае проблемы». Иначе при инциденте откатываться будут на ходу — и не факт, что успешно.

Пример: как тот же сервис мигрировали со второй попытки

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

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

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

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

Четвертая ошибка — не договариваться с бизнесом. Модернизация не должна быть невидимой «инженерной активностью в стол». Её нужно встраивать в roadmap, объяснять эффект и договариваться о приоритетах. Если бизнес не понимает, зачем команда тратит время на миграцию, работа будет постоянно проигрывать новым фичам.

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

Отдельно стоит упомянуть организационную сторону. Закон Конвея работает и в обратную сторону: если новый и старый код владеются разными командами с разными приоритетами, миграция будет тормозиться независимо от выбранного паттерна. На время миграции имеет смысл явно проговорить, кто отвечает за переход, и не разделять старую и новую реализации между несовместимыми roadmap’ами.

Компромиссы, к которым нужно быть готовыми

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

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

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

Когда Strangler Fig особенно оправдан

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

Если продуктом ежедневно пользуются сотни тысяч или миллионы людей, нельзя позволить себе «переписать и посмотреть, что будет». Нужно менять архитектуру так, чтобы пользователь не замечал процесса миграции.

Этот подход также полезен там, где бизнес продолжает активно развивать продукт. Если фичи нельзя заморозить на полгода, модернизация должна идти параллельно с продуктовой разработкой.

Когда модернизацию лучше не делать

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

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

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

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

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

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

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

Потому что цель модернизации — не написать красивую новую систему. Цель — сделать так, чтобы продукт продолжал развиваться, команда могла безопасно вносить изменения, а пользователи не становились участниками инженерного эксперимента.

TSC (Time Stamp Counter) — это высокоточный счётчик тактов процессора, появившийся ещё во времена Intel Pentium. Он позволяет ядру измерять время с минимальными накладными расходами и используется в задачах от профилирования до планирования процессов.

Ранее код ядра содержал альтернативные пути для систем без TSC, поскольку поддержка распространялась на процессоры i486 и другие старые чипы, где счётчик отсутствовал. Теперь, когда эти архаичные платформы исключены из кодовой базы, мейнтейнеры подготовили патч, который делает TSC обязательным через систему конфигурации ядра (Kconfig).

Параллельно из ядра вырежут альтернативные ветви кода без TSC: лишние проверки и резервные реализации уйдут, что упростит кодовую базу.

Ядро Linux готовится сделать TSC безусловным требованием для x86-процессоров.

Решение стало возможно благодаря снятию поддержки устаревших чипов: Intel 486, AMD K5 и AMD Elan.

Патч уже находится в подготовительной ветке ядра и ожидается в цикле разработки Linux 7.2.

Удаление альтернативных ветвей кода упростит кодовую базу.

Что изменится для x86-процессоров в Linux

Для современного железа — ничего: все актуальные x86-процессоры (от Intel Core и Xeon до AMD Ryzen и EPYC) давно имеют TSC. Изменение затронет только разработчиков, которые всё ещё собирают ядро для ретро-совместимости.

Поддержка Intel 486 держалась в ядре десятилетиями из-за принципа максимальной совместимости, но в 2025–2026 годах мейнтейнеры начали массовую чистку legacy-кода. Удаление non-TSC путей — логичное продолжение этого процесса: раз чипов без счётчика больше не поддерживают, зачем тащить обходные механизмы?

Выводы

Отказ от альтернативных ветвей кода без TSC — ещё один шаг к чистке legacy-кода в Linux. Упрощение архитектуры x86-платформы ускорит дальнейшую разработку ядра и снизит нагрузку на мейнтейнеров, которые больше не будут тестировать редкие конфигурации без счётчика тактов.

Источник: Phoronix

Мы перевели статью FinnKuhn. Далее — от первого лица.

Контекст

Я работаю над Pizza Legacy — опенсорсной реимплементацией DOS-игры 1994 года Pizza Tycoon. В игре есть режим крупного плана: когда прокручиваешь карту, видишь постоянный поток машин на улицах. Одновременно — штук двадцать-тридцать маленьких спрайтов, но они ездят по сетке улиц, выстраиваются в очередь на перекрёстках и в целом создают ощущение живого города. Иногда они проезжали сквозь друг друга — был такой баг, — но этого хватало, чтобы карта выглядела населённой. И всё это крутилось на 386-м процессоре на 25 МГц.

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

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

И всё это время в голове сидела одна мысль: оригинальный Pizza Tycoon крутил эту симуляцию на 25 МГц. Почему у меня реализации всегда получались такими сложными?

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

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

Как устроены города

Сначала посмотрим, из чего вообще состоит город. Видно двухполосные дороги, T-перекрёстки, четырёхсторонние перекрёстки и углы. Карты в Pizza Tycoon — это сетка 160×120 тайлов, где каждый тайл берётся из файла landsym.vga.

Дорожная система

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

Тайл 0x16 — это нижняя часть горизонтальной дороги, то есть машины здесь могут ехать только слева направо. Соответственно, 0x06 — справа налево, а 0x26 и 0x36 — то же самое, но для вертикального движения.

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

С углами та же история. 0x56 (CORNER_SW в моём enum) — это угол, на котором машина может либо ехать дальше на запад, либо повернуть на юг. Когда машина доезжает до угла, она подбрасывает монетку: 50% — едет прямо, 50% — поворачивает. Карты спроектированы так, чтобы дорожная сеть всегда оставалась согласованной: рядом с CORNER_SW обязательно стоит либо тайл с движением с юга на север (то есть машине придётся свернуть на юг), либо ещё один угловой тайл, который тоже допускает и поворот, и проезд прямо.

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

Движение: один пиксель за такт

Машины двигаются на один пиксель за такт игрового цикла. На каждом такте главный цикл проверяет, не заблокирована ли машина, и если нет — прибавляет или вычитает один пиксель у её экранной координаты в зависимости от направления. Восток: +1 к X. Север: −1 к Y. Никакой векторной математики.

Есть второй счётчик — progress, который идёт от 16 к 1. Когда он доходит до нуля — сбрасывается в 16, и игра запускает тайловую логику: смотрит, какой там следующий тайл, решает новое направление, обновляет кадр спрайта (чтобы визуально развернуть машину в новую сторону).

Поскольку каждый тайл имеет размер 16×16 пикселей, тайловая логика срабатывает ровно один раз на пересечение тайла. Движение на один пиксель — каждый такт, тяжёлая тайловая логика — только в 1 из 16 тактов.

Когда машина только спавнится, progress устанавливается в случайное значение от 1 до 16. Это разносит проверки границ тайлов между разными тактами, так что нагрузка размазывается равномерно — примерно 25 машин не упираются в тайловую логику одновременно.

Обнаружение столкновений: дешёвый O(n²)

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

Но код обнаружения столкновений написан так, чтобы выходить из проверки как можно раньше. Первое, что он делает, — извлекает направление второй машины. А так как дороги односторонние, восточная и западная машины в принципе не могут оказаться на одной дороге. Значит, такая пара возвращается мгновенно, даже не читая координат. То же самое для пар «восток — юг», «запад — север» и так далее.

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

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

Спавн машин

Когда игрок входит в режим крупного плана, игра сканирует все 132 тайла видимой области (12 столбцов × 11 строк) и для каждого дорожного тайла кидает кубик против плотности трафика района, чтобы решить, спавнить ли там машину. Районы с высокой плотностью получаются загруженнее, с низкой — пустыми. Угловые тайлы из точек спавна исключены: машины появляются только на прямых участках.

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

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

Почему это работает

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

• Машинам не нужен поиск пути — карта сама говорит им, куда можно ехать.
• Обнаружение столкновений дешёвое, потому что ранний выход по направлению делает большинство пар практически бесплатными.
• Нет скорости и физики — один пиксель за такт выглядит достаточно убедительно.
• Если врезался — просто подожди 10 тактов. А если надо повернуть — просто проехал половину тайла и повернул. Работает на любом тайле в любом направлении.

Прежде чем тащить в свой проект поиск пути и граф сцены, стоит спросить себя: сколько у меня реально сущностей на экране? Какие ограничения у домена? Маленький экран, односторонние дороги, двадцать пять объектов — всё это аргументы за тривиальный алгоритм, а не за универсальный движок.

Я переписал систему довольно близко к ассемблеру оригинала — по сути, пара switch-блоков с разными вариантами маршрутизации в зависимости от типа тайла. Код можно посмотреть в методе decide_desired_direction в Car.cpp репозитория проекта.

• Intel 386 25 МГц (1994), карта 160×120 тайлов, каждый тайл 16×16 пикселей, видимая область 12×11
• Направление зашито в тип тайла (0x16, 0x06, 0x26, 0x36) — машинам не нужен поиск пути, они просто читают тип клетки под собой
• 625 попарных проверок за такт (при ~25 машинах) — но большинство возвращается после нескольких инструкций за счёт раннего выхода по направлению
• Один пиксель за такт + счётчик 16→1 разносит тяжёлую тайловую логику между тактами, нагрузка размазывается равномерно
• Главный урок: встроенные ограничения домена (односторонние дороги, маленький экран, заранее известные маршруты) дают такие упрощения, о которых современный разработчик просто не подумает

Источник: «How Pizza Tycoon simulated traffic on a 25 MHz CPU» — блог Pizza Legacy. Публикуется с разрешения автора в рамках открытого проекта.

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

Что делает Code Wiki

Сервис сканирует весь репозиторий, строит структурированную wiki-документацию и перегенерирует ее после каждого коммита.

Таким образом, мы получаем не просто статичный README и не набор заметок. Локальная «Википедия по проекту» остается синхронизированной с кодовой базой всегда. Google подчеркивает несколько ключевых возможностей:

• Автоматическая документация. Code Wiki описывает архитектуру, модули, классы, функции. Причем делает это регулярно, без участия разработчика.
• Глубокий контекст. Встроенный чат на базе Gemini использует сгенерированную wiki как базу знаний. В итоге мы получаем не «общий» ИИ, а агента, который знает репозиторий целиком.
• Навигация по коду. Все элементы документации связаны гиперссылками с исходниками — можно сразу перейти от объяснения к конкретной строчке реализации.
• Диаграммы. Сервис автоматически рисует актуальные архитектурные, sequence- и class-диаграммы, которые меняются вместе с кодом.

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

Что дальше

Пока Code Wiki работает только с публичными проектами. Но Google уже делает CLI-расширение для Gemini, которое позволит генерировать документацию для закрытых, внутренних кодовых баз — локально и без передачи данных в облако.

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

Зачем все это

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

Code Wiki должен закрыть этот пробел и превратить понимание кода в операцию, которая занимает минуты. Сервис уже работает в виде публичного превью на codewiki.google.

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

1. ТРИАДА: разработка и поддержка проектов в горящие сроки

Компания ТРИАДА работает с высоконагруженными e-commerce проектами, корпоративными порталами, CRM-системами и мобильными приложениями с 2006 года — реализовали более 200 проектов для банков, страховых компаний, промышленных предприятий.

Специализация — поддержка legacy-кода и запуск проектов в условиях жестких сроков, когда другие подрядчики не справились.

Что делают

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

Полный цикл разработки включает:

• тщательный анализ требований
• проектирование архитектуры
• создание продуманного UI/UX-дизайна
• разработку
• тестирование

После запуска обеспечивают проактивный мониторинг 24/7 с мгновенными оповещениями в Telegram и Mattermost. Система мониторинга обнаруживает потенциальные сбои до того, как они станут заметны пользователям.

Для удобства клиентов предлагают гибкие форматы оплаты: фиксированная ставка, «Time & Materials» или постоплата с отсрочкой.

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

Примеры проектов

1. Крупнейших интернет-магазин по версии Data Insight

Обеспечили стабильную работу одного из крупнейших интернет-магазинов России с нагрузкой 1 млн посетителей в сутки. Интеллектуальная система балансировки дает скорость ответа 0,01 сек для гостей и персональную выдачу для авторизованных пользователей.

Команда из 30 экспертов внедрила строгую стандартизацию процессов и бесшовно интегрировала 20+ внешних систем. Результат: проект 4 года в топе Data Insight с бесперебойной работой и премиальным пользовательским опытом.

2. CRM для металлургического холдинга — импортозамещение за 3 месяца

За 90 дней перенесли 5-летнюю кастомизацию американской CRM на Битрикс24. Команда из 8 специалистов сохранила всю бизнес-логику и улучшила процессы.

Реализовали безопасную синхронизацию между CRM в закрытом контуре без интернета, интегрировали SAP, развернули СЭД, чат-боты и BI-аналитику. Холдинг получил полную цифровую экосистему под российским контролем.

3. Корпоративный портал для цифровой трансформации завода

Команда из 7 специалистов за год создала портал с системой навигации по бизнес-процессам. Реализован BPMN-редактор с версионностью и согласованиями, объединено управление проектами, клиентским сервисом и документооборотом. Настроена интеграция с 1С и другими корпоративными системами.

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

Как работают

Методология по Agile, Scrum, Prince2 — в зависимости от процессов заказчика или предлагают собственные. Участвуют в митингах клиента, планировании спринтов, демо результатов. Команда доступна как in-house сотрудники, предоставляют прозрачные отчёты по времени в срезах задач и сотрудников.

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

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

Выстраивают DevOps-культуру с CI/CD-конвейером через Gitlab CI/CD, Jenkins — новые функции доставляются быстрее и чаще с минимальными рисками. Контейнерная архитектура на Docker, Kubernetes, Docker Swarm.

Поддержка и мониторинг

На серверах разворачивают систему мониторинга производительности, доступности и безопасности. Она отслеживает нагрузку CPU и RAM, работу Apache и Memcached, статус SSL‑сертификатов и бэкапов. Все показатели собраны в дашборде «Рабочий стол проекта».

При превышении допустимых параметров, например загрузке CPU свыше 80% более 5 минут, система автоматически отправляет уведомление специалистам с графиками метрик для быстрой диагностики. Время реакции и устранения инцидентов регламентировано SLA, а контроль круглосуточный.

Технологии

Команда работает с любыми технологиями: от PHP (Symfony, Laravel, Yii) и GO до современных фреймворков ReactJS и VueJS. Специалисты разбираются в legacy-коде и самописных движках. Мобильная разработка на Swift, Kotlin, знают ObjC и Java.

Ключевое преимущество — опыт интеграций с CRM (Битрикс24, AmoCRM, Salesforce), ERP (SAP, 1C), CDP, программами лояльности, логистическими сервисами, эквайрингом. Одними из первых в России построили сквозную BI-аналитику

2. fuse8 — полный цикл от гипотезы до продакшена

fuse8 — агентство, которая специализируется на комплексной разработке цифровых продуктов с акцентом на современные технологии. Работают по схеме «от идеи до масштабирования»: сначала проектирование с фиксацией целей и метрик, затем разработка короткими спринтами, после — поддержка и развитие.

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

Что делают

• Запускают новые продукты с нуля
• Модернизируют существующие системы
• Собирают выделенные команды под экосистему заказчика
• Интегрируют платёжные системы, маркетплейсы, CRM и ERP — исключая привязку к коробочным решениям вроде 1С и Битрикс
• Реализуют API и SDK под конкретные задачи продукта

В проектах используют TypeScript, React, Next.js, Nest.js, Node.js и .NET.

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

Как работают

Процесс разбит на три этапа.

1 Этап. Проектирование занимает 5 недель: исследуют аудиторию, фиксируют метрики, описывают сценарии и интеграции, собирают user story map, приоритезируют MVP и готовят роадмап с первыми прототипами. Выбирают стек под экосистему и команду заказчика на этом же этапе.​

2 Этап. Разработка идет короткими спринтами с регулярными демо. Если проект с фиксированным бюджетом и сроками, управляют скопом через FFF (фиксированная цена, объем и бюджет), сохраняя качество MVP (подробнее — в статье). Заказчик погружен в процесс и видит артефакты на каждом шаге.​

3 Этап. После запуска настраивают наблюдаемость — метрики, логирование, мониторинг производительности. Планируют бэклог гипотез для развития продукта. Средний срок сотрудничества с клиентами — больше четырех лет.​

Примеры проектов

• FF Manager — платформа для молодежной футбольной лиги в Казахстане. База упражнений, планирование тренировок, оценка эффективности — все в одном интерфейсе. Проект получил награды G8, WDA и Tagline Awards. От идеи до первых дизайнов, роадмапа и выбора стека ушло 5 недель.​

• Личный кабинет поставщика для EMEX — автоматизация процессов, которые тормозили развитие продукта. Унифицировали стек, ускорили выпуск версий, повысили отказоустойчивость системы. Проект взял золото и серебро на Tagline Awards. До этого провели технический аудит портала, который не обновлялся 7 лет, и спроектировали новую архитектуру за 5 недель.​

• Платформа для the Open — британский гольф-турнир с миллионами активных пользователей. Переработали устаревшее решение в highload-систему, которая выдержала нагрузку при десяти миллионах одновременных сессий. Билеты на турнир разошлись за 40 дней — рекорд для мероприятия.
• ERP для бизнеса по взысканию долгов — индивидуальная система на .NET. Автоматизировали 80% ручного труда сотрудников, эффективность отдела выросла на 20% после запуска первой версии. Снизили регуляторные риски за счет автоматической генерации отчетов. Бронза Tagline Awards в категории финтех-проектов.​
• Сервис онлайн-займов — начали работу с продуктом на этапе идеи стартапа и вместе с командой заказчика довели его до позиций лидера рынка. После запуска первой версии наращивали функциональность и развивали систему несколько лет.
• Веб-платформа для Crystal Palace — фанатский сервис футбольного клуба. Расходы на серверные мощности сократили в 10 раз, доход от продажи членства вырос на 40%, количество веб-сессий увеличилось на 78%.​

• Сайт Уралпромбанк — переработали структуру главной, логику каталога продуктов, оптимизировали анкеты-заявки. Раскрытие информации о деятельности банка для акционеров и регуляторов стало полнее и удобнее. Бронза Tagline Awards в категории сайтов-сервисов.​
• Складская система для EMEX — интерфейсы для десктопа и портативных устройств, автоматизация всех сценариев работы складских сотрудников. Интеграция с остальными системами компании для непрерывного логистического процесса.​

Для кого подходит

Агентство предлагает не разрозненные технологические ресурсы, а сработанную команду с отраслевым опытом под интересы заказчика.

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

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

3. Бестранк: автоматизация как сервис

Агентство Бестранк специализируется на цифровизации внутренних процессов среднего бизнеса — автоматизируют согласование договоров, интегрируют ИИ‑агентов и CRM, сопровождают проекты длительное время, по формату максимально близки к внутреннему IT-отделу.

Чем занимается агентство

Ключевые направления — автоматизация бизнес-процессов, создание и поддержка внутренних порталов, модулей для Bitrix24, интеграция нейросетей и запуск ИИ‑ассистентов. Форматы — разработка «под ключ», долгосрочное сопровождение, быстрый старт и мягкая адаптация решений под уже работающие системы, доработка и развитие существующих платформ.

Частые задачи: настройка CRM, автоматизация сбора и согласования данных, организация электронного документооборота, интеграция ИИ‑агентов для сокращения рутины, связка между корпоративными и государственными системами.

Кейсы и сценарии

• Автоматизация согласования договоров в ГК Симметрон. Проект делился на четыре этапа, внедрение происходило итерациями. Итог — стабильная работа процесса уже четыре года: ежедневно автоматизировано согласование до 10 документов.
• Автоматизация заполнения карточек компании в CRM. Приходит новый запрос — система автоматом извлекает e‑mail, подтягивает ИНН, ОГРН, адрес, численность сотрудников, ОКВЭД, сайт. С помощью нейросетей анализируется содержимое сайта, уточняется сфера деятельности и основные направления. Все заносится в CRM без ручного ввода.

Особенности подхода

Используют продуктовый подход: вместе с клиентом строят дорожную карту развития цифровой экосистемы — CRM, портала или ИИ-решений. Агентство нацелено на долгосрочные отношения, предпочитает клиентов с планами роста на 3+ года и заключает годовые, полугодовые контракты (100 часов в месяц по фиксированной цене). Работают по модели гибкой смены приоритетов: если бизнес меняет задачи, план переустраивается без дополнительных сложностей — близко по духу к внутреннему IT-отделу, но экономичнее.

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

Технологические детали

В качестве базы — Bitrix24 и доработки для нее: собственные модули, сценарии, инструменты внедрения ИИ‑функций. Активно используют интеграции с Yandex.GPT, а также типовые и кастомные решения для синхронизации с корпоративными CRM, ERP, внешними API, платёжными и информационными сервисами.

Управление проектом и поддержка

Взаимодействуют через сервисы Bitrix24: если клиент использует аналогичный портал, настраивают автоматический обмен задачами между площадками. Если у клиента другая система — подстраиваются под существующий таск-трекер. Взаимодействие строится гибко: ключевое — прозрачность обмена задачами, отчетность, доступ к процессу работы. Работа с поддержкой включает технические работы, SLA и оперативную доработку, ориентированную на потребности бизнеса.

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

4. WaiWai: ИИ-агенты, которые говорят на языке бизнеса

Команда WaiWai разрабатывает и внедряет и AI‑агентов для продаж и рекрутмента. Компания помогает среднему и крупному бизнесу автоматизировать поиск лидов и коммуникацию с потенциальными клиентами.

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

Чем занимается агентство

WaiWai работает под ключ — от настройки среды и целей до развертывания готовой AI‑системы в продуктиве. Основное направление — разработка AI‑агентов для продаж и рекрутмента. Агентство создаёт кастомные интеграции с корпоративными CRM и маркетплейсами, разворачивает модели в контуре компании и обеспечивает техническое сопровождение.

Кейсы и сценарии

• АК Барс Банк — AI‑агент для рекрутмента. Система подключается к HeadHunter и другим площадкам, оценивает не только резюме, но и карьерный путь кандидатов, формирует персональные обращения. Благодаря этому автоматизируются массовые вакансии с тысячами откликов. Результат — 61% сокращение срока закрытия вакансий, 48% высвобожденного времени рекрутеров. Проект получил премию «AI Олимп» в номинации «Новая цифровая идея года».

• Falcone — AI‑агент для продаж услуг доставки. После внедрения отклик клиентов вырос в 5,7 раза, а продажи — на 21%. Оборот компании удвоился, Falcone стал резидентом «Сколково» благодаря интеграции ИИ‑решений.

• Конференции Онтико — AI‑агент для продажи билетов. Агент подбирал разработчиков по профессиональным интересам и истории участия в мероприятиях, коммуницировал через Linkedin и email. Конверсия выросла в 2,4 раза.

Подход к работе

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

Решения развертываются безопасно, с изоляцией данных внутри инфраструктуры клиента. Для тестирования есть собственные SDK, IDE и Playground — среда, где заказчик может проверять сценарии AI‑агентов без риска утечек.

Технологическая база

WaiWai разворачивает LLM‑модели семейства Qwen и Gemma внутри инфраструктуры клиента, добиваясь безопасной работы с внутренними данными. Модели адаптированы к российскому контексту и требованиям 152‑ФЗ. Компания входит в «Сколково», Реестр отечественного ПО и реестр МТК.

Архитектура решений поддерживает интеграции с CRM, ERP и внешними API, а также подключение платёжных систем и marketplace‑функционала.

Управление и поддержка

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

5. Beavers Brothers: от брендинга до высоконагруженных игр

Beavers Brothers работает с комплексными проектами — разрабатывает фирменный стиль, сайты, личные кабинеты, веб-игры и делает дизайн-поддержку для IT-компаний и финансового сектора.

Среди клиентов — Microsoft, SAP, Schneider Electric, Яндекс, Лаборатория Касперского, 1С, Т1, Банк России.

Что делают

Основные направления — разработка сайтов (лендинги, промо-страницы, корпоративные порталы, веб-игры), сервисы и личные кабинеты, брендинг (логотип, фирменный стиль, бренд-платформа), дизайн-поддержка (motion, презентации, арты для соцсетей). Форматы работы — под ключ, разработка дизайна, поддержка и доработка с расширением функциональности.

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

Примеры проектов

• Игра для Мегамаркет — высоконагруженный проект для десктопа и мобильного приложения. Команда из 16 человек за 2 месяца разработала под ключ геймдизайн, интерфейс, код и развернула проект с пиковой нагрузкой 30 тысяч пользователей одновременно.

• Мобильное приложение и десктоп-версия личного кабинета для Appeer — система денежных переводов с широкой целевой аудиторией. Задача — создать интерфейс, удобный для всех и соответствующий требованиям финансового регулятора. До этого команда разработала для клиента нейминг, бренд-платформу, логотип и фирменный стиль. Проект занял 4 месяца, команда — 6 человек. Функционал личного кабинета дополнялся по ходу работы, требовалась синхронизация с инхаус-разработчиками сайта.

• База знаний для ПИК-Комфорт — проект с бизнес-задачей снизить стоимость обучения сотрудников через оптимизацию процесса. Провели аналитику, изучили пользовательские сценарии, спроектировали интерфейс онлайн-базы и подготовили стандарты оформления образовательной документации. 2 месяца, команда из 6 человек.

• Личный кабинет для интернет-магазина Ushatava — комплексный проект для улучшения UX и расширения функционала сайта. Выделили 8 пользовательских сценариев, разработали кликабельные прототипы и протестировали их на глубинных интервью с представителями целевой аудитории. Сделали дизайн в стиле существующего сайта и сверстали. 6 месяцев, команда из 6 человек.

Подход к работе

Процесс разработки адаптируется под задачи и возможности клиента — используют практики Agile, спринты, конвейерную разработку и DevOps. Для качества и скорости проводят код-ревью, тестирование, ретроспективы, поддерживают кросс-функциональность команды.

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

Больший опыт проектов с IT-компаниями — международными, федеральными и стартапами, а также финансовым сектором — банками и финтех-проектами.

Технологии

React (Next), PHP (Symfony, Laravel), Kotlin/Java (Spring Framework, Spring Boot), Angular, Vue (Nuxt), NodeJS (NestJS). Базы данных — SQL, NoSQL (MongoDB, PostgreSQL). CMS — WordPress, Webflow, 1C-Битрикс.

Интеграции с CRM, платёжными системами, клиентскими API и базами данных.

Управление и поддержка

Взаимодействие строится по принципу одного окна — работа с одним контактным лицом, прямой доступ к команде по запросу. Для постановки и контроля задач используют таск-трекеры, регулярно готовят отчётность и проводят чекап-созвоны. Облачные инструменты для легаси проекта доступны в любое время с любого устройства.

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

Кого в итоге выбрать?

Выбор подрядчика зависит от конкретной задачи и стадии развития продукта.

• ТРИАДА — вариант для сложных проектов с legacy-кодом, горящими сроками и необходимостью в глубокой экспертизе по поддержке и интеграциям, особенно на базе 1С и Битрикс.
• fuse8 — подойдёт для компаний, которым нужен партнёр полного цикла, способный быстро спроектировать и запустить MVP, а затем развивать его, опираясь на современные технологии без привязки к коробочным решениям.
• Бестранк — специализируется на автоматизации внутренних процессов для среднего бизнеса, особенно на базе Bitrix24.
• WaiWai — узкопрофильное агентство для тех, кому нужны AI-агенты для продаж и рекрутмента.
• Beavers Brothers — работают в комплексных проектах, где нужна не только разработка, но и визуальная составляющая: брендинг, дизайн, 3D и motion-графика.

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

Меня зовут Виталий Киреев, я руководитель отдела исследований и разработок хостинг-провайдера SpaceWeb. В статье расскажу, как мы с нашей командой проводили рефакторинг кода при переходе с PHP 7.4 на PHP 8 и на что заменили одну из самых популярных функций — create_function.

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

Контекст: когда стало ясно, что нужен рефакторинг

В части проектов SpaceWeb много legacy-кода. Мы поддерживаем проекты с версии PHP 5.6, которая появилась в 2014 году. С некоторой периодичностью переходим на новые версии PHP, постоянно обновляя код.

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

Когда вышла версия PHP 7.4, функция create_function, которая часто использовалась в нашем коде, стала deprecated, то есть перестала поддерживаться и работать. Из-за этого стали появляться ошибки в коде. Тогда и стало ясно, что нужен рефакторинг.

Подсветить часть проблем в коде нам помогли статические анализаторы кода — PHP Code Style Fixer и PHPstan. Но большую часть кода мы проверяли и обновляли вручную. В первую очередь нужно было придумать, на что заменить популярную create_function. Сперва начали переход на анонимную функцию и замыкание. А спустя время внедрили и стрелочные функции, чтобы повысить читаемость кода и решить дополнительные задачи.

Анонимные функции: как работают и как применить замыкание

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

На самом деле, create_function, которую мы обычно использовали до PHP 8 — это классический пример использования анонимной функции. Ее часто применяли для обработки данных в массиве. Функция содержит два аргумента — массив аргументов функции и сам код.

Когда эта функция стала deprecated в PHP 8, мы начали рефакторинг кода. Анонимные функции стали выглядеть так:

Но что, если нам потребуется вызвать эту функцию в нескольких разных местах? Тогда можно использовать замыкание. Это позволит вызывать функцию, используя ее как переменную.

А как быть, если нам нужно использовать переменные из окружения, и значения переменных будут меняться в процессе выполнения программы? Здесь нам помогут стрелочные функции.

Стрелочные функции: в чем отличие от анонимных и где лучше использовать

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

В этом примере была задача отфильтровать контракты и соотнести их с нужным ИНН. Если бы решали ее с помощью анонимных функций, то под каждый ИНН пришлось бы писать отдельную функцию. А еще везде использовать use.

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

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

Итоги

Для замены create_function в PHP 8 можно использовать как анонимные, так и стрелочные функции.

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

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