Как и зачем измерять инженерную продуктивность в крупной компании (Рубрика #Management)

Появилась запись моего выступления на MTS True Tech Day, где я рассказывал про инженерную продуктивность. Эта тема является важно для больших компаний, так как достаточно сложно понять насколько эффективно работает организация. Есть общие показатели на всю компанию, но они
— Показывают общую ситуацию в компании и сложно понять вклад отдельных частей организации
— Отображают уже достигнутые результаты причем с сильным лагом — это примерно соответствует тому, чтобы при управлении машиной смотреть не в лобовое стекло, а в зеркало заднего вида
В крупной технологической компании (а в Тинькофф порядка 10к инженеров) большой вклад в эффективность компании вносит эффективность работы инженеров, поэтому мы уделяем этому большое внимание.

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

Расшифровка есть в статье в моем блоге, а также в виде pdf в этом канале.

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

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

Выступление про архитектуру и проектирование на фестивале Т-Двор в Питере (Рубрика #Architecture)

Через неделю я еду в Питер, чтобы выступить на нашем фестивале Т-Двор, который будет с 6 по 9 июня. Последний день будет посвящен технологиям и профессиям будущего и именно там я расскажу кратко про то, как мы проектируем свои решения, которые должны работать надежно и масштабироваться под растущую нагрузку из-за увеличения количества клиентов (у нас их уже 42 млн), количества продуктов (их сложно посчитать), а также усложнение нашей экосистемы. Я расскажу про
- Использование RFC/ADR для описания крупных изменений и их ревью
- Фокус на использовании платформ и as a service решений внутри
- Подходы к architecture as a code, которые пока больше похожи на architecthure documentation as code, но на развитие которых у нас большие планы
- Расскажу про RnD подходы к архитектуре, которые пока у меня в голове или в лучшем случае в бэклоге, но по которым мы планируем сделать большой рывок в будущем

В общем, регистрируйтесь бесплатно и выбирайте 9 июня (там можно выбрать билет на один из четырех дней) и приходите на мое выступление:)

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #DistributedSystems #Management #Leadership

ЦЕХ 4 - Урок #8 "MS Word для работы с большими и сложными текстами. Эксперт — Юлия Потемкина" (Рубрика #Writing)

Перегруз на работе привел к тому, что я чуток выпал из курса по написанию книги, но теперь решил нагонять его. Начал с восьмого урока от Юлии про MS Word и его возможности. Чем-то этот комбайн (MS Word) меня пугает (возможно кучей опций по настройке), поэтому я сам обычно использую Google Docs в онлайн варианте. Но урок про Word было интересно. Кстати, предыдущие посты здесь: 1, 2, 3, 4, 5, 6 и 7. Основные мысли, что я вынес из урока такие:

- Word отлично подходит для работы с большими и сложными текстами
- Word напоминает сложную IDE (аля IntelliJ IDEA от JetBrains) для опытного разработчика, но только для опытного писателя/редактора
- Word можно подстроить под себя так, чтобы работать в нем было естественно. Настройки могут отличаться в зависимости от целевого режима - написание текста vs его редактирование
- Бэкапы наше все - Word делает автосейвы, но хорошо бы и самому их делать (для защиты от шифровальщика багов)
- Важно правильно использовать стили - это важно не только для визуала, но и для дальнейшего редактирования текста
- Важно не заморачиваться сильно с форматирование текста, линейными отступами, дефисами и так далее - все это при редактировании поедет
- Чем-то эта работа со стилями и in-place подкручиванием визуала напоминает веб с его CSS (cascading style sheets) и настройками отображения прямо в HTML
- Важно уметь пользоваться поиском и заменой по документу
- Есть специальные элементы в тексте, которые могут пригодиться: сноски, формулы, таблицы и иллюстрации. Если книгу предполагается отдавать в профессиональную печать, то эти элементы могут разъехатся, если сделаны в лоб
- Word позволяет выстроить процесс ревью, комментариев и предложений по редактированию прямо в документе. Это такой асинхронный коллаборативный формат работы. Чем-то напоминает Google Docs, но там это прямо в онлайне и при помощи CRDT (Conflict-free replicated data type):)
- Ну и напоследок стоит сказать, что в режиме написания книги нужно сделать так, чтобы интерфейс и шрифты поменьше отвлекали от самого письма, так что минимальный интерфейс и невычурные шрифты нам в помощь:)

