2024-12-08: Highload - технологии и культура

Короткая ссылка: Highload-2024

Ссылки сюда (3) →

О других конференциях

Вслед за Teamlead прошел Highload. 3500 offline участников, 15+ треков интересных выступлений и много общения, так что публиковать заметки в ходе конференции не получалось. Собираю в отчет сейчас. Отмечу, что презентации всех докладов уже доступны на сайте конференции, надо зайти в конкретный доклад, так что подробности можно смотреть.

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

Еще хочу отметить следующие выступления.

• Григорий Петров про нейрофизиологию восприятия кода, где реально раскрывался вопрос понятности и когнитивной простоты кода.
• Евгений Харченко из Райффайзен Банк про инженерную культуру, нацеленную на достижение устойчивости работы продуктов и снижение боли пользователя, pain index.
• Виталий Левченко про грейды Go-разработчика, в которых. на мой взгляд, нет специфики Go, все верно для любого разработчика-универсала.
• Максим Мирошниченко. Оптимизация конкурентных приложений: паттерны, сравнение и микроархитектура.

Читая отчет, помните, что это — очень малая часть из того, о чем рассказывали на конференции.

Наиль Миннахметов из МТС. Артефакты архитектуры. Какие, зачем и как их организовать

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

А еще они не побоялись для архитектурных артефактов за основу взять свежую методику EAoaP — Enterprise Architecture on a Page. Взяли за простоту, в ней 6 блоков и 24 артефакта, из которых лишь 8 обязательных. Методику пришлось дорабатывать, потому что она ориентирована на небольшие ландшафты, где нет сложных иерархий оргструктуры и продуктов. Но при доработке они старались сохранить простоту, а для этого использовали общий принцип: локальная архитектура описывается просто, а выя агрегация выполняется автоматически. Для этого, правда, пришлось потребовать, чтобы все артефакты были машиночитаемыми, и использовали хранимые справочники, где есть связи между иерархиями. Это дает накладные расходы на создание артефактов, но не такие большие. А вот ведение и отслеживание изменений — упрощается.

Еще один принцип — архитектура описывает To Be. As Is собирается автоматически, и его можно сравнить с To Be. Это, отчасти, побочное следствие машиночитаемого представления.

Ну а теперь — подробнее.

Какие задачи хотелось бы решить с помощью архитектурных артефактов?

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

Выбор фреймворка. Есть большие фреймворки Zachman, TOGAF, FEAF-EAF. 50+лет, продаются консультантами. Все они про то, что мы в точке А, хотим в Б и будем идти туда лет пять по плану. Для современных условий это точно не подходит. Есть легкие: c4 model, Rozanski Woods, Kruchten 4+1 — они все про решение, а не про бизнес.

И взяли EAoaP — Enterprise Architecture on a Page, который родился из критического взгляда на большие фреймворки с 2 м артефактов. В нем всего 6 блоков и 24 артефакта, из них 8 обязательных. И он пытается не делить слои артефактов, а сохраняет смесь бизнеса и ИТ — это важно.

Проблемы EAoaP.

• Нет реальных внедрений. Автор летом 2024 рассказывал про модель — она свежая.
• Модель не учитывает оргструктуру компании. Вообще. Отделы, трайбы — этого нет.
• Модель плоская. А любой enterprise — сложен, там иерархия, например, продукт — кластер-экосистема
• Явно нет разницы между as is и to be. Артефакты дают состояние в точке.

Блокам Vision, Outlines (бизнес-идеи), Lanspape (ландшафты) и Design явно нужна иерерхия. В лоб поддерживать иерархию, связывать — утопично. Поэтоу их идея — создавать Inventory — хранилище, чтобы оно связывало артефакты. Отслеживаем связи и формируем представление на единых витринах, например business capability и реализация продукта. Для этого все артефакты — машиночитаемые. AsIs собираем с ландшафта, а мы описывает только ToBe.

Дальше — детали по артефактам, записанные в телеграфном стиле.

Standards.

• Библиотека шаблонов проектирования
• Логические модели данных — отказались от стандартизации, на усмотрение продуктов, потому что важность и сложность в продуктах различная
• Guide lines: playbooks и handbooks
• Inventory технологий и жизненный цикл — вплоть до хранения версий библиотек, тут детально

Принципы — иерархическая структура. Принципы — основная сила, которая помогает людям на местах принимать решения. Это — подсказка, но решение принимаете сами, а не идете к корпоративному архитектору. Связь бизнеса и приложений, подходы к разработке (api first).

Consideration — стратегия, вектор развития

• Принципы — иерархическая структура
• Inventory трендов и жизненный цикл
• Концептуальная модель данных — стандартизованна, в отличие от логической, потмоу что они менее детальны: какие объекты и кто владелец. Сделан inventory.
• Стратегия — иерархия артефактов. business — tech — arch
• Policy, правила — на усмотрение проекта, у них нет централизованных правил

