Помните клиента, который делает стартап в одно лицо и уже напрограммировал два миллиона строк кода?
Наш архитектор Леша придумал, как выделить из его монолита отдельный голосовой сервис и написал ADR , а этот парень за день все реализовал :) завтра будем разбираться, не выплеснул ли он по пути ребенка.
С таким я ещё не сталкивался — мы ставим клиенту задачи, а он их программирует!
Прикольно, как меняются технические аудиты.
Сейчас мы делаем технический аудит и план технического развития бизнесу, которому почти 30 лет. Десятки репозиториев на разных языках, большАя часть логики в сотнях хранимых процедур и триггеров в монолитной MSSQL базе.
За 4 недели архитектор смог разобраться на уровне, который раньше занял бы полгода минимум.
При этом, если раньше мы готовили PDF файлы и схемы, которые читали люди, то теперь мы собираем папку с анализом исходников, папку с анализом базы (один файл на хранимку или таблицу), и так далее. Все зависимости, вся логика проекта — в текстовых описаниях. Ну и файл с описанием, что мы делаем и для чего, конечно. Все это в гите, с контролем версий.
А дальше подключаем этот репозиторий к Claude code и задаем вопросы по проекту: «как устроена логика ценообразования», «на что повлияет изменение параметра Х», реестр рисков и так далее. Ответы проверяют живые инженеры — так мы оцениваем качество нашей базы знаний.
—
Если раньше мы оставляли пусть хорошо и с любовью написанные, но документы и делились пониманием в разговорах, то теперь мы как будто оставляем своего цифрового двойника, который будет продолжать отвечать на вопросы заказчика даже после окончания аудита.
Эту базу знаний будут использовать не только для этого рефакторинга, но и для онбординга новых специалистов.
—
Через 4 недели работы, мой архитектор взял 2 недельный отпуск. Мы дадим свои рекомендации и закончим аудит уже после его возвращения.
Скорость работы увеличилась в разы, но нам, людям, все ещё нужно время, чтобы новые знания уложились в голове. Нужно время, чтобы понимание проросло в нас. Слово «проросло» точно отражает то, что этот процесс нельзя ускорить усиленной работой. Можно только создать условия и не мешать. Раньше это происходило естественно, теперь нужно специально делать перерывы.
—
Раньше я гордился тем, какие четкие, ясные, красивые диаграммы сервисов мы рисуем. Теперь их заменили полностью автоматизированные mermaid схемы. Генеральную схему всего бизнеса таким образом мы пока не нарисовали, она получатся совершенно неудобоваримая. Это ограничение технологий или отражение внутренней сложности бизнеса? Пока что ее нет и у нас в голове, так что это открытый вопрос.
—
Делюсь тремя файлами: Claude_md — общие правила игры для модели, а ещё файлы с целями и принципами этого аудита.
Ну и классное рассуждение по мотивам исследования: автор цитирует классика Питера Науэра (того самого, который N в BNF), который говорил, что программирование — это создание ментальной модели задачи, предметной области, в которой мы работаем.
Опытные программисты, годами работающие над проектом, конечно же, имеют эту модель в подкорке, и их софт ей соответствует. У нейросети этой модели нет, поэтому она скорее мешает, чем помогает.
Дальше автор делает печальное наблюдение, что большинство программистов работают с плохим кодом, который увидели вчера. Мол, в таких ситуациях нейросети будут полезны.
—
Удивительно, как теория переплетается с практикой.
Совсем недавно сделали проект, в котором нас позвали «привести в порядок успешный стартап». Чуваки собрали MVP, но страдают от низкой скорости добавления фичей. Раньше я говорил, что это из-за «высокой внутренней сложности кода».
Более точная формулировка: в числе прочего, мы придумали, как привести их код в соответствие с предметной областью. Для этого мы нарисовали схему их предметной области, выделили контексты и домены, а потом придумали разделение ответственности по задачам между сервисами.
Красиво!
Как перезапустить проект технически?
Прямо сейчас мы решаем эту задачу для стартапа. Ребята делают платформу для ученых, чтобы проводить исследования на больших группах респондентов. Куча интеграций, огромный зоопарк форматов данных.
Они пользуются уже третьей версией своей платформы. Фронтенд на low-code платформе Bubble, бэкенд частично на flask и частично n8n. Всё работает, приносит пользу, проект поднял больше миллиона долларов инвестиций.
Как навести порядок, радикально увеличить скорость доставки фич и гарантировать масштабируемость?
Первый порыв любого программиста — переписать всё с нуля. Благо, проект ещё не очень большой, за месяца 3–4 парой программистов, наверное, можно управиться. Составить список фичей, написать их заново, потушить сервис на пару часов, импортировать данные из старой системы в новую и запуститься.
Но это — ошибка. Во-первых, мы не понимаем истинного объема бизнес-логики, который успел накопиться в коде. Скорее всего, сам клиент её недооценивает. Во-вторых, пока будем переписывать — проект продолжит развиваться. Придется догонять. В-третьих, любой, кто делал импорт данных, скажет вам, что это задача из ада, и чем старее данные — тем сложнее их вытащить. Настроить тестирование этого нового проекта будет сложно, да и полноценным оно не может быть по определению.
В результате, в момент включения новой платформы в продакшен, точно возникнут проблемы, которые придется героически исправлять «прямо сейчас», в стрессе. Мало предсказуемости, о реальном объеме работы мы узнаем только в самом конце проекта, при попытке переключения. Мы такое не любим.
Правильный ход — это strangler fig pattern. Пишем небольшую обертку для старого бэкенда. Этот новый бэкенд действует как прокси — передает запросы к старому бэкенду, запоминая сами запросы и ответы. Дальше выделяем первые эндпоинты бэкенда, которые мы можем запрограммировать заново, красиво. Дублируем эти запросы пользователей в старый и новые движки. Сравниваем ответы нового движка с ответами старого, исправляем ошибки. Накапливаем информацию в новую, аккуратно составленную базу данных. И только после продолжительного тестирования на живых данных начинаем отдавать пользователю ответы нового бэкенда. Берем следующую пачку эндпоинтов и повторяем процесс.
Получается, у нас нет момента «большого рубильника», который переключит весь трафик со старого движка на новый, мы «едим этого слона по частям». Переход со старого бэкенда на новый происходит плавно, незаметно для бизнеса. Ошибки в новой системе видны только программистам и не затрагивают клиентов.
Не менее важна предсказуемость. В первом подходе мы весь проект живем под дамокловым мечом — какие сюрпризы нас ждут при запуске? Во втором подходе мы размазываем эту неопределенность по всей продолжительности проекта, так что уже через пару недель можно увидеть реальную скорость разработки, включая исправление ошибок, и оценить общий объем работы и сроки.
Наконец, этот подход позволяет выкатывать новые фичи в продукте внутри нового бэкенда до окончания переезда, параллельно с рефакторингом.
К сожалению, кажется, что каждый молодой программист обречен пытаться всё переписать правильно с нуля. Технарь, предлагающий strangler fig pattern, не лучше, просто за его обучение уже заплатил другой заказчик.
На фотографии тот самый фикус-душитель опутывает дерево, как новый бэкенд опутывает старый.
Разработали сложный микросервис уведомлений для крупной строительной компании.
На картинке — общая архитектура сервиса.
В новой технической статье рассказываем, как так получилось.
—
Хотите запустить новый продукт с нуля или сервис внутри существующей архитектуры? Пишите в личку @samatg! Мы берем новых клиентов.
Вышла классная заметка DHH о том, что лучше писать нормальные монолиты, чем пытаться делать модные микросервисы. Дэвид — создатель Basecamp и Ruby on Rails.
Поводом для заметки послужила новая статья команды Amazon Prime Video, где они рассказывают, как отказались от микросервисов, решили проблемы с масштабированием и сократили издержки на 90% (не опечатка).
Не буду здесь повторяться; тем более, что Дэвид даже рассказал, как быть, если вы уже поторопились и сделали микросервисы.
—
Вот Дэвид издевается над Амазоном и микросервисами, а я в традиции постмодернизма поиздеваюсь над ним. Хорошо быть здоровым и богатым — в смысле, что опираясь на многолетний опыт и руководствуясь здравым смыслом, делать минимальное необходимое программирование, не переусложнять систему. Спасибо за совет!
По сути я с ним согласен — в 90% случаев микросервисы не нужны. Но если вы об них ещё не обжигались — то не слушайте старых пердунов вроде нас, делайте свои ошибки, учитесь, по-другому учиться очень сложно.
Тем более, что это интересная задача для нас с Федей — разбирать архитектурные завалы. Если вдруг обнаружили себя в ситуации, что разработка начала тормозить или хотите избежать этого со старта — обращайтесь :)
«Простота — это великая добродетель, но она требует напряженной работы, чтобы её достичь и образование, чтобы оценить. И к сожалению, сложность продается легче.» — Дейкстра.
—
Простые решения дешевле в реализации и поддержке, в них меньше вероятности допустить ошибку, их легче передать другому и так далее и так далее.
Кажется, что раз решение сложное — то в него вложено больше труда и значит оно должно быть лучше.
Это, конечно, не так. Процитирую Паскаля: «если бы у меня было больше времени, я бы написал письмо покороче».
В программировании ровно то же самое: простые решения требуют гораздо больше интеллектуальных усилий, приходят с опытом.
Да, есть задачи, которые сами по себе сложные, с огромным числом ограничений и тд., например, биллинги обычно такие. При этом, почти все биллинги, которые я видел, были переусложнены сверх необходимого. 🙈
—
Отличная статья об этом феномене на примере научных статьей в области машинного обучения. Спасибо Игорю за наводку.
Давненько у нас не было «классических» эпизодов про то, как технически устроены известные сервисы и как там построена разработка.
Восполняем этот пробел эпизодом про ЦИАН. Если вы снимали, сдавали или покупали жилье в России — вы с ним точно сталкивались.
Как ЦИАН смог стать таким популярным, что случилось, когда они объединили два огромных бэкенда на .NET и PHP/Python и как они борются с мошенниками с помощью алгоритмов — узнаем у технического директора ЦИАНа Алексея Чеканова.
Слушайте и подписывайтесь: Apple, Google, Яндекс, Spotify, Castbox, Overcast, веб-версия.
Сегодня я видел небольшой самодельный ERP (много мелких крудов типа оформления отпуска) на скале, с Кафкой и Кассандрой. Там есть блоги. На скале.
А вчера — высоконагруженное e-commerce решение с ядром на битриксе.
Не могу решить, что мне нравится больше 👀
Мой учитель по психотерапии говорит, что почти в каждом терапевте есть мазохистическая часть личности, иначе в профессии делать нечего. В IT-аудите — похожая история.
Ещё круто, что как не издевайся над здравым смыслом — все равно ведь работает и даже деньги зарабатывает. Мир шире и богаче, чем я себе представлял.
Похвастаюсь. Делаем с Федей аудит одного крупного финансового сервиса. Сегодня был третий день встреч с техдиром.
Каждый фиолетовый прямоугольник — это довольно большой сервис (отдельный репозиторий), над которым работает своя команда.
На схеме примерно треть, а то и четверть всей системы. Базы по много терабайт, тысячи интеграций — вызывает уважение, да что говорить, восхищение, что всё это работает и приносит пользу и деньги. 😍
