ИИнтуиция

Интуиция — это способность подсознания соединять разрозненные сигналы и опыт в целостное решение.

Сила:
учитывает то, что разум не замечает, и быстро схватывает целое.

Человек чувствует, что собеседник врёт, хотя «логических доказательств» нет — сработали микродвижения и интонация.

Слабость:
может ошибаться, делая выводы по верхам.

Игрок в покер «чует победу» и делает ставку, хотя шансы (по теории вероятности) минимальны.

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

Может ли ИИ заменить разработчика/архитектора?

Оставлю вопрос открытым )

Простая мысль, которую очень сложно донести

"Делать правильно" зачастую неправильно

Быстрота как заинтересованность

Слайды из курса по проектированию высокопроизводительных систем.

Телеграм закрыли, теперь можно выкладывать )

Архитектурное айкидо

Существуют два противоположных мнения, которые уживаются в одних и тех же методичках:
— Архитектура обслуживает бизнес.
— Архитектура ищет баланс между потребностями стейкхолдеров.

Можно объединить эти два «непримиримых» утверждения:
Архитектор использует энергию бизнеса на пользу другим стейкхолдерам.

Неважно, какие цели преследовал Иван IV, выделяя деньги на строительство Покровского собора.
Храм Василия Блаженного до сих пор радует глаз.)

Выносливость как заинтересованность

Продолжаю делиться слайдами

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

Пишу доку для развёртывания системы на одной солидной платформе.
Требуется девятнадцать документов с моделями и расчётами.
И тут на глаза попадается заметка:

В МИ-6 под прикрытием работал агент советской разведки Ким Филби. Вот его воспоминания:

«Благодаря мне сотрудники первого главного управления КГБ СССР могли работать в Великобритании, как говорится, в полный рост, так как сотрудники контрразведки Ми-6 были мной отвлечены на написание никчёмных бумажных справок и отчётов. Когда кто-то из них начинал активно вести работу, вербовать агентуру, выявлять резидентов, я заваливал его никому не нужной бумажной рутиной, и его активность очень быстро сводилась на нет. Я горжусь тем, что лично разработал и ввёл несколько новых форм отчётов».

Наткнулся на такую формулировку:

Модель должна быть как можно более простой, но не проще.

Звучит как Дзен коан. )

Принцип фокусировки

Можно разделить модели по их назначению:
1. Архивирование знания
Запишем сюда всё, для последующей отчуждаемости.
Жаль не работает, так как поддерживать такие модели в актуальном состоянии - адов труд. Вся эта документация по факту теряет актуальность на третий день после написания.
2. Коммуникация
Эти модели строятся под заказ и под заказчика.
Ориентированы на аспекты интересные стейкхолдеру.
Должны быть просты и доступны.
Чаще всего одноразовы.
Показали и спрятали в ADR для истории.
3. Модели для моделирования
То, что я использую для принятия архитектурного решения.
Объективизация мысли.
Такие модели подобны зрительным образам.
Мозг схватив пару важных деталей сам достроит недостающую картинку.
Но если заметит аномалию, или что-то непонятное, то глазу придётся сфокусироваться.
Фокусируемся на непонятном и сложном.
Зачем мне в сотый раз описывать таблицу логов ? )

☝️☝️☝️

Контекстные допущения и остаточные риски

Есть очень "неуютные" кейсы принятия решений под давлением обстоятельств.

Например:

1.
Менеджер:
— Мне сегодня к вечеру нужен технологический стек, иначе мы не согласуем договор.

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

3.
Саппорт:
— Ты, конечно, можешь получать идешки из MDS, но очень не советую. По факту это сырая поделка, которая умеет только падать.

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

Например:

Контекстные ограничения:
Интеграция с существующей master data системой (MDS) исключена контекстными ограничениями.

или

Остаточные риски (Residual Risks):
Решение о выборе БД было принято при не выявленных требованиях к производительности и обусловлено требованиями жизненного цикла. Сохраняется риск несоблюдения будущих контрактов.

Выглядит красиво, но по-моему у нас так никто не делает )

Манифест расширенной модели требований

1. Принцип дополненного ТЗ
Контракт в ТЗ (бумажное ТЗ от заказчика) — это лишь надводная часть айсберга. Архитектор не просто пассивно принимает его, а проактивно генерирует внутреннюю (инженерную) модель требований.

2. Принцип легитимности
Архитектор имеет полное инженерное и моральное право «докидывать» свои требования, поскольку они не высасываются из пальца, а являются единственным физическим способом обеспечить:
- Либо явные, проявленные показатели (FR, NFR).
Пример: декомпозиция «1 секунды отклика» на бюджеты задержек микросервисов.
- Либо скрытые, непроявленные заинтересованности заказчика.
Пример: проектирование модифицируемости ради выживания бизнеса на динамичном рынке.

3. Ловушка формального соответствия
Проектное решение обязано целиться исключительно в архитектурную (расширенную) модель требований.
Если спроектировать систему только под явный контракт заказчика проект формально попадет в метрики ТЗ, но может провалиться в реальной жизни, потому что разрушит скрытые заинтересованности
(система будет невыносимо дорогой в поддержке, не сможет масштабироваться или умрет от блокировок).
___

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

Правильно

Стоит отметить, что слово "правильно" в архитектуре означает "согласовано с моим пониманием", и ничего больше.