Саша Раковский

Про одного CTO

Неделю назад наткнулся на канал одного CTO. Там он хвастается своим опытом: в одной из компаний за год работы техдиром результат - собрали команду в 100+ человек, поменяли процессы и переписали все на микросервисы. Читаю и понимаю, что что-то мне тут не нравится.

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

Во-первых

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

Например:
- айти принесло больше денег, чем потратило;
- количество дефектов/инцидентов в проде сократилось в несколько раз;
- или, ещё лучше, количество потерянных денег вследствие дефектов уменьшилось на сумму, меньшую, чем затрачено на исправление;
- выполнили все требования регулятора в срок.

Во-вторых

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

1. Микросервисы.

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

То есть микросервисы должны позволить команде разрабатывать, тестировать и выкатывать доработки БЕЗ синхронизации с другими командами. Поэтому границы микросервисов = границы команды. То есть, в общем случае, на одну команду достаточно одного микросервиса.

Либо, если несколько доменов, то по количеству доменов. Просто потому что, если ничего общего нет, то непонятно, зачем оно должно быть в одном сервисе. Для примера: в приложении доставки еды сервис оформления заказов пользователем и сервис изменения меню рестораном - это разные поддомены и разные сервисы. Пример из жизни: сейчас наша команда считается помойкой доменов, куда можно скинуть все, что другим негоже. Поэтому у нас уже 5 доменов и, получается, 5 сервисов. И на подходе ещё 2.

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

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

2. Процессы.

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

Цель внедрения процессов очевидна:
- Для прозрачности работы от исполнителей требуется отчётность и метрики. Например: задачки в жире, трекинг времени и статусов, обязательные артефакты в конфлюенс, обязательные оценки на полгода вперёд;
- Для снижения рисков устанавливаются дополнительные контрольные процедуры. Например, блокирующее ревью безопасником.
- Для снижения рисков сужаются полномочия. Например, отбираются доступы.
- Для равномерного распределения однообразной работы по специалистам и обмена компетенциями узкие специалисты собираются в команды. Например: команда девопс, команда тестирования, команда дба.
- Для согласованности действий подразделений планируются координационные мероприятия: рабочие группы, статусы и прочее.

Коварный недостаток XP

Сегодня уже в который раз в своей жизни услышал очень интересный "упрёк" в адрес xp, что экстремалка "портит" разработчиков. Почему? Да потому что после неё невозможно найти новую работу.

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

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

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

Что делать бедному экстремальщику, попавшему в такое трудное положение, я писал тут.

Про код-ревью

Вот уже месяц прошёл, как я пообещал написать "коротенький пост про ревью на неделе". Но, пока я в канал про программирование постил байки про автопром и предпринимательство, про само ревью все у меня нудятина какая-то получалась.

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

Ну и, по традиции, рассказываю как оно там у нас в команде.

Читать после основной статьи.

- Используем ли мы пулл-реквесты?
- Нет.

- Есть ли у нас код-ревью?
- Да, мы практикуем парное программирование.

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

- Скрываем ли мы этот факт от посторонних глаз?
- Да, объяснять, какая мотивация стоит за этим у нас нет никакого желания.

И теперь по полочкам

1. Доверие.

В нашей команде вопрос доверия - центральный. Решается он строгим входным фильтром и обучением. Абы кого я в команду не беру: всех, кто оказался в команде, я видел в работе до этого. Отобрал самых идейных фанатов автотестов и клин кода, самых ответственных и лёгких в общении. Все, оказавшиеся в команде, прошли минимум через месячный процесс обучения.

2. Контроль качества.

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

- Хватает ли нам этого?
- Не всегда. Где-то мы понимаем, что нам не достаёт инвестиций в нагрузочное тестирование, где-то ещё чего-то.

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

Интересно, кстати, что эксплицитно, как процесс ревью, это артикулируется не так часто. Чаще используются фразы наподобие:

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

Мне немного стрёмно эту штуку делать, давай вместе поковыряем?

Там сложное место, его Гриша делал. Вместе посидите, пожалуйста.

Гриш, ты там хвастался своим решением. Давай посмотрим, че ты там намутил такое.

