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

"Очередной созвон. На экране расшаренная 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) архитектор

👋Ну что продолжаем неделю про CAP теорему и поговорим про "С"

Для большинства из вас «консистентность» - это как «любовь» для подростка. Что-то одно, великое и непонятное. Вы думаете, это тумблер: включил - и все хорошо, выключил - и наступила «eventual consistency». Так вот, бред это сивой кобылы. Консистентность - это не выключатель. Это, мать его, регулятор мощности на электростанции, где каждое деление на шкале стоит вам денег, производительности и седых волос.

Давайте я вам разложу на пальцах, какой бывает эта ваша "C" и почему ваш выбор «строгой» консистентности - это, скорее всего, выстрел себе в ногу.💩

🔥Строгая консистентность (Linearizability)

Представьте себе одного-единственного бухгалтера на всю компанию, который сидит в запертой комнате. Любая операция - списание, зачисление, запрос баланса - идет через него. Он обрабатывает их строго по одной. Да, это медленно. Да, у его двери всегда очередь. Но, черт возьми, вы можете быть на 100% уверены, что в любой момент времени баланс - единственно верный.

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

🔥Последовательная консистентность (Sequential Consistency)

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

Когда это нужно: Системы, где важен порядок событий. Например, в чате сообщение А должно всегда приходить раньше ответа Б на него. Или в системе совместного редактирования документа правки должны применяться у всех в одной и той же последовательности, чтобы не получилась каша.

🔥Причинная консистентность (Causal Consistency)

А это уже совсем другой уровень. Системе плевать на глобальный порядок всех событий. Ей важны только причинно-следственные связи. Если событие Б случилось потому, что произошло событие А, то никто и никогда не увидит Б раньше А. А вот если события В и Г никак не связаны, то они могут прилететь к разным пользователям в разном порядке.

Когда это нужно: Социальные сети. Вам важно увидеть комментарий под постом, а не наоборот. Но вам абсолютно все равно, в каком порядке вам покажут два несвязанных поста от разных людей. Это отличный компромисс между строгостью и производительностью для 90% систем.

🔥Консистентность в конечном счете (Eventual Consistency)

Мое «любимое». Хайп, возведенный в абсолют. Это когда вы отправляете новость по факсу во все филиалы. Когда-нибудь она до всех дойдет. Может, через минуту, а может, через час. И какое-то время в разных филиалах будут видеть разную информацию.

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

🔥И что в итоге

Прежде чем орать на совещании «нам нужна консистентность», задайте себе один вопрос, но честно:

Какова цена ошибки, если данные на долю секунды разойдутся?

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

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

#этобаза

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

👋Ну что продолжаем про CAP. Меня умиляют команды, которые на каждом углу кричат: «Наш главный приоритет - доступность!». Они пишут это в README, вставляют в презентации для начальства. Звучит солидно. А потом у них падает база данных, и вся их «доступность» превращается в тыкву, потому что никто не подумал о репликации.

Давайте начистоту. Доступность (Availability) - это не галочка в Jira. Это самая дорогая и лживая метрика в IT. Вы не можете просто «выбрать доступность». Вы покупаете ее. За деньги, сложность и бессонные ночи вашей команды поддержки.

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

🔥Уровень 1: «Бытовая доступность»

Это ваш типичный проект-монолит на одном сервере. Доступен ли он? Да, пока сервер работает. Когда он падает - из-за сбоя питания, обновления ОС или потому что уборщица выдернула шнур - система недоступна. Все просто и честно. Это ларек с шаурмой. Если продавец заболел, ларек закрыт. Никто не ждет от него доступности 24/7.

Когда это нормально: 90% внутренних систем, админок, MVP, которые вы показываете инвестору. Короче, везде, где минута простоя стоит дешевле, чем зарплата еще одного инженера.

🔥Уровень 2: «Три девятки» (99.9%) - Начало боли

Это примерно 8.7 часов простоя в год. Чтобы этого достичь, одного сервера уже мало. Вам нужен как минимум второй сервер и балансировщик нагрузки. Теперь, если один сервер падает, второй подхватывает трафик. Звучит просто? А теперь подумайте: вам нужна репликация данных между ними, консистентность этих данных, система мониторинга, которая поймет, что первый сервер упал, и автоматический механизм переключения. Ваша архитектура усложнилась в три раза. Цена - деньги на железо и зарплата DevOps-инженера.

