👋Листаю ленту. Очередная статья-молебен на тему «Как AI сделает из вас архитектора-бога». Пишет ADR-ы, рисует C4-диаграммы, отвечает на тупые письма от менеджеров. Все в восторге. Комментарии — сплошной восторг.

А у меня в голове только одна мысль.🙃

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

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

А теперь представьте имбецила, которому сразу дали калькулятор. Он получает правильные ответы. Он даже может сдать экзамен. Но он понятия не имеет, что он, черт возьми, делает. Он не может отличить умножение от сложения. Он — оператор кнопок.

Вот это и есть архитектор, который «проектирует» с помощью AI. Он скармливает промпт и получает красивую картинку. Микросервисы, Кафка, вот это всё. Выглядит солидно. Только он не знает, почему система именно такая. Почему здесь нужен CQRS, а не простой CRUD. Почему этот сервис взорвется под нагрузкой.

AI — это идеальный инструмент для создания архитектурного карго-культа. Он строит вам идеальный бамбуковый аэродром. С кокосовыми наушниками в комплекте.

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

AI — это анаболики. Он дает вам быстрый, красивый результат. Ваша презентация выглядит так, будто ее делал бог. Ваши диаграммы безупречны. У вас есть «мышцы». Но это фальшивка. Внутри — пустота. Стоит только столкнуться с реальной, нестандартной проблемой, и вся эта красота схлопывается. Потому что силы нет. Выносливости нет. Мозга нет.

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

Вы правда думаете, что этому можно научить машину?👀

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

А вы? Если вы отдали машине право думать, то кто вы в этой схеме? Вы становитесь просто передаточным звеном. Прокладкой между AI и командой.

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

Так что продолжайте радоваться. Генерируйте свои ADR-ы одной кнопкой. Пусть AI думает за вас. Только потом не удивляйтесь, когда однажды вас заменят. Не другой нейросетью. А простым скриптом на Python.

Потому что оператор кнопок должен стоить дешево.💯

#заметкинаполях

Токсичный (it) архитектор

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

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

Я чуть не лопнул от смеха.😁 Безрисково они хотят...

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

Представьте, что ваш монолит - старый, ржавый, но рабочий грузовик. Он чудит, жрет масло, но худо-бедно возит грузы и приносит деньги. Вы хотите заменить его на новый блестящий пикап или что-то другое. Идея номер один - сжечь старый грузовик и ждать, пока приедет новый - это подход «Big Bang Rewrite», который проваливается в 99% случаев, оставляя бизнес с голой задницей.💩

Паттерн «Душитель» (Strangler Fig) продается вам как гениальный и простой план: давайте рядом со старым грузовиком потихоньку строить новый, и постепенно перекладывать груз с одного на другой. Звучит вроде как безопасно, да?

Это сказка для менеджеров.

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

Красиво? Да.
Работает? В книжках пишут что да. 👀

А теперь суровая реальность, о которой вам не расскажут на митапах.

🧐 Это невыносимо ДОРОГО и ДОЛГО. «Постепенно» в мире средней компании — это «годами», и не говоря про энтерпрайзы. Все это время вам нужно содержать два зоопарка. Кормить команду, которая ковыряет легаси-говно мамонта, и команду хипстеров, которые пилят новые сервисы на Go. Это двойные расходы на инфру, пайплайны, мониторинг и зарплаты. Это кровоточащая рана в бюджете вашей компании.

🙄 Ваш прокси — это ваш НОВЫЙ "МОНОЛИТ". Только еще хуже. Этот фасад, который вы поставили спереди, становится самой сложной и хрупкой точкой отказа. В нем логика роутинга, аутентификация, трансляция протоколов. Ошибка в конфиге этого монстра кладет ВЕСЬ ваш бизнес. Вы не избавились от монолита, вы просто назвали его API Gateway и сделали сетевым. Гениально.

😡 АД С ДАННЫМИ.  Главный гвоздь в крышку гроба вашего проекта. Как ваш новый сервис профилей будет работать с заказами, которые остались в базе монолита? Будет ходить в старую базу напрямую? Поздравляю, вы только что изобрели распределенный монолит — худшее, что создало человечество после смузи с авокадо. Данные в двух местах, связанные через нестабильную сеть. А как синхронизировать? А консистентность? Вы утонете в скриптах миграции, очередях и бесконечных разборках, почему данные разъехались. 80% времени и нервов уйдет сюда.

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

И ответьте себе на три вопроса, только честно, глядя в зеркало:

😐 НАХРЕНА? Какую бизнес-проблему вы решаете? «Монолит - немодно, надо микросервисы» - это диагноз, а не ответ.