Vision — артефакты, описывающие бизнес

• Inventory процессов, вроде научились с ними жить, хотя стараются уходить от процессов, использовать capability
• Inventory архитектур ArchOps — хранить, визуализировать. architecture as a code
• Inventory business capability — бизнесовая? делают еще упакованные
• Inventory product business capability (продуктовая ценность)
• Roadmaps — ситуативно, на их масштабе их вести не получается, огромные диаграммы Ганта со взаимосвязи — не живут, только по месту.
• Синхронизация по целям — вместо роадмапа, путь к цели команды определяют сами.

Outlines

• Бизнес-описания типа сценариев — по необходимости.
• Inventory CJs — на инициативы смотрим через ustomer journey
• Cравнение вариантов — для любых выводов ADR, для design тоже. Цели (критерии) выбора, варианты, результат выбора.

Design: ADR и ArchOps

Landscape

• IT-роадмапы — ситуативно
• AcrhOps, часто как context diagram c4 model
• Inventory продуктов, в связи с capability.

Итого: 20 % артефактов убрали, 20 % модифицировали, и 60 % — сделали иерархичными.

Динамика и связи. Рекомендация фреймворка — все со всем связано, сложная логичная схема вечной актуализации.

У них

• Все артефакты одного типа связаны в inventory. Все на уровне продукта, а система агрегирует в домены бизнеса.
• Артефакты разных блоков связываются через единые представления на основе информации, и можно навигироваться.
• Цели и capabilities — основаня точка синхронизации Бизнес-ИТ.

Федеративный подход к управлению функцией архитектуры. Нет отделу корпоративной архитектуры, с которым все согласуют!

В целом EAoaP — неплох, точно лучше TOGAF. Минусы — тоже есть. Они нивелируются машиночитаемым подходом. Inventory вам в помощь. Единые репозитории — чтобы все время было актуально, чтобы описание жило. Единый репозиторий всегда смотрит связки по горизонтали. И показывает картину на уровне домена, которой из отдельных систем не получишь. Трудозатраты на создание — побольше, потому что машиночитаемй формат, а не на салфетках. А экономят — именно актуализацию и разбор по взаимосвязям.

Это история 2.5-3 года. Бизнес — сам пришел. Телеком как core классно, но дальше надо развиваться в разные стороны. Разговор про деньги и value, связь с целями. И когда инициатив, продуктов и проектов много, в этом надо как-то навигироваться. Наполнение — в процессе. 600 продуктов, всех заставить нельзя. Начали создавать quality gate в процессах, которые побуждают делать в обмен на профит — ускорение согласования и так далее. Сейчас 2/3 продуктов как-то пристуствуют.

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

Владимир Кочетков из Positive Technologies. Программировать как хакер, защищать — как программист

Основной тезис доклада: подход Hack yourself first — раз в неделю посадить разработчика взламывать приложение, за который топит Troy Hunt, и который распространился — зло. Очевидно, что атакующий с улицы — более профессионален во взломе и преуспеет больше. А мы заставляем разработчика заниматься мутной, странной для него работой. Это дорого и демотивирует. А на курсах безопасности учат этому — уязвимостям.

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

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

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

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

Дальше был кейс, на типовом api работы с пользователями: register, login, logout, change (account), reset_pwd. И для каждой выписаны варианты взлома, которые видит хакер: sql-инъекции там, где есть запись в БД, подбор паролей и так далее. По-сути, можно рассматривать его работу как программирование на вирутальном вычислители, в роли которой выступает ваш софт, а его цель — написать программу, которая ломает приложение. Хакер ищет возможности, которые разработчик не предусматривал. Разработчик, когда пишет код, ориентируется на необходимость, и не проверяет, не сделал ли больше, чем нужно. Пример: интерпретатор арифметических выражений делаем через eval — калькулятор есть, но там много дополнительных возможностей, включая запуск произвольного кода. Уязвимости десерриализации — передать им серриализованный объект, так что десерриализация выйдет за пределы предусмотренного, вызывались какие-то методы. И так далее.

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

1. Код только для реализации фичей. Без отдельного кода работы с атаками. Не надо встраивать блокировку после пяти попыток входа с неверным паролем, потому что хакеру безразлично, перебирать логин-пароль или пароль-логин, искать пользователей с простыми паролями. Зато хакер легко сможет устроить массовую блокировку пользователей и нарушить работу системы. Борьба с подбором паролей — вопрос инфраструктуры.
2. Ограничивать грамматики входных и выходных данных. При работе с файлами не надо точечно пытаться вырезать подъем по директориям, надо проверить, что конечный каталог находится среди допустимых.
3. Код и идентификаторы ресурсов формировать из объектов: разбираем строку, делаем все проверки, и дальше идем в api с разобранным объектом.
4. Оценивать каждое изменение на необходимость и достаточность.
5. Следовать лучшим практикам кодинга, а не фазинга. Например, Синглетон — дабл лок чек: проверка null, лочим, проверяем что не стал другим.