Впрочем, нередко в конце каждой такой фразы намеренно добавляется "в паре". То ли для солидности, то ли просто из любви к искусству.

3. Обучение.

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

Итого

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

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

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

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

К чему это я все?

Такой подход - самый настоящий Lean-startup, с циклом от начала исследования до первой оплаты в несколько недель. В сравнении с безумным расточительством бигтехов и венчурных фондов тут вероятность успеха высочайшая, а риски - минимальные. Для рядового разработчика это очень хороший способ обрести финансовую независимость, перестать работать на дядю и начать работать на себя. Но, как это часто бывает, работа на себя - это нередко ещё и работа по вечерам и выходным, так что будьте осторожны со своими желаниями.

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

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

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

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

Про солопренеров

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

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

Солопренёры утверждают, что:
- отсутствие конкурентов - признак отсутствия спроса;
- подсмотреть у конкурентов, можно бесплатно, без космического бюджета на маркетологов;
- инвестируя большие деньги в продукт без клиентов, вы на выходе останетесь и без клиентов, и без денег.

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

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

Должно ли вас смущать, что таких сервисов уже десятки? Нет! Наоборот, это признак того, что там есть спрос, и все игроки зарабатывают. Это в терминологии солопренеров "зелёный рынок".

Антипримеры

1. Какой-нибудь сложный софт, который нельзя запилить в одиночку по вечерам за месяц-другой. Например, видеоредактор на телефон.
2. Какой-то сервис для неплатежеспособных школьников или приложение, у которого дофига известных полностью бесплатных аналогов, поэтому никто никогда вам не принесёт свои деньги.
3. CRM, конструкторы сайтов, какие-то маркетплейсы или ещё какой софт, где рынок уже давно не растёт, где идёт кровавая рубка среди огромных рекламных бюджетов или вовсе господствуют монолии. Это "красный рынок", он же "алый океан". В целом, само по себе, это не противопоказание, просто дополнительный риск неудачи.
4. Какая-то уникальная крутая идея, куда ещё не зашёл ни один конкурент, типа ИИ-генерированного конспекта созвонов с клиентами для практикующих психологов. Вроде бы прикольная идея, но отсутствие конкурентов намекает на то, что это просто никто не будет покупать. Такие рынки называют "голубой океан", полагая, что, в отличие от красных морей, где кровавая конкуренция, здесь настоящее раздолье для стартапов. Но, если честно, тут ближе будет метафора "ледяной пустыни".

Как конкурировать с теми, кто на рынке подольше?

У конкурентов, как правило, уже есть клиенты, у них обычно побольше продукта, чем у вас, и сам продукт уже отлажен. Базовая рекомендация тут - отстройка от конкурентов.

Возьмём для примера шаверму. Вокруг вас, вероятно, полно шаурмечных, с которыми, скорее всего, очень непросто конкурировать. Но, если вы отстроитесь от них и станете продавать, например, зож-шавуху, то, внезапно, у вас появляется своё конкурентное преимущество: ваша шаверма - это не 600ккал и утро в туалете, а 300ккал, много протеина и большая бицуха.

Отстраиваться от конкурентов в айти можно за счёт региона, канала привлечения или какой-то узкой группы пользователей. Например: можно ориентировать свой продукт именно на РФ, куда конкурент ещё не добрался; рекламироваться именно в тг, где рекламы конкурентов ещё нет; заточиться только на мамочек в декрете, потому что у них сильно своя специфика, и существующие продукты им нужны, но не совсем удобны.

А минусы будут?

Тут я обязан указать и на ограничения этого подхода.

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

Ключевое отличие заводов Тойоты бросалось в глаза: через весь завод была подвешена нейлоновая нить, которая останавливала сборочную линию. Работников GM вводило в шок, что, если болт встал поперек, они останавливали линию, исправляли проблему и запускали линию обратно.

Эта Lean-практика кстати также пришла к нам в айти и стала широко известна, как Build Quality In и Shift Left. Исправляя проблему тогда, когда она возникла, вы снижаете число пропущенных проблем, число накопленных проблем, стоимость их исправления.