#Writing #SelfDevelopment

Рулетка кейсов: Примеры плохой архитектуры (Рубрика #Architecture)

Появилась запись дискуссии с последней подлодки, куда я пришел поговорить про плохую архитектуру с организаторами, а также Ильей Зоновым и Кириллом Ветчинкиным.
Дискуссия была насыщенной и мы обсудили вопросы
- Что такое архитектура? Когда ее можно считать плохой, а когда хорошей (тут ключом была готовность к изменениям)
- Что такое универсальная архитектура и бывает ли она (нет)?
- А есть ли что-то за hype терминами и подходами (CQRS, GraphQL, микросервисы)?
- Как работать с базой данных и нужен ли ORM или нам поможет паттерн repository?
- Насколько реально мигрировать с одной базы на другую?
- Нужны ли стандарты, а также когда они мешают?
- Как появляется open source в компаниях и что иногда создание собственных инструментов может быть выгоднее, чем использование готовых решений.

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

P.S.
Спасибо организаторам, что подготовили ссылки на те ресурсы, что мы упоминали

1. Антипатерн «Golden Hammer»
2. Книга В. Хононов «Изучаем DDD. Предметно-ориентированное проектирование» и наш разбор ее в книжном кубе
3. Мой пост про «GraphQL: The Documentary»
4. Мой пост про «GraphQL. Язык запросов для современных веб-приложений»
5. Мой пост про «Adaptive Architectures • Marty Pitt • GOTO 2023»
6. Документация MongoDB. Query MongoDB — Web SDK
7. Олдовая статья «Клиент-сервер 2001»
8. Статья «Diplodoc — открытый набор инструментов для создания документации»
9. Мой пост про . Про документальный фильм про Kubernetes
10. Статья «How Discord Migrated Trillions of Messages to ScyllaDB»
11. Статья «Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%» и мой разбор

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #DistributedSystems #Management #Leadership

Корпоративный мессенджер Time

Мы в компании достаточно давно съехали на свой корпоративный мессенджер Time. Это случилось в тот момент, когда Slack отказался работать с русскими компаниями. За эти пару лет само решение прошло испытание огнем, водой и медными трубами и показало то, что этот мессенджер можно использовать для общения в компании с десятками тысяч сотрудников. Также поверх него можно строить бизнес-процессы и автоматизации (аля chat-ops). Какое-то время назад мы начали продавать это решение как коробочный продукт для заказчиков и на него есть устойчивый спрос. Если перед вами стоит вопрос, а какой мессенджер использовать, то вы можете почитать про наш Time и заказать себе демо.

Ну и немного чиселок для гиков о том, какие показатели это решение показывает на одной из инсталляций:)
- 36 тысяч онлайн-подключений в пике
- 2 млн сообщений в день
- 45 тысяч пользователей
- 3,7 млн диалогов инициировано
- 120 тысяч каналов создано
- 99,99% доступность

#Software

ЦЕХ 4 - Урок #9 "Рассказываем истории: сторителлинг в книге. Эксперт — Лариса Парфентьева" (Рубрика #Writing)