Алексей Мерсон (Т-Банк). Надежность на масштабе в 45 млн клиентов — инструменты и практики цифрового банка

Этот доклад поначалу вызвал разочарование фокусом на сложностях поддержки на большом масштабе, а не на применяемых решениях. Возникло даже ощущение, что весь доклад может оказаться рассказом о том, как «наши космические корабли бороздят просторы Большорго театра» (был такой мем эпохи застоя). Но потом стало видно, что Алексей раскрывает схемы многоуровневой эшелонированной обороны: мониторинг состояния приложений, призванный сигнализировать о проблемах до того, как они возникают; мониторинг обращений пользоателей как индикатор потенциального возникновения массовых проблем; support 24*7 для реакции на кризисные ситуации, механизмы предотвращения ситуаций, в которых служба поддержки захлебывается в решении проблем; единый календарь релизов со световорной моделью, позволяющей их приостановить и так далее. И в рассказе были средства, используемые для конкретных целей: Sage, FineDog, Kolobok и другие.

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

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

Алексей Николаевский (Яндекс). Транзакционная работа с топиками. Архитектура и сравнение решений в Apache Kafka и YDB

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

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

D докладе были подробно рассмотрены механизмы транзакций в Kafka и YDB, но это я пересказывать не буду. Смотрите слайлды и документацию, разбирайтесь. По-хорошему тут нужны схемы, при чем такие, чтобы было понятно — что происходит в сложных случаях, например, при падении экземпляра. А их, увы, не блыо. Жаль. Но все равно, я послушал с большим интересом.

Григорий Петров (Evrone) Красота кода глазами нейрофизиолога-программиста

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

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

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

И тут мы подходим к интересному. Оправдаются ли эти инвестиции при бурном развитии ИИ? Может быть, работа на уровне кода станет уделом довольно узкой группы людей, как сейчас стала работа на уровне ассемблера, которая когда-то была повсеместной? Использование GPT активно входит в повседневную практику. Самое популярное — перевод между языками старого кода и парное программирование с ИИ: сеньоры работают как архитекторы с кучей исполнителей, а джуны — могут не гуглить конкретную инфу. Еще нейросеть знает где и лежит конкретный код в проекте и помогают с ревью: в промпт можно запихнуть практики, при чем конкретного проекта. Это помогает во входе в проект, когда надо стиль понять. ИИ — хороший суммаризатор результатов линтеров и анализаторов, и можно поговорить — она объяснит, почему дефект, почему надо править. Может оценить сложность кода: объясни простыми словами, если объяснит — значит простой. Может писать тесты. И так далее.

И не похоже, что ИИ — это новое визуальное программирование, распространение реально идет снизу-вверх, хотя, как всегда, есть скептики. Правда, отмечу, что от человека требуется базовое понимание констркуций. Императивные и объектные языки достаточно похожи, и тут возможно примерное понимание. Но вот функциональная парадигма отличается сильно, а ее сейчас можно использовать не только в специальных языках, типа xsl, Schema или Haskel, но и во вполне известном C#, куда ее в 2008 втащили вместе с реляционной, чтобы сделать linq. Асинхронные конструкции тоже требуют соответствующего мышления. И я сомневаюсь, что у ИИ получится понятно объяснить. То есть нужна некоторая база. В теории, ее надо выделить и учить именно ей, в небольшом объеме. На практике, вряд ли это сделают, образование — консервативно, а большие крусы продавать выгоднее — понятно, за что берешь много денег. Хотя есть те, кто занимается обучением детей — может, они сделают. Так что, думаю, стоит следить за этой веткой образования.

А еще, говорят, есть нюанс. Есть исследование UpLevel, что использование прораммистами нейросетей дает +41 % багов и не увеличивает перемалывание тикетов. Я бы тут заметил, что это закономерно, если учитывать, что хорошие GPT появились недавно. Исследование говорит лишь о том, что работа в паре с нейросеткой тоже требует навыков. и эти навыки отличаются от работы в одиночнку. Это как сравнивать эффективность разработки на новом языке или фреймворке и на давно знакомом. Для любого языка и фреймворка есть время наработки хороших практик. и оно тем больше, тем больше различие.

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