😐 ГДЕ РЕЗАТЬ? У вас есть четкое понимание границ модуля, который вы собрались отпиливать? Вы уверены, что он не связан с остальным монолитом тысячами невидимых нитей? Вы проводили аудит?

😐 ЧТО С ДАННЫМИ? Покажите мне ваш план миграции и синхронизации данных. Не на словах, а на бумаге, с диаграммами и проработанными кейсами откатов. Нет плана? Свободны.

Если ответа нет хотя бы на один вопрос - забудьте слово «душитель».
Иначе единственное, что он придушит - это ваш проект, бюджет и остатки здравого смысла.🚀

#этобаза

Токсичный (it) архитектор

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

Вся индустрия будто слетела с катушек. Мы нанимаем не тех, кто может спроектировать надежную систему, а тех, кто никому не испортит настроение.

Это бред.

Бред, который убивает проекты. Медленно, но гарантированно.

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

Хирург А - душа-человек. Держит за руку, травит анекдоты, говорит, что все будет хорошо. Никогда не скажет, что вы сами виноваты, потому что жрете как не в себя. Не будет спорить с анестезиологом, чтобы не создавать «конфликт». Его все любят.

Хирург Б - угрюмый тип. Глянет в ваши анализы и буркнет: «Не бросите курить - через год вернетесь на этот стол. Если доживете». Будет орать на медсестру за не тот зажим и спорить до хрипоты с коллегами. Его побаиваются.

Кого вы выберете?👀 Если у вас есть инстинкт самосохранения, вы выберете того, у кого самый низкий процент смертности. И плевать вы хотели на его «софт-скиллы».💯

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

Забудьте чушь из HR-буклетов. Вот настоящие «софт-скиллы» архитектора:

🚀Интеллектуальная честность. Способность публично сказать: «Я не знаю» или «Я облажался, вот план, как это исправить». А не лепить умное лицо, неся чушь.
🚀Техническое мужество. Умение быть щитом проекта, а не флюгером. Говорить «нет» бизнесу, команде, гендиру - кому угодно, если их хотелки ведут всех на дно.
🚀Способность к трансляции. Умение переводить с языка байтов на язык денег. Объяснить менеджеру, почему его «маленькая кнопочка» будет стоить полгода рефакторинга.

Всё остальное - мишура.

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

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

Выбирайте. Только потом не жалуйтесь.

#заметкинаполях

Токсичный (it) архитектор

👋Смотрю на часы. 10:45. Наш 15-минутный «ежедневный синк» идет уже сорок пять минут. Сорок пять, Карл! Скрам-мастер, вчерашний выпускник курсов по «лидерству и мотивации», с видом Черчилля перед высадкой в Нормандии водит курсором по Jira.🫡 Тимлид пытается в пятый раз объяснить, почему его задача «в процессе» уже третий день. А я просто жду, когда этот сеанс коллективного самообмана закончится и можно будет по-настоящему работать.

И в этот момент меня накрывает. Окончательно и бесповоротно.

Agile не мертв. Вы его убили. А потом набили труп соломой, нарядили в костюм из стикеров и поставили в центре опенспейса как ритуальное чучело. И теперь вы водите вокруг него хороводы, бормоча заклинания из книжек Кокберна и Сазерленда.👀

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

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

И роль архитектора в этом балагане? У тебя два пути, и оба ведут в ад.

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

Второй путь - стать наблюдателем.😳 Ты машешь рукой, мол, «самоорганизующаяся команда», и позволяешь им творить. Они счастливы. Velocity растет. Менеджеры хлопают в ладоши. А ты молча смотришь, как варвары строят из твоего Рима уродливые фавелы. Как закладывается технический долг такого размера, что расплачиваться за него будут три поколения программистов. А через год, когда система встанет колом под нагрузкой, кто будет виноват? Правильно, архитектор. «Куда же ты смотрел?!»

Так что делать?

Давайте начистоту. Выбросьте к черту половину ваших ритуалов. Оставьте только то, что приносит реальную пользу. Прежде чем начать любую встречу, задайте один вопрос: «Какого черта мы здесь собрались и с каким результатом должны выйти?» Если ответа нет - расходитесь.

🚀Дейли - три вопроса: Что сделал? Что буду делать? Что мешает? Пять минут на команду. Все. Остальное - в личку или отдельные встречи.
🚀 Оценки - забудьте про story points. Оценивайте в днях, вилками (например, 2-5 дней), и честно говорите, что это предположение, а не клятва на крови.
🚀Архитектура - она не возникает из хаоса. Она должна опережать разработку хотя бы на шаг. Выделите время на проектирование. Да, это «не по Agile». Плевать. Либо так, либо через год будете жить в руинах.

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

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

#заметкинаполях

Токсичный (it) архитектор

Всем привет!👋