Продолжаю обучение написанию книг, догоняя программу, что ушла на месяц вперед:) Этот урок был посвящен сторителлингу, который я активно изучал самостоятельно, но интересно было послушать урок Ларисы, которая делилась своим опытом. Предыдущие посты доступны здесь: 1, 2, 3, 4, 5, 6, 7 и 8.
Если возвращаться к самому уроку, то вот основные мысли, что я вынес из него:
- Важно понимать цель и мотивацию написания книги - тут может быть и развитие личного бренда и терапия:)
- Какая цель бы не стояла перед автором, сторителлинг отличный инструмент для привлечения внимания и удержания аудитории
- Дальше автор вспоминает книгу "Сделано, чтобы прилипать" ("Made to Stick") и рассказывает про фреймворк SUCCESs из него. Суть в том, что идеи прилипают если они соотетствуют шести категориям: простота (simplicity, неожиданность (unexpected), конкретность (concrete), достоверность (credentialed), эмоциональность (emotional), истории (story). Кстати, я про эту книгу уже рассказывал раньше
- Потом речь идет про структуру истории, где в простейшем случае у нас есть начало, завязка, конфликт, усиление конфликта, кульминация, развязка и финал. Причем важно соблюдать некоторую последовательность, когда напряжение нарастает, конфликт усиливается и история достигает кульминации.
- Для создания интересных историй можно использовать архетипические сюжеты и здесь автор вспоминает "Морфологию волшебной сказки" Владимира Проппа, про которую я рассказывал раньше
- Также можно использовать правило зебры и контраста - для создания эмоциональной вовлеченности у читателя стоит чередовать периоды напряжения и расслабления в истории
- Для создания персонажей надо использовать яркие и запоминающие детали - это позволяет добавить образам персонажей объема. Для оживления персонажей можно использовать те детали и привычки, что вы подмечали у своих знакомых
- Концовку истории можно организовать по разному - оставить читателей на пике или закончить все выводом (хорошо если не нудным). Кстати не все истории должны иметь happy end - тут можно почитать книгу "Я — легенда" ("I Am Legend"), про которую я рассказывал раньше

P.S.
Про сторителлинг и рассказывание историй я уже рассказывал раньше в этом канале:
- про мастер класс по сторителлингу
- про то, как сторителлинг сделал нас людьми
- про тысячеликого героя - классическая книга про путь героя
- про работу сценаристов - классический подход для написания сценариев
- про создание подкастов и рассказывание историй
- про фрирайтинг для решения задач
- про черную риторику и власть слова
- про искусство словесной атаки
- про публичные выступления с прошлого MBA с Ниной Зверевой
- пример крутого выступления с рассказом истории - последняя лекция Randy Pausch
- про откровения оратора про выступления и истории
- про построение историй и выступления в лекции от Yandex
- про риторику и поэтику от Аристотеля
- про нейробиологию чтения

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

The Most Dangerous Phrase • Daniel Terhorst-North • GOTO 2023 (Рубрика #Management)

Интересное выступление Daniel Terhorst-North на тему фразы "We've always done it way" ("Мы всегда делали это так"). Родственником этой фразы является "Так исторически сложилось":) Опасность в том, что, однажды приняв решение и начав действовать определенным способом, дальше мы действуем так по накатанной. Возможно, уже поменялись условия, при которых принималось решение, но образ действия уже стал самоподдерживающейся привычкой. И это плохо, так как наши действия уже могут быть далеки от оптимума. В итоге, автор говорит про
- Наши привычки и смену парадигмы, которая бывает болезненной - на эту тему стоит почитать книгу Томаса Куна "Структура научных революций"
- Идеи устаревают, даже блестящие идеи, но некоторые делают это достойно и адаптируются под реальность, а другие как Скрам или SOLID становятся скорее вредными
- Автор показывает удачную эволюцию идей на примере книги "Цель" Элияху Голдратта, разбирая ее продолжение через пару десятков лет с названием "Beyond the Goal". В этой книге есть интересный алгоритм размышлений о пользе технологий:
1) What is the power of technology?
2) Which limitation does the tehcnology diminish?
3) Which rules enabled us to manage the limitation?
4) Which new rules we need?
В этой книге хорошо описано, что важно измененять правил для использования технологий и их ограничений.
- Дальше автор начинает препарирует SOLID, показывая чем были обусловлены single responsibility principle и open-closed principle примерно 30 лет назад. А дальше становится видно, что в том контексте принятия решений предложенные подходы работали хорошо. Но с тех пор много воды утекло, поменялось окружение и SOLID в том виде, как его рассказывает uncle Bob, стал нерелевантным. Рекомендую посмотреть аргументацию автора выступления - он отличный рассказчик и умеет погружаться в историю возникновения вопроса и вспоминает даже статью Дейкстры "On the role of scientific thought". А потом он примерно также разбирает open closed principle:)
- Потом наступает время Scrum, историю которого автор начинает с Мартины Девос, которая в 1990х создала процесс с шестинедельными спринтами и упрощенными планами на спринт (вместо бесконечного Ганта). Это позволило командам работать более эффективно и быстро реагировать на изменения. Тогда это был прорыв - делать релизы раз в шесть недель на фоне конкурентов, что релизились раз в год или реже. Но с тех пор индустрия научилась релизить изменения в масштабе минут или часов - для этого автор вспоминает про современные подходы к CI/CD. Правда, Скрам как и прежде двигает все в сторону недельных релизов, что сейчас кажется шагом в прошлое:) Но создатели Скрам продают его как чудодейственное средство как ни в чем не бывало - ведь это их способ заработка.

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