В конце доклада было награждение победителей конкурса красоты кода 2.0, который проводил Сбер. По-видимому, именно это дало название докладу, которое стало не соответтсвовать содержанию: про красоту кода в нем не было, речь шла лишь про понимание и когнитивную сложность. А это — разное. Может быть простой и уродливый код, а может — сложный, но красивый — когда его, наконец, поймешь.

Эмир Вильданов (Picodata). Движок распределенного SQL в СУБД Picodata: принцип его работы, принятые архитектурные решения и сравнение с аналогами

Это был технический рассказ про внутреннее устройство движка Picodata — открытой, распределенной in memory базы данных, написанной на rust. На каждом инстансе используется Tarantool, они сделали fork и его развивают, а задача picodata — оркестрация этих инстансов и обеспечение согласованной работы.

Фокус рассказа — исполнение SQL-запросов. При этом на каждом отдельном узле запросы выполняет движок Tarantool, он строит план запроса. А их задача — собрать все вместе. И для этого надо построить оптимальный план с точки зрения сетевых вызовов и объемов передаваемых данных.

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

Для начала — SELECT — чтение данных. ВЫполняется парсинг в AST-дерево, дальше надо понять, на каких узлах и что именно исполнять, вызывая локальные SQL-операторы Tarantool, и как свертывать результаты с помощью map-reduce. Распределение хранения по узлам обеспечивается библиотекой vshard из экосистемы Tarantool. В каждой таблице есть ключ распределения. И если в запросе есть условия по полям, которые входят в ключ, то его можно выполнять на ограниченном количестве узлов. Более того, если условия касаются сразу нескольких таблиц, то их join можно тоже выполнять локально. Это встречается достаточно часто, например. если данные распределяют по географии — по странам и регионам.

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

Group by выполняют сначала на узлах, а потом — на координаторе.

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

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

В конце было сравнение с Cockroach DB SQL. Основная разница — что там на узлах key-value, а в picodata — полноценный sql. И обработка шардинга при анализе запросов.

Евгений Харченко из Райффайзен Банк. Инженерная культура на масштабе: как развивать и оценивать практики

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

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

А теперь — конспект доклада. В ИТ Райффайзена 3700 отрудников 262 команды и много сообществ. Матричная структура: команды распределены по бизнес-доменам, а сообщества объединяют специализации.

Проблемы

• темпы разработки не позволяют адаптироваться
• качество кода вляет на стабильность
• разнообразие подхода

Основаня метрика — pain index, мера, как мы делаем больно клиенту. Она показывает стабильность — развернули сырое, уронили качество.

В 2019—2021 они внедряли стандраты, а в 2022 перешли от стандартам к лучшим практикам и созданию инженерной культура.

В 2019 была создана Acceleration team? ее цель — внедрять dora-метрики и практики. Нужна цель и слоган, близкий командам, им стало развитие технологического совершенства. ИТ-стандарты — лучшие практики разработки и эксплуатации. А еще упрощение внутреннего рекрукмента, подъем технической зрелости и повышение качества и стабильности кода.

Начали с continious integration и автотестов. Процесс разработки построен на основе trunk based development с короткоживущими ветками. На pull request выполняется code review, проверяются критерии качества кода, выполняется сборка с прогоном автотестов. Всего 4 практики. Первый год внедрения: 58 % команд в статусе unknown. В остальных 2-3 из 4.

В 2020 был начали использовать continious deployment projects, переходить на gitlab с attlasian и добавили фокус на логгирование и мониторинг в продуктах. Тогда было 146 команд, использование практик увеличивалось.

В 2021 появилась внутренняя платформа разработки, на которой автоматы сборки и проверки, покрытие увеличилось, хотя команд тоже стало больше. Прогресс — за счет инструмента gitlab, и команды accelertion team, это из team topologies.

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

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

В состав практик добавили disaster recovery — восстанавление при падении. Проверка — тестируемый сценарий DRP, фактические знанения RTO и RPO, и тест.

В 2023 — следующий такт развития, coaching of engineering:

• relibility и resiliency (R&R), avalilability — доступность сервиса.
• TTM от запроса (задачи) и до прода, lead time и deploy frequency
• MTTR — среднее время восстановления
• Performance — как быстро функция отвечает

Они провели исследование инженерной культуры по модели Рона Веструма в dora.dev. Цель — проверить и адаптировать. Шесть категорий: обмен информации, отношение к ошибкам, сотрудничество, общая ответственность… Общие практики — в technical capabilities. Построили свою модель: частота развертывания против культуры. Делали опросы, строили отчеты по связи культуры и метрик. У команд с индексом культуры от 4.3 на 30 % меньше встречаются нереализованные технические практики. А pain index снижался от 5.6 до 4.3 с 2022 до 2024, и это коррелирует с распространением практик в целом. А вот про то, насколько связан pain index по конкретным продуктам с распространением практик и уровнем культуру, данных не было. Впрочем, возможно, тут нет однозначной корреляции, надо учитывать зрелость продукта и софта, в зонах интенсивного развития и стабильности показатели могут сильно отличаться.

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