Самое удивительное, что GM внимательно записала процесс NUMMI во всех деталях, но так и не смогла его воспроизвести на других своих производствах.

Про что этот пост?

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

И знаете что? Очень обидно, что эта ключевая идея Agile нигде особо не выпячивается. А ведь это его первая ценность: Individuals and Interactions over Processes and Tools.

Про Lean в естественной среде

Мои любимые экстремальное программирование и Agile зародились в девяностые на фоне всеобщего офигевания от эффективности Lean-философии в автомобильной промышленности.

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

Невероятная история NUMMI

Чтобы было представление о том, насколько Lean выглядел волшебной палочкой в глазах американцев, расскажу, наверное, про самый впечатляющий пример - про NUMMI. Это было совместное автопредприятие Тойоты и GM в восьмидесятые годы, которое GM использовало, чтобы перенять Lean-подходы Тойоты, а Тойота - как свой первый завод в США и беспошлинный доступ на американский авторынок.

Совместное предприятие открыли в 1984 году на базе бывшего завода GM Fremont Assembly, который за 2 года до этого GM закрыла, уволив тысячи работников из-за кошмарной рабочей дисциплины. Ситуация к тому моменту дошла до того, что к началу восьмидесятых работники часто не появлялись на работе, употребляли алкоголь, курили марихуану и даже прятали пустые бутылки от колы в дверных картах, чтобы они гремели во время езды и бесили покупателей. Чтобы с утра конвейер запустился, порой менеджерам приходилось утром идти в бар через дорогу и нанимать людей. В целом, сотрудники этого завода оценивались, как худшая рабочая сила в стране.

Неожиданный поворот

Тем удивительнее был тот факт, что Тойота согласилась, чтобы при запуске нового завода спустя 2 года были наняты те же самые работники. На момент открытия завода старые сотрудники Fremont Assembly составляли 85% всего персонала. Но с одним условием: весь персонал был направлен в Японию на переобучение.

И результаты были фантастическими: сразу с первых дней после открытия NUMMI частота дефектов на 100 автомобилей оказалась на уровне лучших заводов страны. По частоте дефектов машины, произведённые на NUMMI не отставали от машин, собранных на заводах Тойота в Японии. Исследователи оценивали, что на производство того же автомобиля по старым процессам GM потребовалось бы на 50% больше человеческих ресурсов.

Напоминаю, это были те же самые работники, которые до этого брали с собой на сборочную линию термос с водкой и курили в перерывах травку.

В чем же был секрет Toyota Production System?

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

Другим подходом была практика "непрерывного улучшения". Лидеры постоянно интересовались у сотрудников, как можно было бы решить ту или иную проблему. Результаты этих улучшений были заметны везде. Сотрудники GM удивлялись, что вместе с корпусом машины по заводу перемещался стеллаж с инструментами на колесиках; в местах, где работнику приходилось вставать на колени, стелился мягкий коврик; каждая операция была записана и замерена с секундомером.

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

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

Про DDD пару слов

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

Про скелеты

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

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

Альтернатива

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

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

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

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

Преимущества

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

Пример

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

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

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

По итогам исследования удалось установить статистически значимую корреляцию между субъективной поддерживаемостью кодовой базы и определённым набором архитектурных практик и подходов.

Если точнее:
- отсутствие циклов в зависимостях;
- частое использование шаблонов проектирования;
- Liskov Substitution, Open-Closed, Interface Segregation Principle;

Покрытие тестами, CQS, ER-диаграммы и некоторые другие практики дали сильную, но погранично-значимую связь (p более 0,05, но не намного).

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

Из интересного: не подтвердилась зависимость поддерживаемости кода от фп/ооп и от лондонской/детроитской школы тестирования.

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