P.S.
А для того, что последовать совету автора, я рекомендую почитать книги по критическому мышлению, про которые я уже как-то рассказывал в отдельном посте.

#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking

Leetcode - прогресс за пятый месяц

Вот уже 5 месяцев я играюсь с leetcode, вспоминая как писать код:) И этот месяц пока вышел самым слабым - часть его я проболел и поэтому подзапустил свой ежедневный ритуал с решением задачек. Плюс курс "Data Structures and Algorithms" почти закончился (я прошел все темы) и там остались только те задачки, что я откладывал на потом, но каждая из них требует больше времени, чем стандартная. Так у меня и получилось в мае, что я в среднем решал 1 задачку в день:) А если говорить в общем, то я вроде как вспомнил базовый синтаксис python и простой код могу писать без IDE и автоподсказок:) В июне попробую пройти курс "System Design for Interviews and Beyond" - уж больно интересно посмотреть на его содержание.

P.S.
Предыдущие посты на эту тему доступны здесь: 1, 2, 3, 4 и 5

#SelfDevelopment #Algorithm #Software #SoftwareDevelopment

Тинькофф теперь Т‑Банк (Рубрика #News)

Сегодня мы объявили о том, что Тинькофф стал Т-Банком. Об этом рассказывает Станислав Близнюк в своем интервью Ведомостям. Если кратко, то для клиентов ничего особо не меняется, кроме названия продуктов.

#News

Cassandra: The Definitive Guide, 3rd edition (Рубрика #Architecture)

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

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

1. Beyond Relational Databases - в этой главе приводится кратка инфа, из тех постов, что я привел выше
2. Introducing Cassandra - здесь автор приводит ключевые слова, которые характеризуют Cassandra в формате elevator pitch и продает читателям ее крутость: distributed and decentralized, elastic scalability, high availability and fault tolerance, tuneable consistency, Brewer’s CAP Theorem, row-oriented, high performance:)
3. Installing Cassandra - базовое описание установки кластера, создание keyscpace (аналог database в RDBMS) и tables. Этой главы хватит для того, чтобы поднять кластер для экспериментов, но для администрирования стоит почитать доки или книгу для администраторов Cassandra
4. The Cassandra Query Language - эту главу автор начинает с того, что вспоминает модель данных в RDBMS. А дальше он проводит параллели с моделью данных в Cassandra. Все начинается с пар мапы key-value, что вместе с primary key является row в Cassandra. Дальше набор row собирается в партицию. Внутри строки есть primary key, который в Cassandra является составным, который состоит из обязательно partition key и опционального набора clustering columns. Partition key определяет как строки распределены по нодам кластера, а набор clustering columns определеляет порядок размещения строк уже внутри ноды. Еще есть static column для оптимизаций - это колонка, которая не входит в primary key, но все строки внутри partition шарят общее значение. Партиции собираются в таблички, таблички собираются в keyspace, а keyspace размещаются на cluster. Дальше автор рассказывает про типы данных в Cassandra, которых достаточно много и в которых есть интересные типы вида counter, set, list, map, tuples.
5. Data Modeling - самая интересная глава, в которой авторы рассказывают про моделирование внутри Cassandra и как оно отличается от моделирования внутри RDBMS. Если говорить про RDBMS, то там мы идем от концептуальной модели предметной области. Мы нормализуем данные и раскладываем их удобно с точки зрения консистентного хранения данных. Дальше мы можем относительно просто писать нужные нам деларативные запросы на получение данных, где мы спокойно используем joins, соединяя таблицы как нам требуется. И если нам надо писать другие запросы на выбор данных, то это с высокой вероятностью можно сделать достаточно просто.

В Cassandra мы моделируем данные совсем по другому. Авторы книги показывают это на примере моделирования сервиса для букинга отелей. В Cassandra надо идти не от концептуальной модели предметной области, а от модели запросов (query model) и авторы дают такой совет

Think of the most common query paths your application will use, and then create the tables that you need to support them.

Целью является создание такой модели данных в Cassandra, который минимизирует количество партиций, которые нам надо потрогать, чтобы ответить на запрос. Суть в том, что партиция является единицей хранения и если мы попадаем в одну партицию, то обычно получаем оптимальную производительность. Отдельно стоит отметить, что сортировка данных в Cassandra тоже является дизайн решением, так как данные на ноде внутри партиции раскладываются в том порядке, что определен набором clustering columns.
Кстати, для моделирования данных в Cassandra используются Chebotko diagrams, на которых моделирование как раз идет от query, которые поддерживаются табличками, а дальше для таблицы указываю входящие колонки и все виды ключей.

Обзор оставшейся части книги в следующих постах: 2 и 3.

#Software #Architecture #DistributedSystems #SystemDesign

Engineering Architecture Meetup @ Т-Банк (Рубрика #Architecture)

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

Тизеры к докладам доступны на страничке с описанием митапа

#Architecture #DistributedSystems #Software #Engineering #SoftwareArchitecture #SystemDesign

Cassandra: The Definitive Guide, 3rd edition - Part II (Рубрика #Architecture)

В этом посте я продолжаю рассказ об интересной книге по Cassandra (начало в предыдущем посте) и говорю только про шестую главу "The Cassandra Architecture"
Эта глава начинается с определения архитектуры

Architecture—fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.
—ISO/IEC/IEEE 42010

И дальше начинается интересное

1) Про топологию развертывания кластера, а точнее про датацентры и стойки (racks). Это важно для понимания того, а как обеспечивается отказоустойчивость - для этого в Cassandra есть сплетни (gossip protocols) и детекция сбоев (phi accrual failure detector). И про то и про другое прикольно рассказано в книге "Database Internals", которую мы обсуждали в "CoA" (выпуски раз и два).

2) Про механизм consistent hashing с токенами, кольцом и виртуальными нодами (насайте DataStax есть отличное описание и визуализация). Про то, как работает partitioner, который раскидывает наши партиции по нодам кластера и про стратегии репликации. Дальше наступает время обсудить consistency level и tunable consistency кассандры, которую мы можем выставлять на каждый запрос.

3) Про координацию запроса координирующей нодой, которая от имени клиента взаимодействует с репликами, чтобы обеспечить запрошенный уровень консистентности. Тут появляется такая штука как hinted handoff для write запросов, когда координирующей ноде не удалось записать данные, но она оставила себе напоминание, что надо надо услышав сплетню о возвращении реплики в строй отправить туда write запрос. Тут же появляются темы как бороться с энтропией (anty-entropy) и чинить реплицированные данные (подход Cassandra основан на подходе Amazon Dynamo, про который можно почитать в whitepaper от 2007 года). Тут и пригождается знание алгоритмов и структур данных, например дерева хешей или дерева Меркла (Merkle trees).

