IT как Лего: почему эта ложная метафора приносит больше вреда, чем пользы, и что использовать вместо неё (Рубрика #Architecture)
На ArchDays 2024 в докладе про эволюцию архитектуры в Т-Банке у меня был слайд «IT as a Lego». Так выглядела концепция повторного использования решений: выделяем блоки, собираем системы из кирпичиков, всё взаимозаменяемо и красиво. Тогда я сказал коротко, что метафора не работает. Сейчас хочу разобрать, почему именно, тем более что Чад Фаулер пишет для O'Reilly книгу "Regenerative Software" ровно про это (книга топовая и я про нее расскажу сразу, как дочитаю)
Чем Лего подкупает
У кубика один интерфейс — стандартные выпуклости, и любой кубик стыкуется с любым. У кубика нет состояния, и он не меняется, пока его не трогают. Заменить кубик стоит ноль. Отсюда получается очень удобная логика для планирования: система равна списку блоков, блок равен строке в бюджете, переиспользование бесплатно, а замена системы — проект с датой окончания. По сути это та же строительная метафора, что и «сервис — это здание», только с инструкцией по сборке.
Звучит круто, но что не так с этой метафорой?
Сервис — не кубик. У него есть данные и история, неявные контракты и потребители, которые давно опираются на недокументированное поведение. В докладе я формулировал так: с точки зрения Лего замена элемента — это просто кубик, с точки зрения живой системы — трансплантация важного органа. Решения, принятые в логике Лего, узнаются по характерным фразам:
- «Возьмём коробку, потом заменим» — а исходная коробка живёт рядом с двумя волнами своих замен;
- «Назовём это платформой, и все будут переиспользовать» — а блок, вынутый из своей среды, тащит за собой её допущения и в другую среду не встаёт;
- «Это маленький сервис, заменим за спринт» — а маленьким он был только по числу строк.
Мне ближе растительная метафора и образ рисового поля из того же моего доклада: мы постепенно его достраиваем и не знаем, что скрывается на дне. Систему не собирают, а выращивают. Она отвечает на среду, у неё есть иммунитет и период восстановления после операций. Из этой метафоры следуют другие решения
- Миграция планируется с периодом сосуществования, а не как переключение рубильника
- Инвестировать надо в среду и иммунитет: платформу, тесты, наблюдаемость
- И признать, что часть системы разрастётся сама и её придётся подстригать.
Книга "Regenerative Software" развивает эту метафору дальше. Ее пишет сейчас Чад Фаулер— соавтор RubyGems, автор The Passionate Programmer и бывший CTO Wunderlist. Книга выходит у O'Reilly в Early Release, финальная версия ожидается в апреле 2027 года, а выросла она из серии эссе "The Phoenix Architecture", которую Фаулер публикует с декабря 2025 года. Тезис: код больше не актив, актив — система. Когда генерация кода почти бесплатна, а проверка нет, главным свойством становится replaceability — возможность безопасно заменить компонент целиком. А сохранять надо то, без чего его не воссоздать: поведение, границы, evaluations, evidence и provenance, то есть историю, почему решение именно такое. Мне понравился его deletion test: «Если удалить эту кодовую базу и сгенерировать заново, на что я буду опираться, чтобы решить, что результат правильный?» Страх при этом вопросе означает, что знание живёт только в коде.
Вторую главу Фаулер начинает с истории из Wunderlist: на замену «простого» сервиса членства в группах отвели вечер, а споткнулись о собственную систему уникальных ID, через которую всё остальное находило данные и которую уже никто целиком не понимал. Та самая трансплантация органа, только описанная изнутри.
Если продолжать биологическую аналогию (это уже моя, а не Фаулера), он предлагает не пересаживать органы, а отращивать их заново из «генома» системы: спецификаций, тестов и истории решений. Организм остаётся собой, хотя клетки в нём сменились. Насколько это заработает за пределами задач со строгими evaluations, пока неясно, и сам Фаулер оговаривает, что replaceability бывает неправильной целью. Но как рамка для решений это точно лучше кубиков.
Так что когда в следующий раз услышите «это просто кубик, заменим», спросите: какой это орган, что вокруг него выросло и на что вы будете опираться, чтобы проверить замену.
#Architecture #Software #Engineering #AI #Books #Management #SystemDesign