На мой взгляд, этот отчёт поднимает следующие вопросы:
1. На что влияет субъективная поддерживаемость систем? Есть ли корреляция с DORA? Есть ли корреляция с иными важными характеристиками: например, organisational performance, non-commercial performance, employee burnout из DORA?
2. Насколько сам формат исследования действительно влияет на результат? Например, мы видим сильную и статистически значимую зависимость между LSP и OCP и поддерживаемостью кода, что, мягко говоря, вызывает некоторое недоумение. И я бы первым делом начал искать, нет ли тут ложной корреляции.
3. Какие у указанных зависимостей направления? Вроде бы логично предположить, что поддерживаемость следует из практик, но вопрос все ещё открытый.
4. Подтвердятся ли эти выводы на больших выборках? Какие практики станут действительно статистически достоверными?

Полный отчёт с сырыми данными тут.

Третья часть по автотестам. Добил трилогию самыми важными приёмочными тестами.

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

Вторая часть по тестам готова. В этот раз про юнит тесты.

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

Про надёжность 🚀

В одном замечательном банке очень любили надежность. 

Например, их смущала ситуация, что в Кафке могут протухать сообщения и заканчиваться ретраи. Поэтому они сделали специальный "надежный транспорт", представляющий из себя 2 кафки и посередине базу данных. Отправитель кладёт сообщение в один топик, сообщение перекладывается в базу данных, из которой читается по расписанию и кладётся в другой топик, откуда его читает получатель.

В итоге, взяли самый надёжный в мире брокер сообщений и, желая сделать взаимодействие ещё надёжнее, сделали его менее надёжным. А что надо было сделать? С умом подойти к настройке retention policy и retry policy, внимательно подумать над разными failover сценариями.

Или другой пример: с целью повышения надёжности всей IT-инфраструктуры банка каждый критически важный сервис (то есть, просто каждый), который взаимодействует с базами данных, обязан все данные сохранять ещё и в запасную базу данных. Чтобы, когда первая база данных умрёт, можно было переключиться на запасную. 

Тоже хотели надёжнее, а сделали наоборот. Что надо было сделать? Использовать зарекомендовавшие себя опенсурсные БД на геораспределенных кластерах.

А что плохого то?

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

Это как с автоматом Калашникова. Почему это самый надёжный автомат в мире? Да потому что он настолько простой, что там ломаться особо нечему. Ну почти.

Это правило работает всегда?

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

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

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

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

Кто подольше с каналом, тот помнит, как я рассказывал про BrightData, как пример Elite-performers, где нет пулл-реквестов, где коммит сразу после автотестов через считанные минуты оказывается в проде.

Вот ещё один такой интересный пример команды из SkyEng. Разрабы-фуллстеки (PHP, angular), пишут все виды тестов, от коммита до прома 20 минут, десяток релизов в день.

На мой взгляд, это самый топ из всех тех. процессов, что вы сможете вообще найти на рынке. The best of the best, как говорится.

Если повезёт, получится вытащить из Глеба, лида команды, побольше подробностей. Кому интересно, накидывайте вопросы в комменты.

Кстати в эту команду сейчас ищут лида-экстремальщика. Если такой есть среди нас, знай: тебя ждут.

https://t.me/teamleadleonid/525?single

Наконец, добил статью по тестам.

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

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

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

Опубликую их, как закончу с оформлением: сейчас со временем туговато, но постараюсь закончить на этой или следующей неделе.

Немного отклонюсь от основной тематики канала, но очень отзывается мне эта тема.

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

Обращаясь к более опытной и обеспеченной части своей аудитории, хочу вот какую мысль озвучить. Мы проводим на работе по 8 часов в день; кто-то больше, кто-то меньше, но, в среднем, это половина нашей жизни, без учёта сна и выходных. К тому же, это лучшие годы вашей жизни, когда вы молоды, активны и работоспособны, окружены самыми важными в вашей жизни людьми и мало в чем нуждаетесь.

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

Моё предложение: если вам позволяет ваше финансовое положение, потратьте больше времени на подбор вашего будущего коллектива и продукта, на выбор компании с хорошей культурой и процессами. И, честное слово, после 300 тысяч рублей в месяц разница в 100 и даже 200 тысяч уже не особо ощущается, поверьте. А чем ниже ваши финансовые ожидания, тем больше компаний захотят такого замечательного специалиста, и тем богаче будет ваш выбор.

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

Снова про архитектуру систем

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

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

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