4) Про транзакции, точнее lightweight transactions (LWT) и протокол Paxos для достижения консенсуса. Собственно LWT нужно для достижения линеаризуемости, о которой речь шла в знаменитой CAP теореме (подробнее в прошлых постах: Про CAP теорему и Про формализацию CAP теоремы и ее доказательство). Автор объясняет, что чтение с кворума и запись в кворум, которые гарантируют strong consistency, не позволяют предотвратить состояние гонки (race conditions) в случаях, когда клиентам сначала надо прочитать, а потом записать данные. Именно для этого и появляется LWT, который базируется на Paxos (про который надо рассказывать отдельно). Но надо отметить, что

Cassandra’s lightweight transactions are limited to a single partition.

А значит мы не можем гарантировать линеаризуемость, если делаем запрос по разным партициям.

5) Про внутренее устройство движка хранения данных, где у нас есть Memtables, SSTables, and Commit Logs. Это работает так, что запросы на запись мы пишем в commit log и делаем это durable, а дальше записываем данные в in-memory структуру memtable, где каждая memtable содержит данные для специфичной таблицы Cassandra. Дальше при достижении определенного предела memtable записывается на диск (это уже называется sstable - sorted strings table или отсортированная таблица строк). Таких SSTable на диске много и Cassandra периодически их компактит, производя mergesort (опять тут пригодятся алгоритма для понимания).

