CTO Day Light от Yandex

Вчера была интересная тусовка для технических директоров от Yandex в центре Москвы.
Мероприятие получилось для меня очень интересным, так как удалось пообщаться с умными людьми и обсудить интересные вопросы от полушуточных до серьерзных, например
- Как выстраивать end-to-end процессы продуктовой разработки и какие проблемы тут могут быть
- Как выстраивать оргструктуру под требования бизнеса и как понять оптимальна ли структура под текущие запросы
- Что такое культура компании и как она влияет на взаимодействие команд и процессы
- Как подходить к процессам архитектуры и проектирования - тут и про написание дизайн доков, про нотации моделирования, про описание стейта архитектуры vs изменений, про TLA+ и не только
- Кто такие системные аналитики и что они делают в командах разработки
- Как выглядит работа в европейской компании vs российской:)
- и так далее

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

P.S.
Спасибо организаторам, что позвали в гости на это мероприятие.
Кстати, оно было продолжением того, что было на CTO Day в Дубае, про которое я рассказывал раньше.

#Engineering #Software #Management #SystemDesign #SystemEngineering #Leadership

Доклад про инженерную продуктивность на конференции MTS True Tech Day (Рубрика #Management)

Сегодня на главной сцене конференции от MTS я буду выступать с докладом про developer productivity. У этой конференции интересный слоган: "код науки и технологии", который мне понравился. Мое выступление у меня будет отчасти экспериментальным, так как часть доклада мне придется рассказывать в формате стендапа без слайдов (не уложился в дедлайн их отправки).

Update: ребята успели зарелизить все слайды и рассказ вышел полноценным и без экспериментов. Респект команде МТС!

У меня есть полная версия со всем визуалом и расшифрокой в виде статьи в моем блоге. План выступления примерно следующий
- Затравка про важность этого вопроса
- Как я предлагаю сузить границы рассмотрения только продуктовыми компаниями и частью delivery без discovery
- Какие подходы были в академической среде: DORA и Accelerate, SPACE, DevEx - тезисы со ссылками на материалы доступны здесь
- Как это делают в Bigtech, например, в Google используют подход QUANTS - тезисы доступны здесь
- Что есть на рынке в виде коммерческих платформ - тезисы и ссылки здесь
- Как это делаем мы в Тинькофф - тут я расскажу про наш инструмент T-Meter
- Ну и какие выводы из этого всего следуют

P.S.
Так как мой доклад - это не питчинг раунда финансирования для стартапа, то я решил исключить часть про влияние AI на developer productivity, что тянет на отдельный доклад (который недавно как раз рассказывал VP of Product из GitHub)

P.P.S
Получить достууп к трансляции можно так
- создать аккаунт здесь https://lk.truetechday.ru/login
- перейти на страничку https://lk.truetechday.ru/broadcast и выбрать интересующий трек (рекомендую в 14.15 открыть главный зал)

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

Расшифровка доклада про продуктивность инженеров для тех, у кого не открывается Medium. На выходных еще запишу режиссерскую версию доклада и залью на свой Youtube канал:)

Designing for change with Vertical Slice Architecture - Chris Sainty - NDC London 2024 (Рубрика #Architecture)

Интересный, но странный доклад про вертикальные слайсы как архитектурный концепт. Основная мысль в том, что нам стоит проектировать приложения с учетом изменений, так как изменения являются единственной постоянной в нашей отрасли. Дальше автор вспоминает предыдущие виды архитектур
- Трехзвенная архитектура (n-tier), что была популярна во времена динозавров. В этой архитектуре у нас есть data access layer, business logic layer, user interface layer
- Луковая архитектура, хорошо, что не липовая (onion) - в этой архитектуре центральным элементом являются бизнес-правила предметной области
- Чистая архитектура от дяди Боба (что любит все чистое: код, архитектуру, agile) - микс лучших практик из других архитектур возведенный на уровень догм
Дальше автор вспоминает что мы делаем код не ради красивой архитектуры (звучит лучше, чем чистая), а ради создания фичей внутри продукта и зарабатывания денег. Поэтому у нас есть ограничения и иногда нам фичи сделать важнее, чем сделать все по красоте. Так появляется техдолг и потребность в рефакторинге.
Сейчас стандартным подходом является создание отдельных сервисов, но у нас появляются проблемы
- High coupling и low cohesion (а нужно конечно наоборот)
- Это приводит к сложности в изменении и обслуживании этих систем
- У нас часто появляются проблемы с методами сервисов, которые имеют больше одной причины для изменений (продолжение single responsibility principle и separation of concern)
- Само свойство систем приводит к большому количеству связей и повышению сложности, если мы не боремся с этим
- Стандартная многозвенная архитектура нам не помогает - у нас есть проблемы с пониманием и изменением кода, так как надо держать все части приложения в голове. Также появляются проблемы со сложностью кода, производительностью и масштабируемостью систем.

И автор предлагает серебрянную пулю в виде vertical slice architecture, где у нас
- Организация кода предполагается по сценариям использования, а не по технической ответственности
- Мы пишем отдельный код для слайсов, а не переиспользуем существующий
- В слайсах мы пишем только тот код, что нужен сейчас. Если в будущем появится новые потребности, то мы добавим их в слайсы (все 100500, которые сделаем в рамках своей архитектуры)

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

Здесь мы легко обрабатываем срочность выпуска фич
- Срочные функции могут быть созданы и протестированы быстрее, без компромиссов в коде (просто добавь воды сделай еще один слайс )
- Код под кастомного пользователя может быть написан в отдельной вертикали, что позволяет избежать загрязнения существующего кода
- Технический долг и рефакторинг также могут быть выполнены более эффективно, так как мы можем его отдавать по слайсам

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

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

#Architecture #Software #SystemDesign #SoftwareArchitecture

An Introduction to Residuality Theory - Barry O'Reilly - NDC Oslo 2023 (Рубрика #Architecture)

Интересное выступление про residuality theory от Barry O'Reilly, автора теории. Автор делает подход к созданию теории, что поможет инженерам прокачиваться в архитектуру не просто набивая опыт, а используя достижения complexity theory, но без погружения во всю ее сложность. Для этого автор начинает с определения упорядоченных и неупорядоченных систем, а дальше он показывает как стрессоры (неизвестные факторы) могут негативно влиять на архитектуру. С учетом вариативности окружающего мира проанализировать все состояния системы и влияние стрессоров на систему в этом состоянии не представляется возможным. Поэтому автор предлагает рассматривать систему не целиком, а изучать то, что остается от системы, если случается пи... (стрессор X). Эти остатки определяют будущее системы и могут быть использованы для управления архитектурой программного обеспечения. Для моделирования стрессоров нам поможет метод Монте-Карло с его рандомизацией, которую мы можем применить к возможным стрессорам.

Дальше автор вводит рассказывает про аттракторы как устойчивые состояния, в которые скатывается система. Он приходит к ним через NK модель Кауффмана. У нас есть система с N элементами, принимающими значение 0 или 1, параметром K характеризующим связность (например, максимум связей одного элемента). Суть в том, чтобы показать, что при росте N и K у нас в системе увеличивается количество аттракторов. Заодно там появляется вероятностная характеристика P, которая характеризует bias связей между элементами. Финалом размышлений становится вывод некоторой выпуклой кривой критичности, которая вырисовывается в пространстве N и K, где мы играем с количеством элементов и связей между ними (еще один способ определить количество сервисов и связей между ними).

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

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

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

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

В общем, все звучит достаточно логично и напоминает мне подход генеративно-состязательных сетей, но только к архитектуре. Дальше я планирую прочитать whitepaper "Residuality Theory, random simulation, and attractor networks" от автора доклада и рассказать про него:)

