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

Картина маслом: команда в огне, тикеты летают, 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) архитектор🤡