В презентации был фреймворк создания практик: статус, описание, решаемая проблема, риски отсутствия, способ реализации… Статус практик: новая, зарождающаяся, хорошая, лучшая

Что считать хорошей практикой?

• Эффективность — опыт и доказательная база по историям успеха
• Адаптивность — с любыми инструментами
• Измеримость — для этого есть dashboard и аналитические отчеты

Технические возможности и навыки взяли из модели SFIA, люди оценивают сами себя. Кто не в курсе — SFIA, Skill Framework of Information Age — модель, на которой образование договаривается с бизнесом: чему учить, какие есть специализации, что они содержат. Первоначально появилась в Великобритании, с ейчас используется в большом количестве стран и развивается. В ней более 120 навыков, по каждому из них описаны уровне владения, которые выровнены между собой по 7 большим уровням. И для каждого уровня — интегральное описание самостоятельности сотрудника, сложности решаемых задач, знаний, способности влиять на других и понимать бизнес.

Сейчас 12 практик. на слайде была карта связей между собой и с показателями. Будут расти дальше, до 40 практик и 300—500 критериев оценки команды. Культура и техника взаимосвязаны, их можно и нужно измерять, и они должны принимать обоснованные технические решения — с цифрами.

Чтобы дерево выросло — надо его посадить. Культура необзательна, но надо настойчиво рекомендовать, показывать пользу. Трассировки практик до бизнес-показателей нет, это цель следующего года. Оно необходимо. Без этого есть мнение техлида (и других членов команды) против других мнений, а команды автономны.

Виталий Исаев из Яндекса. Как объединять данные из разных СУБД и делать это эффективно

Задача объединения данных из разных баз — актуальна, многообразие средств хранения становится нормой: PostgreSQL + ClickHouse + Mysql + s3, далее по списку. Это можно делать за счет средств самой СУБД, многие из которых дают возможность подключения к внешним источникам данных и использования таблиц из них в SQL-запросах совместно с таблицами самой БД. Это умеют многие аналитические базы данных, и есть движки федеративных баз данных.

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

Павел Велихов из Yandex Cloud. Стоимостный оптимизатор в YDB — как, зачем и почему?

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

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

Ольга Лукьянова из Yandex Infrastructure. Моментальная навигация по коду для любого коммита. А так можно было?

Яндекс делает свою платформу разработки, пререлиз в феврале, осенью для всех. А доклад был про реализацию в рамах этой платформы навигации по коду. Большинство платформ смотрят на код, как на текст, и в результате если у тебя метод add, то в списке 100500 пунктов, выбирай сам. Реализация осложняется тем, что навигация должна работать при обработке merge request — то есть ты смотришь diff, и навигацию для старых строк хочется по старой версии, а новых — по новой.

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

Дальше усложнения. Вместо word индекс используют триграм-индекс — разбивка слова по три символа, это нужно для автоподсказок, он есть в Code Search, поэтому удобно перейти на него. Еще для файла строим локальный resolve index, чтобы показывать поплярные имена, типва err. Языково-зависимые эвристики для улучшения результата, например, декларация в том же пакете, если она есть. Полный resolve-индекс для пакетов и типов. И так далее. И различные оптимизации: индекс деклараций позволяет не заглядывать в файлы. Можно не хранить полный индекс для каждой версии, а хранить его инкремент, но тогда при запросе надо добежать до снапшота, стратегия может быть различной. И так далее, много деталей о том, как постепенно усложняли функционал от MVP.

В целом — любопытно.

Екатерина Лысенко. Финтех: причины моей ненависти

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

Я хочу отметить, что сам уже почти 30 лет работаю с банками, и примерно 2/5 проектов с ними. Еще 2/5 — торговые компании, а остальное — другие домены. И конструкции, о которых говорила Катя, мне знакомы. Но ненависти не вызывают, для меня это просто особенности предметной области. которые надо учитывать. Тем более, что часть из них, например, с округлением, плохим интернетом, протоколами интеграции или тестовыми данными от домена не зависят. Их причины вообще не в домене, а в мышлении разработчиков, которые придумали какие-то кривые решения, а потом с ними надо жить. При чем бывает, что исходная система, от которой унаследовано кривое решение, уже много лет как выведена из эксплуатации, но поскольку это важно в протоколы интерации десятка других систем, потому что часть из них когда-то интегрирвоалась с той системой, то теперь решение живет, реинжиниринг — дорог и чреват ошибками.

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

А теперь — телеграфный список сюжетов. Не уверен, что записаны все.

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

