Архитектура архитектуры. Шаг 6: Ежедневный стэндап

    Продолжение. К предыдущим постам и карте цикла.

    Будни разработчика. Цели определены, направления выбраны, задачи разжеваны. Нужно просто писать код и жевать кашку. Что может скрасить серость и однообразность существования? Конечно же daily standup - шоу, в котором есть место для каждого! Ну вот эти вот неожиданные «я посмотрел архитектуру и там ошибка» или вот «я добавил новый модуль, который нам может пригодиться в будущем» ну и, конечно, «я сделал всё проще и быстрей». Мы ведь именно ради этого делаем все церемонии груминга и планирования. Чтоб как бы подготовить почву и дать всем время посидеть молча и подготовить эти панчлайны на конец спринта. А самое обидное, что, потратив столько усилий, на сам стендап вы обычно не попадаете и панчи вам передаёт ваше начальство.

    https://www.flickr.com/photos/cosmic_flurk/5712236914@CCL
    https://www.flickr.com/photos/cosmic_flurk/5712236914@CCL

    В чём интрига? В самой сцене. В самом начале дня у нас обычно дейли разработчиков. Там все делятся успехами и проблемами. Охотно так делятся. Долго и много. Как раковые клетки. Даже анализы можно делать. Чем больше тем на этом daily, тем больше опухоль в проекте. Потом придётся выжигать и резать. Но команд много, а архитектора мало. Поэтому его не зовут, если не уже дымится.

    Дальше отсеиваются разработчики и в следующий тур идут только тимлиды. Они более практичны и рассказывают о своих успехах и как всё по плану, а проблемы выносят в оффлайн. Сухо так и без шуток. С dev. менеджером обычно всё позитивно, если менеджер сам не станет копать или не возникнет подозрение о том, что дедлайн слишком близко к носу. И так как начальник - человек занятой (его каждый раз кто-то занимает, но, как ни странно, каждый раз и отдаёт), команд много и проекты глобальные, то представитель от каждого сайта (ротация среди лидов) подключается к общему митингу, куда обычно и приглашают архитектора. Это самые бесполезные пол часа. Каждый уже пару раз рассказал свою историю и пережевал проблемы (а тут, видимо, как и с шутками: проблема, повторенная дважды, перестаёт быть проблемой). Вдобавок говорить то на английском надо, который для большинства неродной и куча акцентов… Короче, каждый chosen one пытается сказать одно-два предложения, так чтоб не дай бог не задали вопросов. Как на приёме в налоговой.

    Сетка игр в дейли
    Сетка игр в дейли

    В итоге каждая команда поделилась своими проблемами только с собой. Оставшись внутри закрытого спектра бизнес-задач и решений, которые знакомы всем её участникам. Я не против психотерапии, но если у вас проблема и вы можете решить её внутри команды, то зачем ждать планёрки? А если не можете то, чем поможет её озвучить в том же кругу? Но я не менеджер и даже не Agile тренер – мне не понять. Я - Винни Пух и по утрам хожу в гости. К кому-нибудь. Желательно без приглашения (иначе рискуете услышать заученный текст на английском) на ту самую первую сцену, где профилактика будет стоить дешевле лечения. Это здорово экономит время, так как альтернативой будет просмотр коммитов. Код ревью – тот же рыбий жир. Может и полезно, но никто не любит. Любят мёд. Но мёд, как известно, странный предмет – он есть лишь там, где тебя нет.

    Поправка на ветер

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

    Из личного опыта: иногда доходит до абсурда. Был проект, где архитектором была девушка. А on-site менеджером в далёком стане усатый седой дядька с чалмой. Так вот пока кто-то из команды архитекторов-мужчин не посылал мейл: «сделай как она сказала» - раджа игнорировал все её заметки. Культур такой. В общем мудрый раджа оказался тем ещё мудрилой.

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

    Первые конфликты требований не заставят себя ждать. Проблемы сами по себе очень пунктуальны – никогда не запаздывают и даже стараются встретиться с вами пораньше. Мои наблюдения за природой событий подсказывают, что источником часто являются благие намерения и ограниченные знания (слабоумие и доброта). Чем меньше знаешь деталей, тем радужней и проще картинка. Поэтому клиенту обещают чуть больше и чуть раньше. Даже если не официально. Чтоб зарекомендовать себя, выиграть лишний бал для торгов на следующей фазе или обезопасить дедлайн/качество, насильно передвинув срок сдачи на пару недель раньше. Ну чтоб оставить чуток на допилинивание и стабилизацию. Спринт на закалку. Английское «харденинг» более уместно. Как только начинают двигать дедлайны взад-вперед, сразу же чувствуется харденинг. И если дёргать дальше, то проект может плохо кончить. Те же хорошие мысли подталкивают участников процесса добавить немного еще функционала из серии «чтоб два раза не ходить». Такие вещи из бэклога, которые в том же куске что разрабатывается сейчас и весят мало. И как бы проверками их покроют всё равно и код уже открыт на нужном месте. Мелкие задания. Пару часов тут, пару часов там и вот уже появляются первые участки дороги в ад инженера.

    7 фишек этому господину!
    7 фишек этому господину!

    Ад у каждого свой. Мой похож на ежедневные диспуты с начальниками разных отделов, каждый из которых предлагает «вместо твоей глупой инфраструктуры, давай сделаем анимированные кнопочки». Случалось же слышать: «а юнит тесты точно нужно писать? А может можно как-то без них?» или «нам же сейчас не нужно это твоё скалкобилити, а красивый интерфейс – это лицо продукта». Хорошее лицо тоже важно, но этот орган плохо поглощает кинетическую энергию и при встрече с бетонной реальностью лучше приземлиться на пятую точку. Особенную нишу занимают «вот тут 20 дней на безопасность выделено, нужно сделать за 10, чтоб ещё пару фишек втиснуить» из бессмертной серии «а семь шапок можешь?». Мне всегда сложно объяснить кому-то почему же 2+2 = 4. На сложные вещи аргументация всегда находится, а как объяснить то, что ты считаешь базовым, да еще и когда экспериментально доказать за 5 минут не получится.

    Флешбэнг

    Вспоминается лектор в универе по линейной алгебре, который заставлял писать на экзамене типа «один из результатов 2 + 2 будет 4. Точное определение операции сложения и поля чисел, на котором эта операция произведена указаны ниже». В противном случае сам давал произвольное определение так, чтоб 2+2 было 4+С или допустим (+4;-4) и не засчитывал ответ. Я тогда бесился, но похоже препод был настоящим инженером. Не даром его книги продают в переводах на несколько языков. Даром пишу тут я и пытаюсь передать его мысль: решений зачастую больше, чем одно и в разных условиях правильными могут считаться разные варианты.

    Чтобы понизить градус ада приходиться заниматься презентациями, которые бы наглядно показали «как у нас всё работает и почему». Хочется, конечно, Босха, но приходится сводить простые зарисовки со стрелочками. Анализировать бэклог, искать пересекающиеся требования и показывать, что «кнопочки сейчас» по затратам равны «кнопочки завтра», а «безопасность сейчас» намного дешевле «безопасность завтра». Строится цепочка требований ведущих или исходящих из кнопочки и такая же для требования безопасности. Так как бизнес-требования обычно не пересекаются, то цепочку таких требований легко двигать в плане вперёд и назад. А значит и цена будет неизменной. Инфраструктура же пронизывает все модули и цепочки, а значит если завтра будет в 10 раз больше модулей, то будет и в 10 раз больше интеграции/внедрения и проверок (важная статья расходов и времени). Кто бы мог подумать!? И обязательно гуглите что-то из серии «цена ошибки безопасности» в своём промышленном/деловом секторе. Для производства всегда хорошо работает пример Иранских центрифуг. В финтехе или ритейле примеров полным-полно. Хорошая страшилка лучше любых формул. Детей пугают сказкой про волка, а не расчётами семейного бюджета (хотя последнее может быть намного страшней).

    инфраструктура шашлыка
    инфраструктура шашлыка
    На моей памяти

    Лет 10 назад из наших клиентов – лидер в своём секторе в развитой европейской стране, спустился на пару пунктов в рейтинге и обороте после того, как его взломали. А другой наш клиент, бывший на третьем месте незамедлительно вложил тройной бюджет в безопасность и в том же году возглавил рейтинг. Хотя по размеру и размаху он раза был в 4 меньше. Сейчас проверил, они спустились на второе место, но с хорошим отрывом от их прежнего третьего.

    Вот прошли вы семь кругов дневных совещаний и можно начинать работать. Ваша компания выиграла большой тендер в том числе и благодаря волшебной пыли, которой вы сдобрили своё видение решения в документах и диаграммах. Кто и как употребляет эту пыль не наша забота. Контракт подписан и пора её сдуть со всех чертежей. Под пылью много пустых мест, которые как раз сейчас время заполнять. Заполнять, конечно, можно с фантазией – в начале всё легко исправить и цена ошибки минимальна. Поэтому я советую подключать к проектированию модулей инфраструктуры самих разработчиков. Если хорошему программеру выдать конечный результат в стиле «сделай вот так», то он может и сделает, но осадочек то останется. Основные узлы строят специалисты и у них есть свое мнение, которое они хотят высказать не просто в стену, а чтоб их услышали. Это не плохо, но я люблю дело делать, а не говорить и слушать. Умел бы слушать и говорить играл бы в тиндеры, а не в тендеры. Да и мнение ключевых специалистов я уже выслушал, когда строил наброски и готовил решение. Теперь, когда всё утверждено и подписано, начинать с начало как минимум не практично.

    Мой know-how в этом процессе – направляемый мозговой штурм. У вас есть готовый вариант архитектуры модуля. В моём случае это значит, что определена модель (абстракции) и контракты (данные) и есть сопутствующая диаграмма взаимодействий или сущностей. Так вот эту диаграмму я начинаю строить с разработчиком, скармливая ему требования и проблемные аспекты так, чтоб он посмотрел в конце на моё решение и сказал «классно мы с тобой придумали!». Ну ещё бы.

    Работает это примерно так:

    Нужен модуль, который получает пакет цифровых документов и мапит их в базу. Разработчик сразу предлагает какой-нибудь pub-sub, асинхронные (так почему-то 80% людей называют параллельные процессы) таски и пару микросервисов. Куда же без них.

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

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

    второй предложенный вариант
    второй предложенный вариант
    Про параллельность

    Иногда пропускают мимо глаз, ушей и, в конечном счёте, рук проблемы последовательных запросов, перерастающих из очереди в параллелизм. То есть с точки зрения бизнеса там всё в строгом порядке и один за одним. Классический (уже для меня) пример – обработка конвейера. Вот есть производственный конвейер, на ленте которого изделия идут на следующий этап, а рядом есть камера, которая снимает каждую деталь для обработки данных в какой-нибудь отдельной системе. Система эта и камера – отдельный продукт для мониторинга и в производстве не участвует, так что лента никого не ждёт. Потом наступает тот самый неочевидный момент, когда скорость ленты выше скорости обработки изображения. Бегущие напрямую в бэкенд запросы идут внахлест. Закон Литтла в действии. И если никто об этом не подумал, то у нас будут всё прелести конкуренции за ресурс, превратившийся из эксклюзивного в общий.

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

    конечная
    конечная

    За шага 3-4 мы уже достигаем желаемого результата. В отличии от варианта, когда вы просто объясняете почему стоит сделать именно так, вы не лишаете человека самого важного – поиска решения. Разработчик не стенографист и не стал экспертом потому, что просто быстро записывал за кем-то построчно. Если лишить его загадки, то работа может вызвать протест и кучу отрицательных эмоций. С другой стороны, он не знает всей картины. Ни того, что и как будут делать в других командах, ни того, что запланировано на полгода вперёд. В этом основная причина существования должности архитектора – широкий и далекий взгляд на проект. Но ничего не получится, если ваша архитектура не обоснована требованиями. Нечем будет вести разработчика, да и незачем.  В таком случае лучше честно партбилет на стол. У нас с этим строго. Это по утрам я Винни-Пух, а к концу дня я – свинья с ружжом!

    архитектор бьёт чучелом ружья вымышленного леопарда
    архитектор бьёт чучелом ружья вымышленного леопарда

    И стрелять всегда есть в кого. Пока все усердно пишут код нужно следить, что б всё неусерднулось. Тут на помощь нам всякие индикаторы и статические анализаторы кода. Делать метрики для программистов – удел менеджеров. Я лично озабочен метриками кода. Индикаторы здоровья проекта:

    • Отсутствие взрывного роста строк кода после первых шагов. Как только мы закончили строить базу и перешли непосредственно к бизнесу, то коммиты должны быть частыми и небольшими. Меньше кода – практически всегда, лучше код. Поэтому если кто, то навалил кучу, то скорее всего там проблема с заданием и расхождением с линией архитектуры.

    • Длинные функции и классы – не плохой индикатор поспешной работы и костылей. На начальном этапе такого быть не должно.

    • Сложность кода можно отследить по количеству юнит тестов при высоком покрытые.  Много тестов – значит много веток, а значит опять что-то попахивает.

    • Нарушение конвенций тоже стоит заавтоматить и следить. Закладывается фундамент дома, в котором нам всем жить долго.

    • Много статики (классов, методов, полей), обычно, проявления антипаттернов.

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

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

    Для подготовки к следующему этапу необходимо выстроить хороший механизм логирования. Желательно на два уровня – один с понятной историей для бизнеса, а второй для технического анализа, что же всё-таки навернулось. Когда со стадии демо мы шагнём, пусть и в ограниченный, но production, то там будут первые кострища и охота на ведьм. Наблюдать в полнолуние как кто-то седеющими руками набирает код прям в проде – плохая примета. По возможности старайтесь избегать этого. Так что одним стримом пишем: «пользователь ****341 запросил функцию «Поиск Заказа» с аргументом 3480-4341-1334. Результат: не найдено». На этот лог сядет саппорт, когда процесс встанет. А второй стрим со стеком, сервисами и всеми деталями (опять-таки, кроме тех, что нужно замазать ради безопасности или для сохранения личных и коммерческих секретов). Тут уже пойдут разработчики, когда процесс ляжет. Логи делать необходимо с самого начала. Они всегда нужны вчера, когда всё случилось, а вот завтра от них будет мало толку. Клиент как-то не любит слышать: «У вас тут вчера производство встало, а мы не знаем почему. Но когда встанет в следующий раз у нас будет больше данных для анализа!». Хотя в некоторых компаниях лишь под угрозой штрафов начинают понимать, что стоило вложиться сразу в аудит и мониторинг да начинают чесать головы (те в которые едят и те на которых сидят).

    Мысль вслух

    Есть разные архитекторы. Сейчас самый хайповый – архитектор решений. А нужен то архитектор проблем. Тот, кто предскажет нестыковки и видит конфликты. Опытный разработчик справиться с решением любой правильно поставленной задачей и сам. Архитектор необходим чтобы сделать задачу правильной и полной (не бодипозитивной, а с жирными мазками в местах болевых точек и сочным описанием того, что случиться, если на точку нажмут). Мне не важно пустой ли на половину стакан или полный. Мне важно определить, что значит «половина» и, что стакан будет в том месте и времени, когда начнут лить. И стоит уточнить, что лить будут не серную кислоту в бумажный стаканчик.


    Комментарии 10

      +3

      Мне очень понравилось. Сразу стало понятно, чем человек занимается, и какие навыки нужны (предыдущие статьи еще не читал)

        0

        Кстати о Дейли, мы тут как раз про них записали выпуск подкаста: https://newpodcast2.live/podcast/estimates-and-dailies/

          +2

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

            0

            У нас очень разные стороны, мне кажется. Я вот выступал с разных сторон — я вообще не люблю дейли. Но в конце я делаю много важных оговорок и говорю о том, когда и кому в реальности может быть полезен дейли (просто для спора удобно занимать экстремальную позицию, а не мягкую).

          –1
          Какой-то поток мыслей с деталями человека с ежедневной рутиной. Что сказать-то хотел? Ни ввода с проблемами, ни выводов…
          Я тут экспериментирую со стилем

          Ах, вот оно что! Предупреждать вверху надо.
            0

            Предупреждать о том, что есть 5 частей до этого в начале, означает, что все просто пройдут мимо. С другой стороны раз вы поняли, что это — ежедневная рутина архитектора, то всё прекрасно получилось.

              +1
              XaBoK а есть какие-нибудь открытые сообщетва архитекторов, где они обмениваются рутиной?
                0

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

                  0
                  Да ладно. Может конкретных практик и нет, но методология в целом остаётся прежней. Наверняка же есть структура хранения требований, типовые шаблоны и калькуляторы, опросник для определения нефункциональных требований…
                    0

                    Я работал в нескольких компаниях и знаю от друзей о еще десятке — всё на 90% разное. Enterprise — это не "ещё один стартап, который мы подняли за неделю". Корпорации живут засчёт того, что они разные — одинаковых двух рынок не выдержит. В каждой есть свой нюанс и "у нас такой стандарт". Если VW и перенял методологию Toyota, то её адаптируют под себя. Акценты другие и границы должностей. В любом калькуляторе вас не интересуют 5 переменных, что есть у всех, а те 20 которые нужны только вам. В конкретном проекте конкретной компании. Можете сравнить Cost Calculator у Azure, GCP и AWS.

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

          Самое читаемое