Дальше интересно обсудить чтение данных, где нам помогают вероятностные структуры данных, а точнее фильтры Блума (Bloom filters). Они позволяют понять, а есть ли искомая запись внутри конкретной SSTable без full scan. Кроме того используются стратегии кеширования для производительности. Плюс удаление записей с append-only структурой хранения выглядит интересно - мы не можем просто удалить запись, так как надо сохранить tombstone о том, что она удалена. Если мы это не сделаем, то при compaction наши удаленные записи оживут ... и не в виде зомби, а полноценными записями:)

Финал обзора в следующем посте.

#Software #Architecture #DistributedSystems #SystemDesign

Сложность и модулярность две стороны одной медали - Влад Хононов - ArchDays 2023 - Part 1 (Рубрика #Architecture)

Интересное выступление Влада Хононова с конференции по архитектуре, в программный комитет которой я состою. В этом выступлении Влад рассказал кратко связь complexity и modularity, которые позволяют ввести интересные метрики качества систем и кода, которые упрощают coupling/connascence/cohesion. Этот доклад основан на материале книги "Balancing Coupling in Software Design", которую я закажу в бумаге сразу после ее издания

Ну а теперь пройдемся по основным мыслям доклада
- Влад определяет систему как набор взаимосвязанных элементов, организованных для достижения цели (это основано на определении Медоуз из книги "Азбука системного мышления", про которую я уже рассказывал)
- Дальше автор идет вглубь уровней абстракций и показывает, что система - это фрактальная история вида: системы -> микросервисы -> неймспейсы -> классы -> методы -> ...
- Возникает вопрос, а в чем разница между компонентами системы и модулем? И автор показывает, что различие не в физических или логических границах. Автор обращается к классическим определением модулей (self-contained, вызывается другими элментами, может быть скомпилированными отдельно). И дальше автор говорит, что у компонентов и модулей отличие в целях - деление на компоненты решает текущую задачу системы, а деление на модули помогает решить будущую задачу, когда система будет эволюционировать.
- Потом автор рассказывает про определение сложности от автора фреймворка Cynefin, где сложность зависит от простоты установления связи между причиной и эффектом. Условно, если мы можем предсказать последствия своих действий в системе, то это простая система. А вот если нам нужны эксперименты для определения взаимосвязи, то комплексная система
- В проектировании софта сложность может быть локальной и глобальной (условно сложность внутри модуля или сложность взаимосвязей между модулями). Понятно, что локальность/глобальность сложности зависит от точки
- В итоге, модульность и сложность - многоуровневые явления, которые можно наблюдать на разных уровнях абстракций.
- Дальше автор показывает метрики сложности, которые приводил uncle Bob в своей книге "Clean Architecture". Кстати, я уже делал краткое саммари ее части про дизайн модулей здесь. Влад в выступлении показывает как можно хачить метрики abstractness, stability, distance from main sequence. Хотя при желании можно похачить любые метрики, а значит и метрики самого Влада, которые он предлагает дальше:)
- Влад предлагает метод оценки через модель интеграции, которая основана на оценке взаимосвязи между элементами системы. Эта модель объединяет coupling/connascence/cohesion. Суть в том, что нам надо оценить интенсивность обмена между модуля по этим связям
- Модель включает четыре уровня, которые идут от самых терминальных случаев к оптимальным (по мере этого уменьшается объем общих знаний между модулями)
1) Intrusive coupling - интеграция через вторжение, когда нарушаются границы инкапсуляции и зависимый модуль получает доступ к внутренней реализации другого модуля. Примеры: взаимодействие через базу данных, использование reflection для доступа к приватным свойствам.
2) Functional coupling - взаимосвязь через функцию или бизнес-требования. Интересно, что тут не обязательно наличие связи в коде.
3) Model coupling - связь через общую модель бизнес домена, структуру данных. Здесь нам дальше сложно эволюционировать общую модель
4) Contract coupling - связь через контракты (API). В DDD для этого есть способы вида published language, anti-corruption layer, etc