СМЭВ — система межведомственного электронного взаимодействия в России. Почти унифицированный транспорт в России. Проблема: (а) иногда сервис падает и (б) понять как работает можно только эмпирически. Есть доки СМЭВ и отдельно — каждого ведомства. Есть лимиты на обращения от СМЭВ и от министерства, и вас могут случайно отключить до конца месяца за превышение. А еще СМЭВ работает с высокой доступностью, но не гарантирует, что все ведомства к ней подключены постоянно, это дело ведомств. При отсутствии доступа сервисы соответствующих ведомств не отвечают, и перестают отвечать некоторые интегральные сервисы, объединяющие несколько ведомств. напрмиер, проверки документов. И если ты хочешь автоматически обрабатывать документы, то помимо полной проверки надо дублировать функционал, выполняя частичные проверки.

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

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

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

Кривые решения часто делают в MVP с идеей «потом переделаем». А потом они остаются. Вообще «потом переделаем» — типичный миф: если у вас нет времени сделать хорошо, то откуда у вас будет время переделать?

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

Безвалютные проблемы. В функционале забетонирован доллар или рубль. А через три года приходит бизнес и говорит — у нас юань. А потом — у нас много валют. А в системе вообще не предусмотрено поле с валютой. И это — не только финтех: россияская компания, все покупатели платят рублями, и вдруг — оплата с помощью Сбер-спасибо. Она еще и частичная, всю сумму таким образом заплатить нельзя. И да, эта проблема с финтехом не связана, у меня знакомый несколько лет работал над локализацией в Европе крупной американской системы, где никаких валют не предусмотрено, потому что есть только доллар.

Доли в суммах. В системах не думают про округление, хранят суммы как вещественные числа, доли накапливаются. При этом в большинстве стран есть обычные копейки, сотая доля, и там, где есть округление, оно часто такое. А есть страны без копеек, есть Тунис, где динар делится на 1000 единиц, а еще Мавритания и что-то еще, где деление на 5 единиц. А еще есть валюты с очень низким курсом, где по некоторым операциям должно быть округление до 100к или 500к. Хорошо, что Англия в 1971 году отменила свою хитрую систему, где фунт состоял из 4 крон, 20 шиллингов, 240 пенсов и 960 фартингов, и еще была гинея, равная 1.05 фунта.

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

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

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

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

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

Лимиты. Счет, есть баланс, доступные средства, и блокированные hold. B есть лимит на хранение средств. На net+hold. B налоговая говорит «верни 300» — а это превысит лимит.

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

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

Виталий Левченко из Wildberries. Грейды Go-разработчика, или Что отличает сеньора-гофера от остальных

Хороший доклад про компетенции разработчика на разных уровнях. Но я хочу отметить, что специфики Go в нем нет, если не считать таковой вилки зарплат. В докладе — концепция разработчика-универсала, который может сделать проект целиком: и аналитику, и тестирование, и фронт, и общаться с заказчиком, и внедрять, и эксплуатировать. Когда-то только такие и были, и назывались просто «программисты». И сейчас во многих in house, и некоторых продуктовых командах и стартапах такие и есть, нет специализаций. И, как я понимаю, разработчики на Go — тоже такие. Это связано со спецификой ниши. А может, является временным явлением.

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

Грейды связана с зарплатой. Для Go джуны 50-170к, Мидлы 220-330к, Сеньоры 330-460к, Лиды 400-600к Выше — единичные сделки, нет рынка. А для Python — сильно меньше. Почему? Ответ: такой рынок — тавтология, вопрос-то о том, почему такой рынок. А рынок — из-за особенностей компетенций для Go разработчика. Включая отсутствие готовой инфраструктуры, потмоу что стек — новы, но не ограничиваясь этим.

Разница с точки зрения нанимающего менеджера — в масштабе самостоятельной ответственности

• Джун — тот, кто не тащит
• Мидл — тот, ко тащит задачи
• Сеньор — тот, кто тащит проект
• Техлид — может отвечать за проект. Выдавать хороший результат.

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

Куда расти дальше? Архитектор, тилид, стартапер. В крупном enterprise — ответственность за несколько проектов (staff enineer), глава практики principal engineer, и есть мифические люди, которые драйвят отрасль.

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

В докладе, естественно, была тема найма, проверки компетенций. И тут очень важно не упускать смежные компетенции, поэтому помимо хардов — беседа «за жизнь», и проверка system design. Для старших грейдов важно не просто знать шаблоны, а понимать уместность применения, их логику, понимать бизнес-уровень требований и неявные ожидания. Для проверки можно попросить рассказать устройство прошлого сервиса, дальше — качать выдранные решения — чем они обоснованы. понимает ли логику выбора.

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

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

Lead-скиллы: быстрый старт проекта, фокус на результат, знание системы целиком.