Когда это нужно: Обычные интернет-магазины, контентные сайты. Бизнес, который теряет деньги каждую минуту простоя, но может пережить сбой в 3 часа ночи раз в квартал.

🔥Уровень 3: «Пять девяток» (99.999%) - Элитный клуб самоубийц

Это 5 минут простоя в год. ПЯТЬ. МИНУТ. Это включает время на развертывание, обновление, любые сбои. Чтобы достичь такого, вам уже недостаточно двух серверов. Вам нужны несколько дата-центров в разных городах. Геораспределенная репликация. Автоматическое восстановление после сбоев. Канареечные релизы. Команда SRE-инженеров, которые 24/7 смотрят в дашборды. Это стоит как чугунный мост.

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

Вы все еще хотите поговорить о «видах» доступности? Это не виды. Это ценники.

Перестаньте гоняться за девятками, как за покемонами. Вместо этого задайте себе и бизнесу один-единственный вопрос:

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

Посчитайте. А потом посчитайте, сколько будет стоить переход с 99% на 99.9%. Если вторая цифра больше первой - поздравляю, вы только что сэкономили компании кучу денег и избавили своих инженеров от бессмысленной работы.

Доступность - это не технология. Это экономика. И тот, кто этого не понимает, обречен платить за свои амбиции из кармана компании.

#этобаза

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

👋И под конец недели еще одна заметка про CAP. На очередном «архитектурном комитете» какой-то юный гений выдал: «Для этого сервиса мы можем пожертвовать Partition Tolerance, потому что он будет работать в одной приватной сети».

В этот момент я понял, что в IT-индустрии победила не наука, а маркетинг.😡

Слушайте сюда, дети. Запомните раз и навсегда. Partition Tolerance (P) - это не опция в вашем конфиге. Это не то, что вы выбираете, как соус к картошке. Это не компромисс.

P - это гравитация. Она просто есть. Она неизбежна.💩

CAP-теорема - это не выбор из трех опций C, A и P. Это констатация факта: когда случается P (а он случится), вам придется выбирать между C и A. P - это не переменная, это условие задачи.

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

🔥Классический разрыв. Нож и кабель.

Самый тупой и понятный вид раздела. Экскаватор порвал оптоволокно между дата-центрами. Сгорел свитч. Администратор случайно выдернул не тот кабель. Ваши серверы в ДЦ1 больше не видят серверы в ДЦ2. Все честно, все понятно. Сеть либо есть, либо ее нет.

Когда готовиться: Всегда. Если у вас больше одного сервера. Это гигиенический минимум.

🔥Болото, а не обрыв. Медленная сеть.

Вот тут начинается настоящий ад. Сеть не упала. Она просто стала медленной. Пакеты теряются, ходят с дикими задержками. Ваш сервис посылает запрос другому, не получает ответа за 500 миллисекунд и считает, что тот умер (timeout). А тот сервис живой! Просто ответ застрял в пути. Система начинает сходить с ума, потому что она не может отличить мертвый узел от просто очень медленного.

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

🔥Узел-зомби. Процесс, а не машина.

Самый коварный вид раздела. Машина работает. Пингуется. Сеть в порядке. Но процесс, который должен отвечать на запросы, завис. Ушел в бесконечный цикл, словил deadlock или, мое любимое, ушел в long GC pause на 30 секунд. Для остальной системы этот узел - мертв. Он не отвечает. Произошел раздел, хотя физически все компоненты на месте и связаны.