Про то, как использовать эту модель я расскаал в продолжении поста, плюс рекомендую другую книгу Влада "Learning DDD" ("Изучаем DDD – предметно-ориентированное проектирование"), про которую я много рассказывал раньше.

#Software #Architect #SystemDesign #SoftwareArchitecture #Processes #Management

Сложность и модулярность две стороны одной медали - Влад Хононов - ArchDays 2023 - Part 2 (Рубрика #Architecture)

Продолжая пост про доклад Влада Хононова на ArchDays 2023, я расскажу про использование модели интеграции для оценки качества архитектуры.
Для оценка Влад предлагает использовать 2 параметра: расстояние между взаимодействующими компонентами и уровень этого взаимодействия (intrusive coupling, functional coupling, model coupling, contract coupling). Получается у нас связь между стоимостью изменения и расстоянием между компонентами, что затрагивают эти изменения. Для того, чтобы отобразить доступные варианты Влад предлагает использовать стандартный подход консультантов с матрицей 2 на 2, где осями являются дистанция и сила связи. В итоге, у нас получается 4 варианта (2 первых предпочтительных и последние 2, которых стоит избегать)
- High distance, low strength - это стандартное loose coupling, когда компоненты далеко друг от друга и они полльзуются contract coupling
- Low distance, high strength - это стандартный high cohesion, когда компоненты рядом и связь между ними сильна
- Low distance, low strength - это локальная сложность, когда у нас в близлежащих компонентах нет связи и при изменениях нам надо пытаться вспомнить, а почему эти компоненты вообще расположены вместе:)
- High distance, high strength - а это стандартная история с глобальной сложностью, когда изменения в вроде бы несвязанных далеких компонентах приводят к спецэффектам наавроде взрыва на макаронной фабрике
Я приложил картинку с визуализацией этой матрицы 2x2.

В итоге, главным уравнением в этом подходе является

Modularity = Strength Xor Distance

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

#Software #Architect #SystemDesign #SoftwareArchitecture #Processes #Management

Музыка от SUSE (Рубрика #Humor)

У компании SUSE есть отличная музыкальная группа, которая делает крутые it версии популярных песен:) Самое то для пятницы - послушать забавную музыку и отдохнуть после сложной недели, которая получилась сложной и для многих моих коллег, но все справились на отлично. А теперь подборка от SUSE:
- Linus Said
- KUBERNETES
- SUSE. Yes Please.
- Every Byte You Take
- Paint it Green
- Remember When
- Can't Stop the SUSE
- We Didn't Start the Kernel
- Uptime Funk
- Coding
- SUSECON
- Open and Wild
- Where Open Source Grows
- Open Source My Way
- The Time Has Come

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

#Humor #Music