#DistributedSystems #SystemDesign #Math #Engineering #Architecture #SoftwareArchitecture #ComplexityTheory #Software #Processes

Морфология Волшебной Сказки (Рубрика #Writing)

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

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

Дальше автор предлагает пойти не от сюжетов и мотивов, а от их строения и составляющих. Такой подход оказывается чудо как хорош и дальше его продолжают применять в других работах, навроде, "Тысячеликого героя" Джозефа Кэпмбелла (у меня уже был пост про эту книгу).
Сама книга достаточно лаконичная, так как автор уносит в приложения и отдельные работы большую часть проведенного анализа сказок, а в книге делится только основами своей теории и выводами. В итоге, книга состоит из 9 частей
1. К истории вопроса - глава, где автор рассматривает предыдущие подходы к снаряду
2. Метод и материал - здесь автор очерчивает то, что он называет волшебными сказками, которые он и анализирует в своем труде. Дальше показывает, что не важно какие именно персонажи есть в сказке - важно, что они делают и какие функции выполняют. Причем функция - это та поступки персонажа, которые значимы с точки зрения сюжета. А потом следует основные выводы: число функций в известных волшебных сказках ограничено, а мало того они еще и всегда идут в одинаковой последовательности. Поэтому мы получаем неожиданный результат: все волшебные сказки однотипны по своему строению. Интересно, что дальше в книге автор связывает волшебные сказки с мифами и религией.
3. Функции действущих лиц - основная часть работы, которая описывает 31 функцию, в которой у нас участвует герой, жертва, антагонист, даритель, помощники, ложный герой, ... В общем, эту часть интересно читать и видеть как разное поведение можно свести к общим функциям
4. Ассимиляции. Случаи двойного морфологического значения одной функции - здесь автор показывает как некоторые функции в процессе эволюции сказки сливаются воедино, например, есть отдельные функции в виде задачи и боя. Условно бой с драконом или решение сложного квеста царевны, но если царевна задаст задачку сразить дракона, то у нас тут налицо объединение функций:)
5. Некоторые другие элементы сказки - здесь разбираются связки разных функций, утроения (часто встречающиеся в сказках) и мотивироки поступков персонажей
6. Распределение функциий по действующим лицам - здесь автор показывает какие действия могут совершать разные типы персонажей
7. Способы включения в ход действия новых лиц - тут рассматриваются как эти типы персонажей подключаются к сюжету
8. Об аттрибутах действующих лиц и их значении - здесь автор рассказывает про совокупность внешних качеств персонажей и как они придают сказкам красоту и обаяние. Разбирается пример с Бабой-Ягой и ее избушкой, Иван-царевич, волшебные кони, прекрасные царевны.
9. Сказка как целое - а здесь автор берет свой инструментарий и разбирает несколько сказок, показывая как они раскладываются на функции и у нас получаются аля предложения, которые описывают сказку структурно, а дальше эту структуру сказок можно использовать для их классификации.

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

#Writing #Patterns #History

T-Start

Наша мобильная команда опубликовала новую версию мобильног iOS Тинькофф Банка в AppStore под названием "T-Start".
Если у вас iOS, то рекомендую оперативно скачать эту версию и получить доступ к новым фичам, которые наши ребята разрабатывали последнее время.