Когда готовиться: Если вы пишете на языках с автоматической сборкой мусора (Java, Go, C#) или используете сложный софт, который может деградировать под нагрузкой.

Так что прекратите нести этот бред про «отказ от P». Это невозможно. Вместо того чтобы задавать идиотские вопросы про «виды P», начните задавать правильные:

🍄Как мы обнаруживаем раздел? Через какие таймауты? Как мы отличаем сбой от медленной работы?
🍄Что мы делаем, когда обнаружили раздел? Переключаемся в режим read-only? Отдаем старые данные? Показываем пользователю ошибку?
🍄Как мы «склеиваем» систему обратно, когда сеть восстановилась? Как мы решаем конфликты данных, которые возникли в разных частях системы, пока они жили своей жизнью?

Partition Tolerance - это не выбор. Это ваша работа. Ваша система надежна ровно настолько, насколько надежен ваш план на случай этого самого 'P'. А если у вас его нет - у вас нет и распределенной системы. У вас просто куча компьютеров, которые ждут удобного момента, чтобы вас подставить.

#этобаза

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

👋Меня тут HR поймал у кофе-машины. С сияющей улыбкой сообщил, что они запускают «корпоративный университет» с «индивидуальными траекториями развития» и «геймификацией». 👀

Господи, еще один крестовый поход за счастье сотрудников, который закончится ничем.

🙄Давайте я вам открою страшную тайну. Компания не должна вас учить и точка. Ее задача - зарабатывать деньги, а не выдавать вам дипломы, с которыми вы потом побежите к конкуренту за дополнительные денежные бонусы. Вся эта возня с «обучением» - в 90% случаев симуляция бурной деятельности и попытка HR-отдела доказать свою полезность.

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

Работа - это не триединство «результат + удовольствие + обучение». Это бред из глянцевых журналов для «эффективных менеджеров». Работа - это контракт: вы решаете проблемы компании, компания платит вам деньги и на этом все.

Спасение утопающих - дело рук самих утопающих. Всегда так было и будет. Рынок меняется, технологии устаревают. Если вы сами не тратите свои вечера и выходные, чтобы оставаться в форме, вы - сбитый летчик. Никакой «корпоративный университет» вас не спасет.

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

Она не курсы вам покупает. Она ставит перед вами задачи, от которых хочется выть на луну. Задачи, для которых нет готовых ответов на Stack Overflow. Она бросает вас в кипящий котел легаси-кода и говорит: «Разберись». Она дает вам ответственность за кусок продукта и заставляет вас принимать решения, цена которых - реальные деньги.

Вот это - настоящее обучение. Через боль, через ошибки, через ответственность. Компания дает вам самый ценный ресурс - сложные, реальные проблемы. А еще она дает вам доступ к людям, которые уже решали подобные проблемы. К тем самым седым архитекторам и ведущим разработчикам. Ваша задача - не ждать, пока вам назначат «ментора», а пойти и вынести ему мозг своими вопросами.

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

💩Первое - это болото легаси. Когда вы сидите с Java 8. Любая задача — это боль. Никаких новых технологий, никакого простора для маневра. Вам скучно и вы считаете, что деградируете.

💩Второе - стена бюрократии. Вы приходите с идеей, а в ответ слышите: «Нам надо согласовать это с отделом безопасности, с архитектурным комитетом и с тетей Глашей из бухгалтерии». И ваша инициатива тонет в болоте корпоративных процедур. Поздравляю, вы работаете в корпорации.

И если компания - это болото и стена одновременно, то давайте без соплей, у вас ровно два пути.

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

🚀Путь второй: Беглец. Если вы понимаете, что любые ваши действия тонут, что менеджменту плевать на результат, а единственная цель - досидеть до пятницы, то ответ один: бегите. Вы приходите домой и вместо сериалов открываете документацию. Вы делаете пет-проект на той технологии, которую хотите освоить. Вы ходите на собеседования, даже если не собираетесь уходить прямо сейчас, - чтобы понять, чего вы стоите на рынке. Вы инвестируете в себя, потому что ваша компания в вас инвестировать не собирается.

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

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

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

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

Смотрю, мой последний пост про обучение разнесли по паре каналов. Спасибо, конечно, за трафик коллегам из @TrueTechArch и канала @mialinist.

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

Давайте еще раз, для тех, кто в танке, медленно и по слогам. Тема многогранная, так что для начала определимся с терминами.

Есть два типа «обучения». И вы их постоянно путаете.

🔥Тип первый: «Промывка мозгов» под видом развития.
Это когда компания учит вас своим внутренним процессам, фреймворкам, продуктам. DocHub в Сбере, какой-нибудь проприетарный ETL-инструмент в банке, хитрая админка интернет-магазина.

Вы должны понимать: это не ваше обучение. Это инвестиция компании в свое будущее, а не в ваше. Она делает из вас ходячий мануал к своему кастомному велосипеду. Это знание абсолютно неконвертируемо. Как только вы уволитесь, оно превращается в тыкву. Вы не сможете прийти на рынок и сказать: «Я эксперт по внутренней CRM "Рога и Копыта", платите мне в два раза больше». На вас посмотрят как на идиота.

Вы становитесь носителем информации, полезной только одной-единственной конторе. Это не делает вас дороже. Это делает вас удобнее. Правда только для них.

🔥Тип второй: Обучение, за которое платит рынок.
Это знание фундаментальных технологий и подходов. Kubernetes, Go, Rust, системный дизайн, теория ограничений. Это то, что вы можете вписать в резюме и получить +30% к офферу в любой другой компании.

А теперь включите голову и ответьте на один вопрос: с какого перепугу компания должна оплачивать вам ваш будущий побег к конкуренту?

Facebook не «учил» мир ReactJS из доброты душевной. Они создали стандарт, выкинули его в опенсорс и получили бесконечный рынок специалистов, которые сами себя подготовили за чужой счет. Это гениальный ход, а не благотворительность. И они не одни такие.

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

А первый тип - это не обучение. Часто это технологическое сектантство. Вас заставляют поверить в уникальность и незаменимость внутренних инструментов, чтобы вы боялись смотреть по сторонам.😳

И вот еще что. Пока вы работаете руками - пишете код, настраиваете пайплайны - все просто. Можно пойти на курсы, прочитать книгу. Но как только вы переходите на следующий уровень, где надо работать головой, - архитектор, тимлид - правила меняются.

Здесь ваше главное обучение - это не курсы. 💯Это практический опыт на сложных проектах. Ваша ценность - это шрамы от решенных проблем. Вам нужна компания, которая не книжки вам купит, а даст возможность сесть за штурвал и, возможно, разбить к чертям пару кораблей. А потом заставит их чинить.🫡

Перестаньте искать компанию-няньку. Ищите компанию, которая даст вам реальные, сложные задачи. Только так и растут. Все остальное - иллюзия.

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

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

👋Наткнулся на крик души: системные аналитики не нужны. Мужик прав, но не видит корня проблемы.

Настоящая болезнь - расчленение инженера.

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

🍄Аналитик - это «эксперт по месту разреза», если уходить в медицинскую терминологию, который никогда не держал скальпель. Человек-диктофон. Человек-переводчик, который часто не знает ни одного из языков, с которых пытается переводить. Прокладка, генерирующая шум и сломанный телефон.

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

Хотя кто-то скажет: "Разделение ролей = разделение ответственности: это не баг, а фича"💩

Знаете «хорошего аналитика»? Скорее всего, это будущий продакт или архитектор, который по ошибке носит этот шильдик. Исключение, подтверждающее дебильность правила.

А кто сшивает этого Франкенштейна? Архитектор. Единственный, кто еще помнит, как выглядит целая машина.🙄

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

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

👋Опять позвали на «аудит».

Картина маслом: команда в огне, тикеты летают, CI/CD гудит без остановки. Продуктивность, мать ее.

Только вот продукт еле дышит.

Хватит читать статьи про Agile. Возьмите старую книгу «Цель» Голдратта. Да, она про завод, но там больше правды о вашей работе чем в этих модных книгах про Agile. 💯

Запомните раз и навсегда: результат всей вашей команды равен производительности самого медленного ее звена и точка.

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

Так что хватит этой имитации. Вот вам план:

- Найдите одно узкое место. Человек, система, процесс - неважно.

- Заставьте его работать на 100% полезной мощности. Защитите от всего.

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

Перестаньте суетиться. Найдите то, что вас реально тормозит, и убейте это. Все остальное - пустая трата времени и денег.

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

#интересное

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

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

И знаете, что я об этом думаю? Это одновременно и прекрасно, и ужасно.

Прекрасно — потому что это глоток здравого смысла среди всего этого карнавала с DDD, Clean Architecture и гексагонами, которые пихают в каждый CRUD-сервис на три с половиной ручки.

А ужасно — потому что сама потребность в такой «инструкции» — это диагноз всей нашей индустрии.

Человек пытается написать простую, внятную поваренную книгу. А знаете, почему она нужна? Потому что 90% команд разучились жарить яичницу, но пытаются повторить рецепт из мишленовского ресторана. Начитаются Фаулера, насмотрятся докладов и тащат в свой проект репозитории, юзкейсы, адаптеры, порты...

В итоге простейший сервис превращается в монстра из десятка слоев абстракций, где для изменения одной строчки SQL надо поправить семь файлов. И все это не для пользы дела, а для строчки в резюме.

🔥Так вот, запомните. Хорошая архитектура — это не та, в которую нечего добавить, а та, из которой нечего убрать. Ваша задача — решать проблему бизнеса, а не строить собор по всем канонам.

Начинайте с тупого монолита с пакетами по фичам (`feature-based layout`). Когда реально понадобится — вынесете интерфейс, добавите слой. Не раньше.💯

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

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

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

👋Сижу вчера на ревью архитектуры. Команда гордо презентует новый сервис: Kubernetes, Istio, асинхронщина через Kafka, база - какая-то модная NoSQL дичь, название которой я даже запоминать не хочу.

Спрашиваю: «Какая нагрузка планируется?».
Ответ: «Ну, человек 50 в день... но мы готовимся к скейлу!».

В этот момент мне захотелось выйти в окно.

Давайте начистоту. Это не проработка архитектуры и не забота о будущей нагрузке. Это резюме-ориентированная разработка.

Вы тащите в проект технологии не потому, что они нужны бизнесу. А потому, что с ними ваше резюме выглядит сексуальнее для рекрутеров из Big Tech. Вам плевать, как это потом поддерживать. Главное - получить строчку в CV и свалить на +100к, пока этот карточный домик не рухнул.

Это не инженерия, а профессиональный саботаж.

Вы строите «Звезду Смерти» для доставки пиццы. В итоге мы получаем:

❗️Оверинжиниринг. Сложность системы растет экспоненциально, а польза - линейно.

❗️Техническую беспомощность. Когда ваш Istio отрыгнет ошибку, никто не поймет, почему. Потому что вы скопировали конфиг с Medium или Хабра, даже не читая документацию.

❗️Бюджет в трубу. Вместо фич бизнес платит за оплату облаков, которые просто греют воздух.

Хватит играть в стартаперов из Кремниевой долины.

📍Скука - это надежность. Скучный монолит + PostgreSQL вывезет 99% ваших задач.

📍Доказывайте необходимость. Хочешь Kafka? Покажи мне метрики, где RabbitMQ задыхается или где база лочит таблицу. Не можешь? Иди пиши код, а не занимайся ерундой.

📍Думайте о TCO (Total Cost of Ownership). Стоимость технологии - это не цена лицензии. Это зарплата тех бедолаг, которые будут чинить ваши «инновации» в 3 часа ночи.

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

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

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

👋Смотрю тут пулл-реквест одного героя из прошлого поста. Вижу хардкод URL-ов внешних сервисов и  бизнес-логику, намертво вшитую в контроллер, вперемешку с сырыми SQL-запросами.

Спрашиваю: «Какого чёрта? Где абстракции? Где конфиги?»
А он мне с умным видом: «YAGNI! You Ain't Gonna Need It. Зачем усложнять сейчас, если нам это может не понадобиться?»


YAGNI - это не индульгенция на говнокод. И это не оправдание для вашей лени.

Вы превратили полезный принцип в религию идиотизма. Вы путаете функциональную избыточность (делать фичи, которые не просили) и архитектурную гигиену (разделять ответственность).

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

Давайте запомним простые истины:

📍YAGNI это про то, что делает код, а не про то, как он написан. Код должен быть чистым всегда.

📍Hardcoded strings - это технический долг, а не упрощение.

📍Разделение ответственности (SRP) не нарушает YAGNI. Это база, которая позволяет проекту выжить.

Ваша «простота» сегодня - это паралич разработки завтра.

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

Поделитесь это только у меня такие великолепные дарования, или это беда есть у многих.

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

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

👋Прилетает мне тут на днях инвайт: «Рабочая группа по унификации микросервисов». В участниках - 15 человек. Трое пишут код, двенадцать - имеют «ценное мнение».

Я отклонил встречу. Я и так знаю, чем это закончится.

Рабочая группа - это эвфемизм для коллективной импотенции.👀

Это самый надежный способ похоронить любую инициативу. Вы собираете толпу людей с разными интересами, разным уровнем компетенции и (самое страшное) с отсутствием персональной ответственности.

Знаете, что вы будете делать следующие три месяца? Вы будете спорить о цвете кнопок и отступах в JSON-е. Вы потратите сотни человеко-часов на «выработку консенсуса», который никому не нужен.

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

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

Вот несколько пунков чтобы перестать имитировать бурную деятельность и начать работать:

📍DRI (Directly Responsible Individual) или смерть. У любой задачи должна быть одна фамилия. Если за задачу отвечают двое - за неё не отвечает никто. Назначьте ответственного, дайте ему полномочия посылать советчиков лесом и спросите результат.

📍RFC вместо митингов. Хочешь предложить изменение? Не созывай группу. Напиши документ (Request for Comments). Четко, письменно, с примерами. Пусть остальные оставят комменты асинхронно. Нет документа - нет обсуждения.

📍Правило «Минус один». Если на встрече рабочей группы вы не можете сказать, кто здесь лишний - значит, лишние здесь все. Оптимальный размер группы для принятия решений - 3 человека. Максимум - 5. Всё, что больше - это уже митинг-ток-шоу.

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

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

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

👋 На днях ко мне подходит техлид соседней команды. Глаза горят, руки трясутся от возбуждения. Предлагает переписать стабильный, годами работающий модуль отчетов на Rust.

Я делаю медленный глоток кофе, смотрю ему в переносицу и задаю всего два слова: "Чтобы что?"

И всё. Воздух выходит, плечи опускаются. В глазах - немая обида. Он считает, что я - душный дед, токсичный бюрократ и убийца инициативы и что я просто издеваюсь.🤬

Давайте проясним раз и навсегда.

«Чтобы что?» - это не пассивная агрессия. Это главный инструмент инженерной гигиены.🚀

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

Вы привыкли измерять работу в «стори-поинтах» и закрытых тикетах. Вы путаете движение и результат. Вам кажется, что если вы три недели прикручивали Kafka туда, где хватило бы HTTP-запроса - вы молодцы.💩

А я вижу другое: вы сожгли 1,000,000 рублей, чтобы усложнить систему и добавить новые точки отказа.

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

Как отвечать на этот вопрос, чтобы я от вас отстал (и даже зауважал):

1️⃣Говорите на языке денег, а не хайпа.

Плохо: «Нам надо внедрить GraphQL, потому что REST устарел».
Хорошо: «Внедрение GraphQL сократит трафик в мобильном приложении на 40%, и мы перестанем терять клиентов с плохим интернетом».

2️⃣Доказывайте через проблему, а не через решение.

Не «давайте перепишем код», а «текущий код падает при 1000 RPS, мы теряем заказы, рефакторинг поднимет планку до 5000».

3️⃣Имейте смелость признаться.

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

Перестаньте видеть в вопросе «Чтобы что?» личное оскорбление. Это спасательный круг.

Я задаю его сейчас, чтобы через полгода, когда всё рухнет, бизнес или инвестор не спросил вас: «А зачем вы вообще здесь нужны?».

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

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

👋Сижу, пью эспрессо и листаю очередную презентацию от «бизнес-архитекторов». Слайды красивые, спору нет. Красивый зеленый квадрат «Омниканальные продажи». Рядом - «Единый профиль клиента». И, конечно, гвоздь программы - карта капабилити. Выглядит как меню в дорогом, но отвратительном ресторане. Никаких конфликтов, никаких гонок состояний, никаких распределенных транзакций. Рай.

А теперь спускаемся с небес на землю.

Тот самый «Единый профиль» в реальности - это пять разных баз данных, которые синхронизируются скриптом на Perl, написанным уволенным пять лет назад стажером. А «Омниканальность» падает, если одновременно зайти с айфона и через веб, потому что ваш легаси-монолит сходит с ума от двух сессий.😠

И вот что я вам скажу. Вся эта ваша бизнес-архитектура - в 90% случаев карго-культ и профанация.

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

Это интеллектуальная мастурбация. Команды неделями, а то и месяцами, спорят о названиях кубиков, вместо того чтобы решать реальные проблемы. 💩

Пока вы двигаете пиксели в PowerPoint, конкуренты выкатывают фичи. Ваши красивые схемы превращаются в пыльный артефакт, который достают раз в год, чтобы показать новому C-level, как у вас «все по уму».

Карта капабилити - это не стратегия. Это даже не карта. Это просто список существительных. Она не отвечает на вопрос «как?». Она не говорит, где у вас пожар, а где - болото. Это инструмент для тех, кто боится испачкать руки в коде и процессах.

Хватит рисовать. Начните говорить с людьми.

🔍Вместо карты «капабилити» соберите карту проблем. Где болит? Где мы теряем деньги? Где клиенты от нас уходят? Вот ваша архитектура. Она должна быть не про абстрактные «способности», а про конкретные «боли» и способы их лечения.

Перестаньте играть в стратегов. Будьте инженерами.

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

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

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

И тут мне на глаза попадается анонс  от моих друзей и коллег True Tech Arch 8.

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

Но тут есть нюанс. Arch Kata.

Организаторы, похоже, решили включить голову. Вместо того чтобы просто кормить вас слайдами, они заставляют работать. Выдача кейсов, решение, защита. Это, черт возьми, прекрасно. Архитектура - это не рисование стрелочек в Draw.io, это умение принимать решения в условиях неопределенности и защищать их перед теми, кто хочет вас закопать.

Программа на 10 декабря такая:

- 17:00: Сбор, кофе (ладно, кофеин нам нужен).
- 18:00: Парочка докладов. Надеюсь, без воды.
- 20:00: Самое "мясо" - защита проектов Arch Kata.

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

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

Но лучше прийти. Нетворкинг там, говорят, будет. Шанс найти адекватного инженера среди толпы «скрам-мастеров» сейчас на вес золота.

Ссылка на регистрацию где-то внизу. Не тупите. К сожалению я лично не смогу посетить данное мероприятие, но на следующем я думаю буду присутствовать.

Регистрируйтесь!

#интересное

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

👋Сижу, разгребаю очередную «архитектуру» стартапа. Ребята распилили монолит на двадцать кусков, а теперь с ужасом поняли, что данные разъехались, как ноги коровы на льду. И теперь, чтобы все хоть как-то работало используют Saga Pattern.

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

Вы правда думаете, что Хореография (Choreography) - это красиво? Это когда сервисы перекидываются событиями, как горячей картошкой. Сервис А списал деньги, крикнул в Kafka, Сервис Б услышал (или нет), попытался зарезервировать товар... Ой, ошибка. А Сервис А уже забыл, что он вообще что-то списывал. 💩

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

🔹Оркестрация (Orchestration) чуть лучше. Вы ставите надсмотрщика (Оркестратор), который пинает сервисы. Но теперь вы создали «Божественный сервис», в котором зашита вся логика. Поздравляю, вы переизобрели монолит, только теперь он тормозит по сети.

🔥И самое сладкое - компенсирующие транзакции. Помните из универа четыре волшебные буквы: ACID? Конкретно одну из них - «I», Isolation, «Изоляция»? Это когда грязное белье одной транзакции не видит другая. Все происходит как бы в вакууме. Так вот, в вашем распределенном шапито этой буквы нет со всеми вытекающими.

Что с этим делать:

1️⃣Избегайте распределенных транзакций любой ценой. Если два действия должны быть атомарны - держите их в одном сервисе и одной БД.

2️⃣Если прижало - выбирайте Оркестрацию. Вам нужен лог состояния, чтобы понимать, на каком шаге все рухнуло. Хореография годится только для примитивных событий «пожар-забыл».

3️⃣Идемпотентность - это религия. В распределенной среде сообщения дублируются. Если ваш сервис спишет деньги дважды по одной Саге - вас уволят, и правильно сделают.

Не усложняйте. Распределенная система - это не достижение, это геморрой, который вы сами себе создали.


#этобаза

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

👋Сижу, пью свой утренний американо. Всё как обычно. Тихо, спокойно, мозг еще не включился в режим тушения пожаров. И тут в корпоративный чат падает оно. Объявление, полное фальшивого восторга и эмодзи с хлопающими ладошками: «Наш Сеньор Хуан Помидор едет на главную IT-конференцию года с докладом о том, как мы победили энтерпрайз!»

Давайте я вам, дети, расскажу, что такое современная IT-конференция.💩

Это не храм знаний. Это даже не рынок обмена опытом. Это гигантская ярмарка тщеславия, где одни делают вид, что учат, а другие - что учатся. И всё это за чужой счет.

❗️Главный экспонат - спикер. Вчерашний инженер, который вдруг решил, что его умение настраивать K8s - это сакральное знание. Ментально этот человек выпадает из команды на месяц. Он больше не решает задачи бизнеса. Он «готовит слайды» и «репетирует перед зеркалом». Он превращается из инженера в инфоцыгана.

Компания оплачивает ему всё: перелет, отель класса «я-слишком-хорош-для-хостела», суточные и полную зарплату.

А что взамен? Иллюзия «прокачки HR-бренда». Мифическая вера, что джуны в зале тут же захотят к вам работать.

На практике компания инвестирует в то, чтобы сотрудник красиво упаковал себя для рынка и получил +$500 к офферу от конкурента, который клюнет на строчку «Спикер на крутой конфе».

И пока этот «евангелист» вещает со сцены про космолеты, у него в проде падает сервис. Его команда, матерясь, разгребает техдолг, который он оставил, потому что был «занят слайдами».

А что с залом?

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

Раньше привозили мировых звезд - Фаулера, дядюшку Боба. Это был глоток воздуха. А сегодня? Локальные спикеры, которых ты и так встретишь на любом митапе или в YouTube на x1.5 скорости бесплатно.

Самыми честными остались бесплатные митапы от компаний.

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

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

✅Инженеру: Хочешь на сцену? Не вопрос. Но рассказывай не про то, как ты прочитал книжку по DDD, а про то, как вы полгода внедряли его, трижды упали, потеряли данные и набили шишки. Покажи шрамы, а не глянцевую обложку. Твой доклад должен быть «посмертным вскрытием», а не рекламным буклетом.

✅Руководителю: Прекрати отправлять людей на «отдых» под видом обучения. Задай сотруднику после конференции один вопрос: «Что конкретно мы внедрим в работу завтра?». Если в ответ тишина - ты спустил бюджет в унитаз. Лучше купи команде подписку на O'Reilly или курсы у реальных практиков.

Настоящее развитие происходит не в конференц-залах, а в IDE, в код-ревью и в отчетах об инцидентах. Всё остальное - театр.

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

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

👋На днях наткнулся на интересный проект — OpenIDE . Позиционируется как «наша новая открытая среда разработки».

Что это по факту? Взяли IntelliJ IDEA Community Edition, вытряхнули из неё всю телеметрию и проприетарные компоненты JetBrains, а затем прикрутили обратно то, без чего современный Java-разработчик чувствует себя голым: поддержку Spring и Docker.
То есть, по сути, нам вернули часть функционала платной Ultimate-версии, доступ к которой для нас сейчас, мягко говоря, затруднён.

Но давайте без иллюзий. Это не революция. Это реакция.

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

Все эти пляски про «серверы в России» — это не про удобство разработчика. Это про снижение рисков для бизнеса. Теперь ваша IDE ходит за плагинами не в Прагу, а, условно, в Мытищи. Это важно для юристов, но это не повод для инженерной эйфории.💯

Если вы работаете в энтерпрайзе, банке или госсекторе — для вас этот инструмент скоро станет стандартом де-факто. Он снимает головную боль с безопасников. Но вам нужно оценить его с позиции инженера: стабильно ли работает? Не тормозит? Все ли нужные плагины есть в их локальном маркетплейсе?

👉Делитесь мнением: кто уже пробовал? Как ощущения? И есть ли тут те, у кого в компании переход на отечественную IDE уже стал обязательным требованием?👈

#интересное

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