Рост зарплаты связан с ростом ожиданий. А большинство думают, что достаточно делать тоже самое, может, чуть лучше. Чем выше растешь — тем меньше обратной связи. Управление неопределенностью — ты и даешь определенность, опору другим.

Как расти.

• рост запрплаты по пользе
• узнавать что вокруг
• и технику и софты — довести до автомтизма, без проблем
• system design тоже до автоматизма, а знание системы — до идеала
• разбиратсья в процессах
• коммуникация м убеждения

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

Алексей Обыскалов (iContext). Как работать с легаси, чтобы ни вы, ни проект не сгорели

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

Я с этим полностью согласен. Кстати, пользуясь случаем хочу похвастаться кодом для репликаций каталога товаров в большой торговой сети, написанным мной уже более 20 лет назад и до сих пор работающим и развивающимся, уже давно без моего участия. С тех пор было несколько исследований: не пора ли его переписать на разных современных фреймворках, и они приходили к выводу, что это ухудшит качество и стоимость владения: точно появится оплата лицензий, а несколько сложных функций придется серьезно дорабатывать из-за ограничений конкретных фреймворков. Мне любопытно, что с ним будет, когда продукт решат-таки перевести с Oracle на PostgreSQL, насколько сохранится общая организация? Поживем — увидим, пока этого в планах нет. И у меня это — не единичный случай.

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

Основные причины легаси

• Техдолг. Это кредит, плата за скорость. Вася сделал костыль, и ушел — вам расхлебывать.
• Быстрый рост проекта без архитектуры. Стартап сделаем быстро, выйдем на рынок, остановимся и отрефакторим — так не бывает, остановитсья нельзя, надо бежать за конкурентами.
• Отсутствие стандарта кодирования очень влияет. И антипаттерны.
• Влияние бизнес-требований на скорость и качество. Бизнес регулярно требует сделать быстро, и его не волнует, что внутри. Вы делаете, а потом мучаетесь.

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

Проблемы с легаси-кодом.

• Трудности в поддержке и развитии, очень сложно, допилить еще сложнее.
• Риски для стабильности проекта. Если сегодня поменяли валидацию отчетов, а через неделю отвалилось — плохо. Все рассыпается.
• Влияние на мотивацию команды. Кто нырял глубоко — тех ничем не испугать.

Когда рефакторинг необходим?

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

А еще, если при онбординге сотрудника вам стыдно за проект — нужен рефакторинг!

Объективные метрики оценки

• Покрытие тестами: либо не хотим, либо не можем; хорошее — от 75 %, но зависит от проекта. И тесты для тестов — что они проверяют что нужно
• Цикломатическая сложность — количество маршрутов по коду. средний 10, сложный — 15. И функций.
• Когнитивная сложность — насколько сложно понимать код. sonarlint.
• Code churn — показывает, как часто меняется код, точки внимания
• Технический долг
• Coupling afferent|efferent — зависимости между классами

Откуда цифры? PHP metrics — устанавливается, просто конфигурируется, быстро работает (если без зависимостей). Есть граф зависимостей и таблица. Sonar Qube — он тяжелее, сложнее ставится, но зато богаче конфигурируется, он сильнее

Определяем приоритеты

• Код с большим количеством багов
• Критически важный для бизнеса функционал
• Часто изменяемый код — для него важна низкая сложность и высокая поддерживаемость

Когда рефакторинг не нужен

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

Как оценить затраты и продать бизнесу?

• Подготовка:
  • Код ревью и аудит
  • Объем работ и размер техдолга
  • Предварительно договориться с бизнесом (например, стабилизационный спринт);составление плана работ
  • Оценка уровня подготовки команды и обучения (х2 оценки)
  • Разделение задач и оценка трудзатрат (включая аналитику и общение со стейкхолдерами)
• Представление ценности рефакторинга для бизнеса:
  • Улучшение качества продукта
  • Сокращение рисков — всплески, нагрузка на сервер, баги на релизе
  • Повышение скорости разработки
  • Снижение стоимости поддержки
  • Масштабируемость
• ROI:
  • Прямые и косвенные затраты (еще стоимость отвлечения)
  • Возврат через сокращение затрат — багфикс на релиз
  • Доход через ускорение
  • Оценка затрат на остутствие изменений — как будет ухудшаться

С бизнесом нужна техника малых шагов, чтобы было доверие. А ускорение показывать предметно: здесь закидывали на «подумать», теперь не будем. И можно напоминать после рефакторинга на конкретных задачах.

Безопасный реакторинг

• Пошаговый подход к изменениям
• Внедрение автоматического тестирования — не даем сломаться
• Инструменты — метрики и другое
• Код-ревью, хорошее
• Документация изменений
• Метрики и анализ результатов — туда ли идем