Собственно, инсайт

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

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

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

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

Опять про единорогов

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

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

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

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

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

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

Вот, например, тот же Scrum. Ну изучили вы выступления и статьи Джеффа Сазерленда. Там у них все, якобы, шикарно сработало. Ну и что, это повод их копировать? Нет, конечно! Мы же не можем достоверно сказать, повлиял ли хоть как-то скрам на их успех. Может, просто такие крутые разработчики работали, которые вытащили проект.

Сейчас, благодаря State of Devops, мы точно знаем, что релизы раз в месяц и отсутствие регламентированных технических практик - это серьёзные недостатки оригинального скрама. Хотя, справедливости ради, в сравнении с распространёнными тогда водопадами оригинальный скрам был просто космическим процессом.

Но почему я призываю изучать не просто исследования всякие типа пресловутого State of Devops, но и первоисточники. Вот возьмём, например, Continuous Delivery. В том же State of Devops видно, что эта практика работает и работает круто.

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

Upd: впрочем, справедливости ради, не так важно, что было написано в оригинальной книжке, как то, что измеряли исследователи. Но даже задача найти методологию исследования - это тоже работа с первоисточником. Причём не менее трудоемкая, чем изучение книги.

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

Про опыт

- Почему ты считаешь, что это правильно?
- Потому что у меня 20 лет опыта, разве это не аргумент?

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

Про заблуждения

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

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

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

Обратно в айти

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

Довольно быстро я понял, что через все наше айти идёт испорченный телефон: идеи из оригинальных источников путешествуют в доклады и статьи, по пути мутируя до неузнаваемости. Такими "призраками" себя самих они и поселяются в головы "опытных коллег", которые не привыкли работать с первоисточниками.

Обратно к опыту

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

3.3. Continuous delivery.

Тут тоже многое может пойти не так.

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

Но Continuous Delivery возможен и без ежедневных релизов. А вот без чего он не возможен, так это без соответствующей инфраструктуры: без пайпа и без стендов, на которых вы могли бы гонять автотесты в рамках пайпа. Особенно, нагрузочные тесты. И тут техдир легко может по незнанию вам напихать палок в колёса, указав, что автотесты - это задача команды автотестеров, а пайп и инфра - задача команды девопсов. И удачи вам построить каноничный книжный continuous delivery pipeline, когда у вас нет возможности его написать, нет доступа к инфраструктуре, а девопсы ваши запросы игнорируют, считая, что вы занимаетесь какой-то фигнёй.

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

Заключение.

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

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

1. Команда.

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

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

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

Итого: хотите хорошие процессы - набирайте команду под себя. Если не дают - ищите место, где дадут.

2. Общая кодовая база.

Встречал и такое. Несколько команд работают на проекте. Весь проект тестируется совместно, код сервисов общий для всех команд - все кодят везде.

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

Итого: хотите хорошие практики - в них не должен вмешиваться никто снаружи. У вас обязана быть как минимум своя кодовая база, в которую ни у кого больше доступа нет.

3. Техдир и топ-менеджмент.

Это вообще классика. Чем слабее менеджмент, тем меньше у вас получится сделать.

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

Но вот более продвинутые и важные практики и идеи вам могут и поломать.

3.1. Работа со скоупом.

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

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

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

3.2. Культура.

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

Другой культурный аспект - это бюрократия. Это не только отчёты, оценки и прочие параноидальные обязательные процедуры. Это ещё и деление на функциональные команды: команда аналитики, команда тестирования, релизная команда, команда внедрения, команда сопровождения, команда devops. Мало кто задумывается, что такое деление - это тоже элемент бюрократии, создающий препятствия на пути движения информации и решения проблем.

Хороший управленец обязан быть мягким, аккуратным и поддерживающим. Его работа должна быть направлена на обход всех условностей и препятствий на пути к решению проблемы. Он должен стремиться сгруппировать участников процесса в небольшие крепкие рабочие коллективы, объединённые одной целью и ответственностью. Хорошая культура проявляется в заботе о сотруднике, его мотивации, интересах, комфорте и психологическом состоянии.