Перейти к содержанию
Инженер следующего изменения

Оглавление

Engineering Profile / Версия 1.0

Мне нравится превращать сложные системы в понятные.

Сама сложность меня не привлекает. Понятную систему проще развивать, сопровождать и передавать другим инженерам.

Владимир Синявский
Engineering Lead и архитектор программных систем

Контакты Резюме PDF, откроется в новой вкладке

10+ лет инженерной практики.
5+ лет технического лидерства.

FinTech, Travel, EdTech и AI.

01

Почему я этим занимаюсь

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

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

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

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

02

Я начинаю с домена и ограничений. Технологии приходят позже.

  1. 1 Понять предметную область

    Где проходят реальные границы домена и почему одни и те же слова значат разное?

  2. 2 Найти реальные ограничения

    Я смотрю на технические ограничения вместе с продуктовыми и организационными.

  3. 3 Смоделировать домен

    Модель нужна для решений. Простого описания текущего кода недостаточно.

  4. 4 Спроектировать границы

    Ответственность компонентов и команд должна оставаться понятной при росте.

  5. 5 Выбрать технологии

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

  6. 6 Вывести на прод

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

  7. 7 Наблюдать и развивать

    Новые факты меняют архитектуру. Это нормальная часть её жизни.

03

Чем я занимаюсь

Новая платформа

Спроектировать продуктовую систему, собрать техническую основу и вывести MVP на прод.

Legacy без остановки

Развивать работающую систему постепенно, сохраняя бизнес-процессы и совместимость.

Команда и ответственность

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

AI-native Engineering

Проверять AI-подходы в реальной работе и оставлять то, что действительно помогает инженерам.

04

Домены меняются. Классы инженерных проблем повторяются.

Точки слева направо: Payments, Travel, EdTech / Legacy, AI-native.

Выбранная задача

Сложная предметная область

AI-native

Нет: задача не была основной для этого домена.

Выбранная задача

Внешние интеграции

Выбранная задача

Асинхронность и неопределённость

EdTech / Legacy

Нет: задача не была основной для этого домена.

Выбранная задача

Эволюция без остановки

AI-native

Нет: задача не была основной для этого домена.

Выбранная задача

Надёжность и наблюдаемость

Выбранная задача

Инженерная среда

21 из 24 пересечений подтверждены конкретными проектами. В трёх случаях – нет: эта задача не была основной для домена.

"Эволюция без остановки" встречалась в legacy-биллинге, работающих travel-сервисах и при постепенной замене Rails на .NET.

05

Проекты, где я с этим работал

CASE-002

Travel & Business Travel

В travel-домене внешне простое "найти и забронировать" превращалось в агрегацию нескольких GDS и разные жизненные циклы брони, оплаты и взаиморасчётов.

Контекст. RuTrip держал около 300 rps. В продукте были 40 фильтров, 4 сценария бронирования, 3 способа оплаты и 2 вида взаиморасчётов с GDS.

Что сделал. Работал над агрегацией поиска и бронирования, Customer Journey Map и общим языком с продактом. Архитектуру постепенно переводили на vertical slices.

Результат. Время поисковой выдачи сократилось с 20–30 до 6–8 секунд. Позже в business travel я работал с внешними GDS и критичными корпоративными системами, которыми пользовались 300+ сотрудников.

CASE-003

Evolutionary Legacy Modernization

Нестабильный Rails API платформы с 20 000 активных пользователей нельзя было остановить и переписать целиком.

Контекст. Работающий продукт зависел от нестабильного Ruby on Rails API, а миграцию нужно было провести без остановки клиентских приложений.

Что сделал. Собрал команду из четырёх backend-инженеров. Мы постепенно замещали маршруты через Strangler Fig и параллельно переносили данные.

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

CASE-004

Engineering Organization

В инвестиционном EdTech-продукте команда выросла с 5 до 15 человек и разделилась на две.

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

Что сделал. Занимался наймом, 1:1, ИПР и делегированием. В команде появились DDD, Event Storming, взаимное ревью, тестирование и DevOps.

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

CASE-005

AI-native Engineering

Сейчас я проверяю в реальной работе инструкции для AI-агентов и процесс разработки с ними. Подход ещё формируется.

Контекст. Нужно было ускорить сложную интеграционную разработку и работу с legacy, оставляя инженерные решения за человеком.

Что сделал. Собрал 20+ инструкций для AI-агентов (agent skills), настроил их версионирование и доставку, подключил к работе бэкенд-команд и обучил коллег.

Результат. В одиночку собрал MVP сложной интеграционной системы за 4 месяца. Другой legacy-проект переписал с PHP на .NET / React за 1 месяц, используя AI-пайплайн.

Active development

Открытый проект

OSS-001

Travel Platform

Открытый проект, где видны моделирование домена, архитектурные решения и организация кода. Сейчас готов бэкенд Flights M1: модульный монолит с DDD, интеграции с поставщиками авиаконтента, устойчивость, наблюдаемость и отдельный AI-сервис.

Дальше – Hotels, Rail, Trip Planning и ядро AI-сервиса.

Открыть репозиторий
06

Несколько наблюдений из практики

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

Самые сложные проблемы часто начинаются с разного понимания предметной области.

Команду и инженерные процессы тоже приходится проектировать.

AI меняет работу сильных инженеров, но ответственность за решения остаётся у человека.

07

Почему существует этот сайт

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

Теперь я собираю такие истории сам.

Архитектура

Проектирование, которое работает после первого релиза

Длинные разборы решений, ограничений и цены изменений.

 Практика

Статьи на Хабре

DDD, distributed systems, legacy и инженерная работа с AI.

 Исследования

Интерактивные инженерные разборы

Как порядок решений влияет на стоимость и устройство системы.

В Telegram – наблюдения из инженерной практики, продолжения статей и эксперименты с AI в работе синьора и техлида.

08

Если хотите обсудить похожую систему или решение, напишите.

Email siniavsky.vladimir@gmail.com Telegram @vladimir_sva GitHub svasorcery Блог blog.vsinyavsky.ru Сайт vsinyavsky.ru Документ Резюме PDF, откроется в новой вкладке

Буду обновлять эту страницу вместе с проектами и собственным опытом.