Помните клиента, который делает стартап в одно лицо и уже напрограммировал два миллиона строк кода?
Наш архитектор Леша придумал, как выделить из его монолита отдельный голосовой сервис и написал ADR , а этот парень за день все реализовал :) завтра будем разбираться, не выплеснул ли он по пути ребенка.
С таким я ещё не сталкивался — мы ставим клиенту задачи, а он их программирует!
Взлет и падение StackOverflow.
Это был главный сайт вопросов и ответов для программистов. На пике популярности, в 2014-2018, там задавали по 200 тысяч вопросов в месяц! В прошлом месяце, на нем задали только 3 тысячи вопросов, столько же, как и в августе 2008, при запуске.
Нейросети — финальный удар, который добил гиганта. ИИ отвечает на конкретно твой вопрос мгновенно, а недавно научился искать по всему интернету. Это удобнее, чем часами, а то и днями ждать ответов от волонтеров.
Но сайт начал падение ещё в 2018 году! Ну и окончательно покатился вниз в 2021, задолго до появления нейросетей (первая сколько-то полезная chatgpt 3.5 выйдет только в ноябре 2022).
Что же это было? Две главные гипотезы:
1. Discord. Эту программу для чатов запустили в 2015 году и в 2016-17 туда начали переезжать популярные open source проекты. Это, кстати, огромная потеря, ответы на вопросы из Discord’а недоступны для поиска в «большом интернете». Есть проекты типа Linen, которые пытаются это исправить, но они стоят денег и по умолчанию сообщения «заперты» в чатах. А ещё Discord, конечно, продаёт доступ к чатам компаниям обучающим нейросети, но это отдельная история.
2. Очень злая модерация. Модераторы закрывали вопросы как дубликаты или как не подходящие под «правила сайта». В результате, новички часто не могли получить ответ на свои вопросы и уходили разозленные, а опытные участники разочаровывались и переставали отвечать. Классический синдром вахтера, когда суть подменяется формой, у википедии схожие проблемы.
Интересно, что сайт изначально имел двойственную суть: это была попытка создать полную, структурированную энциклопедию знания о программированию с одной стороны — это был посыл со-основателя Джефа Атвуда (он вышел из проекта в 2013) и сообщество людей, которые помогают друг-другу, с другой — идея Джоэля Спольски, второго сооснователя, вышедшего из проекта 2019 вместе с продажей.
Кстати, SO — пример отличной архитектуры, когда люди не изобретают сложность на пустом месте. Один из самых популярных сайтов в интернете работал на десятке серверов, а временами выживал вообще на одной машине. Рекомендую серию статей 2016 года, где инженер оттуда рассказывает, как всё устроено под капотом. Есть чему поучиться.
А ещё у нас есть эпизод подкаста, где мы говорим с Николаем Чабановским, который сделал русский клон и продал его самому Джоэлю Спольски и отвечал за сообщества в SO.
Прям ностальгия...
Хорошая заметка про сервис уборки за вайбкодерами.
Совпадает с моими наблюдениями в том, что ИИ помогает быстро сделать прототип и писать тесты, а вот полноценная продакшен версия требует нормальной архитектуры и внимания сеньора.
К сожалению, многие получают это знание через собственные ошибки, когда навайбкоженный сервис сломался и (или) его взломали.
В такой ситуации профессия vibe code cleanup specialist («привожу в вайбкод в порядок») перестаёт быть шуткой. В статье есть ссылки на примеры и даже исследования.
Интересно, как меняются инструменты, но не меняется суть. Мы уже много лет зарабатываем на том, что приводим в порядок проекты, запущенные другими людьми. Это называют «технический перезапуск», «глобальный рефакторинг», суть та же. Только если раньше это был код, написанный другими людьми, то теперь он сгенерирован нейросетями.
Сделать первую версию недорогой командой или навайбкодить — это, кстати, не плохо. Просто этап проекта, когда нужно за минимальную сумму протестировать идею. Привести потом это в порядок — кратно более сложная задача, но к этому времени проект уже доказал осмысленность дальнейших вложений.
Технически, приводить в порядок сложнее, чем писать с нуля, потому что не достаточно реализовать продуктовую идею, нужно дополнительно разобраться в том, как устроена прошлая версия и не сломать то, что уже работает.
Похоже на то, как дешевле построить дом с нуля, чем сделать ремонт в историческом здании.
Теперь эти «исторические здания» собирают с помощью роботов. :)
Ну и классное рассуждение по мотивам исследования: автор цитирует классика Питера Науэра (того самого, который N в BNF), который говорил, что программирование — это создание ментальной модели задачи, предметной области, в которой мы работаем.
Опытные программисты, годами работающие над проектом, конечно же, имеют эту модель в подкорке, и их софт ей соответствует. У нейросети этой модели нет, поэтому она скорее мешает, чем помогает.
Дальше автор делает печальное наблюдение, что большинство программистов работают с плохим кодом, который увидели вчера. Мол, в таких ситуациях нейросети будут полезны.
—
Удивительно, как теория переплетается с практикой.
Совсем недавно сделали проект, в котором нас позвали «привести в порядок успешный стартап». Чуваки собрали MVP, но страдают от низкой скорости добавления фичей. Раньше я говорил, что это из-за «высокой внутренней сложности кода».
Более точная формулировка: в числе прочего, мы придумали, как привести их код в соответствие с предметной областью. Для этого мы нарисовали схему их предметной области, выделили контексты и домены, а потом придумали разделение ответственности по задачам между сервисами.
Красиво!
Как перезапустить проект технически?
Прямо сейчас мы решаем эту задачу для стартапа. Ребята делают платформу для ученых, чтобы проводить исследования на больших группах респондентов. Куча интеграций, огромный зоопарк форматов данных.
Они пользуются уже третьей версией своей платформы. Фронтенд на low-code платформе Bubble, бэкенд частично на flask и частично n8n. Всё работает, приносит пользу, проект поднял больше миллиона долларов инвестиций.
Как навести порядок, радикально увеличить скорость доставки фич и гарантировать масштабируемость?
Первый порыв любого программиста — переписать всё с нуля. Благо, проект ещё не очень большой, за месяца 3–4 парой программистов, наверное, можно управиться. Составить список фичей, написать их заново, потушить сервис на пару часов, импортировать данные из старой системы в новую и запуститься.
Но это — ошибка. Во-первых, мы не понимаем истинного объема бизнес-логики, который успел накопиться в коде. Скорее всего, сам клиент её недооценивает. Во-вторых, пока будем переписывать — проект продолжит развиваться. Придется догонять. В-третьих, любой, кто делал импорт данных, скажет вам, что это задача из ада, и чем старее данные — тем сложнее их вытащить. Настроить тестирование этого нового проекта будет сложно, да и полноценным оно не может быть по определению.
В результате, в момент включения новой платформы в продакшен, точно возникнут проблемы, которые придется героически исправлять «прямо сейчас», в стрессе. Мало предсказуемости, о реальном объеме работы мы узнаем только в самом конце проекта, при попытке переключения. Мы такое не любим.
Правильный ход — это strangler fig pattern. Пишем небольшую обертку для старого бэкенда. Этот новый бэкенд действует как прокси — передает запросы к старому бэкенду, запоминая сами запросы и ответы. Дальше выделяем первые эндпоинты бэкенда, которые мы можем запрограммировать заново, красиво. Дублируем эти запросы пользователей в старый и новые движки. Сравниваем ответы нового движка с ответами старого, исправляем ошибки. Накапливаем информацию в новую, аккуратно составленную базу данных. И только после продолжительного тестирования на живых данных начинаем отдавать пользователю ответы нового бэкенда. Берем следующую пачку эндпоинтов и повторяем процесс.
Получается, у нас нет момента «большого рубильника», который переключит весь трафик со старого движка на новый, мы «едим этого слона по частям». Переход со старого бэкенда на новый происходит плавно, незаметно для бизнеса. Ошибки в новой системе видны только программистам и не затрагивают клиентов.
Не менее важна предсказуемость. В первом подходе мы весь проект живем под дамокловым мечом — какие сюрпризы нас ждут при запуске? Во втором подходе мы размазываем эту неопределенность по всей продолжительности проекта, так что уже через пару недель можно увидеть реальную скорость разработки, включая исправление ошибок, и оценить общий объем работы и сроки.
Наконец, этот подход позволяет выкатывать новые фичи в продукте внутри нового бэкенда до окончания переезда, параллельно с рефакторингом.
К сожалению, кажется, что каждый молодой программист обречен пытаться всё переписать правильно с нуля. Технарь, предлагающий strangler fig pattern, не лучше, просто за его обучение уже заплатил другой заказчик.
На фотографии тот самый фикус-душитель опутывает дерево, как новый бэкенд опутывает старый.
Разработали сложный микросервис уведомлений для крупной строительной компании.
На картинке — общая архитектура сервиса.
В новой технической статье рассказываем, как так получилось.
—
Хотите запустить новый продукт с нуля или сервис внутри существующей архитектуры? Пишите в личку @samatg! Мы берем новых клиентов.
Рассказываем, как перезапускали разработку медицинской информационной системы (МИС) для сети клиник «Чайка».
МИС — ядро современного медицинского бизнеса. Внутри — классическая история: за годы развития продукта, техническая команда оказалась погребена под сложностью проекта и то, что раньше занимало дни, теперь тянулось месяцами. Нас позвали ускорить разработку этой системы.
В какой-то момент мы зареклись браться за проекты по ускорению разработки — очень сложно масштабировать эту услугу как бизнес.
В этот раз испробовали новый подход: вместо чистого консалтинга, пришли с небольшой собственной командой и своими руками реализовали ключевые элементы новой архитектуры — не рассказали, но показали и внедрили новые идеи.
Сложный и большой проект: мы придумали новую архитектуру для бизнес-критичного приложения в сложной доменной области и успешно запустили новые и перезапустили некоторые старые модули системы без остановки производства.
К сожалению, довести проект до конца не получилось — помешала война. Тем не менее, основная идея, кажется, сработала — результаты появились гораздо быстрее и таких проектов мы можем брать больше, чем чистый консалтинг.
В статье хвастаемся тем, что получилось и без утайки делимся, где ошиблись. А ещё внутри супер красивые интерфейсы современной медицинской системы. Инжой!
Вы техдир и хотите поделиться похожей историей? — заходите в чатик @ctodailychat.
Хотите ускорить свою команду разработки или просто запустить новый продукт? — пишите мне в личку @samatg, мы ищем клиентов!
Вышла классная заметка DHH о том, что лучше писать нормальные монолиты, чем пытаться делать модные микросервисы. Дэвид — создатель Basecamp и Ruby on Rails.
Поводом для заметки послужила новая статья команды Amazon Prime Video, где они рассказывают, как отказались от микросервисов, решили проблемы с масштабированием и сократили издержки на 90% (не опечатка).
Не буду здесь повторяться; тем более, что Дэвид даже рассказал, как быть, если вы уже поторопились и сделали микросервисы.
—
Вот Дэвид издевается над Амазоном и микросервисами, а я в традиции постмодернизма поиздеваюсь над ним. Хорошо быть здоровым и богатым — в смысле, что опираясь на многолетний опыт и руководствуясь здравым смыслом, делать минимальное необходимое программирование, не переусложнять систему. Спасибо за совет!
По сути я с ним согласен — в 90% случаев микросервисы не нужны. Но если вы об них ещё не обжигались — то не слушайте старых пердунов вроде нас, делайте свои ошибки, учитесь, по-другому учиться очень сложно.
Тем более, что это интересная задача для нас с Федей — разбирать архитектурные завалы. Если вдруг обнаружили себя в ситуации, что разработка начала тормозить или хотите избежать этого со старта — обращайтесь :)
«Простота — это великая добродетель, но она требует напряженной работы, чтобы её достичь и образование, чтобы оценить. И к сожалению, сложность продается легче.» — Дейкстра.
—
Простые решения дешевле в реализации и поддержке, в них меньше вероятности допустить ошибку, их легче передать другому и так далее и так далее.
Кажется, что раз решение сложное — то в него вложено больше труда и значит оно должно быть лучше.
Это, конечно, не так. Процитирую Паскаля: «если бы у меня было больше времени, я бы написал письмо покороче».
В программировании ровно то же самое: простые решения требуют гораздо больше интеллектуальных усилий, приходят с опытом.
Да, есть задачи, которые сами по себе сложные, с огромным числом ограничений и тд., например, биллинги обычно такие. При этом, почти все биллинги, которые я видел, были переусложнены сверх необходимого. 🙈
—
Отличная статья об этом феномене на примере научных статьей в области машинного обучения. Спасибо Игорю за наводку.
Давненько у нас не было «классических» эпизодов про то, как технически устроены известные сервисы и как там построена разработка.
Восполняем этот пробел эпизодом про ЦИАН. Если вы снимали, сдавали или покупали жилье в России — вы с ним точно сталкивались.
Как ЦИАН смог стать таким популярным, что случилось, когда они объединили два огромных бэкенда на .NET и PHP/Python и как они борются с мошенниками с помощью алгоритмов — узнаем у технического директора ЦИАНа Алексея Чеканова.
Слушайте и подписывайтесь: Apple, Google, Яндекс, Spotify, Castbox, Overcast, веб-версия.