Создание будущего легаси

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

Итого.

• Изменяйте метрики, подумайте о пользе бизнесу, если вы не видите — он тоже
• Говорите с бизнесом на его языке
• План наше все
• Тесты

Это может сделать любой, даже джун — если покажете боль.

Мотивация команды — надо показать, что выход есть. Идут изменения.

Максим Мирошниченко из VK Tech. Оптимизация конкурентных приложений: паттерны, сравнение и микроархитектура

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

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

• http-сервер. Хендлеры обрабатываются конкуретно — но этой конкурентностью окно внимания не перегружается, реализация скрыта
• ticker — там простейшее использование
• errorGroup: пять независимых сетевых запросов — там удобный инструмент для оптимизации

Идея — в ваш код заложить такую же простоту, как в библиотеке.

• Использование — как в http-сервере, реализация отделена от логике и скрыта
• for{select} Как в ticker — простые блоки, понятно называются и понятно что делают. Объединение в отдельный слой. простота и гибкость, доверие за счет тестирвоания.

Утилитарные блоки

• удобная работа с каналами
• схожая сигнатура: на вход 1 канал на выходе — другой
• швейцарский нож паттернов

Шаблоны

• pipelene — конвертер. Принимает функцию конверртации A-Б, загоняем канал Аб отдаем Б
• FanIn/Out сборка — разборка однотипных каналов
• батчирование — канал режем на куски заданного размера.
• воркерпул — parallel — на входе: входящий канал, функция, и число параллельных воркеров и выходной канал.

Реальные системы, например, клиент базы — не заточены на канальное взаимодействие. Надо сопрягать.

Определение параметров: характер нагрузки — параллелизм для процессора, конкуретность для ввода-вывода, профиль чтения-записи для БД. Для имитации — время обработки операции. Надо знать свою задачу, которую решает конкуретность.

Дальше были примеры.

Есть кэш, который почему-то начал тормозить. Устроен: Mutex и map. анализ: map — большой, запись 80 % нагрузки, там блокировка mutex на запись. Делаем шардирование кэша, определяем номер шарда как хеш ключа, деленный на число шардов, блокируем нужный — получается 6 параллельных записей, вместо одного. Делаем бенчмарки, видим, что вдвое улучшилось, дальше можно детально подбирать число шардов.

Пусть кеш, в котором значения меняются редко, но изменения надо быстро отражать, поэтому проверять значения. Пусть функция проверки блокирует mutex, если соответствует — выход, если изменилось — делаем работу. Блокировка mutext при совпадении — лишняя. Делаем на чтении Rlock, а на изменение — уже обычный lock.

Бенчмарк говорит, что предыдущая версия работает быстрее в два раза. Почему-то. Может быть, имитационные бенчмарки неверны. Может, гипотеза неверна. Если неверно — надо откатить изменения, так как код медленнее и сложнее.

Интенсивная процессорная нагрузка. Задача — ускорить однопоточную программу поиска простых чисел. Есть многопоточные алгоритмы. Программа фильтрует поток числе, выдавая поток простых. Делаем расщепление FanOut, потом воркеры, потмо — FanIn объединяем. Как определить сколько? Ставим runtime maxproc, а потом снижаем. Чтобы не было проблем. Код бизнес-логики — не содержит никаких асинхронных паттернов. Запускаем бенчмарки, смотрим на ускорение.

Микроархитектурный кейс. Пусть в систему поступают задания, они дают процессорную нагрузку. Результат — канал Result — пишем в БД. Что сделать? Параллельную обработку заданий и писать в БД батчами. Дальше пример кода для реализации. Он не показывал реализации, только схемы, потому что реализация — под проект. Например, в одном случае мы можем через по таймауту отдавать батч, даже меньшено размера, а в другом — ждать наполнения куска.

И дальше имитационные бекчмарки. Отдельно на каждую оптимизацию и на обе. И, что интересно: каждая отдельно дает много, а комбинация — много не дала, и можно дальше углубляться — почему?

Фреймоврк для построения конкуретных приложений.

• Тип проблемы. i/o или cpu
• Реализация — конкретные методы.
• И покрытие блоков конкуретными тестами — работа в асинхронной среде.
• Дальше сборка микроархитектуры из блоков.
• И бенчмарки на них.

Слои абстракции:

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

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

Есть разные способы асинхронного: атомик, mutex и каналов. Он мерил, каналы — самый быстрый. Хотя может зависеть от железа.

Про ошибки. Первым параметром идет контекст. Обработка ошибок — там, где конкурентное взаимодействие. Можем конвертировать ошибку в что-либо. В примере ошибка может быть на конвертации и на записи в БД, и надо понимать, что там будет, например, еще и ошибку.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 01:43, 8 декабря 2024 • нет комментариев