"Очередной созвон. На экране расшаренная VS Code. Молодой и восторженный тимлид с горящими глазами показывает мне… код. Код, который генерирует диаграммы.

«Мы внедряем LikeC4! - вещает он. - Теперь у нас будут живые, актуальные схемы прямо в репозитории! Больше никакого Miro, который вечно устаревает!»

Я молча отхлебнул кофе. В его голосе было столько щенячьего восторга, будто он не инструмент для рисования коробочек нашел, а лекарство от рака."

Наверное, так началась бы моя статья про диаграммы как код, но это как-нибудь в другой раз. У меня есть что сказать по этому поводу. А сегодня просто хотел поделиться интересным инструментом, который помогает создавать диаграммы. 💯

LikeC4 - это набор инструментов и специализированный язык (DSL), который описывает архитектуру в виде единой модели, а затем компилирует ее в различные диаграммы.🔥

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

#интересное

Токсичный (it) архитектор

Привет,👋 на этой неделе хочется поговорить про CAP-теорему.🧐 Попытаюсь в несколько постов раскрыть эту тему.

И начнем с истории. Меня как-то позвали на «архитектурное ревью», где сидят двадцать человек с горящими глазами, изучают слайды. 👀Микросервисы, кубернетес, распределенная база данных. И тут тимлид, с придыханием, произносит сакральное: «Мы выбрали AP-систему, потому что для нас важна доступность. Будем жить с eventual consistency».

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

У вас есть три вещи:
🗿Consistency (C): Все видят одни и те же данные в один и тот же момент. Никаких «подождите, у меня другая версия».
🗿Availability (A): Система всегда отвечает на запросы. Не падает с ошибкой, даже если внутри у нее армагеддон.
🗿 Partition Tolerance (P): Система продолжает работать, даже если часть ее серверов перестала «видеть» другую часть. Например, сетевой кабель перегрызла крыса в дата-центре.

Так вот, CAP говорит: когда случается (P) - а он, вашу мать, всегда случается, это закон Мерфи в железе, - вы должны выбрать что-то одно. Либо (C), либо (A). Нельзя и рыбку съесть, и в кресло сесть.

Большинство «модных» команд, начитавшись блогов Netflix, как мантру повторяют: «Нам нужна доступность! Выбираем AP!». Звучит круто. На деле это означает: «Мы готовы отдавать пользователю любую чушь, лишь бы он не увидел ошибку 500». Система доступна, да. Но данные в ней - каша. Один сервис видит, что товар на складе есть, а другой - что его уже купили. Привет, потерянные заказы и злые клиенты. Ваша «eventual consistency» на практике часто означает «consistency never». Так что кроме как на лайки такие подходы ставить не стоит.

А есть и другая крайность - CP-системы. Банки, биллинг. Там, где за расхождение данных можно присесть. Система лучше упадет и перестанет отвечать (потеряет A), чем покажет неверный баланс (сохранит C). Это честный, взрослый выбор.

Но знаете, что самое смешное? Пока вы тут выбираете между C и A, вы забываете, что сеть падает не все время. Большую часть времени она работает. И тут на сцену выходит старший, еще более злой брат CAP — теорема PACELC.😳

Она задает вопрос, от которого у многих начинает дергаться глаз: «Хорошо, сейчас сеть в порядке (нет P). Что выберешь теперь: Latency (L) или Consistency (C)?».

И вот это - ваш ежедневный ад. Отдать ответ быстро, но с риском, что данные чуть устарели? Или заставить пользователя подождать, пока система синхронизирует все реплики и выдаст 💯% точный результат?

Системы, построенные только по CAP, игнорируют этот аспект. Они как одноклеточные: «сеть упала - действуем по плану Б». А PACELC заставляет думать постоянно. Когда все хорошо (Else), мы жертвуем консистентностью ради скорости (EL) или скоростью ради консистентности (EC)?

Ваша новомодная MongoDB - это PA/EL. В случае сбоя она выберет доступность. В штатном режиме - низкую задержку. А какой-нибудь VoltDB - это PC/EC. Упадет, но не соврет. И в обычном режиме будет проверять данные до посинения, жертвуя скоростью.

Так что прекратите кичиться знанием трех букв. CAP - это гигиенический минимум. Сейчас стоит думать в терминах PACELC, и думать не только когда сеть падает, но и когда все идет по плану. Задайте себе два вопроса:
🚀Что для бизнеса страшнее: простой или вранье? (Это ваш выбор C или A при P).
🚀Что для пользователя важнее: скорость или 100% актуальность данных? (Это ваш выбор L или C, когда все работает).

Ответы на эти вопросы для сервиса корзины и для сервиса авторизации будут, мягко говоря, разными.

#этобаза

Токсичный (it) архитектор