Метрика сцепленности по языку

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

Задача: определить, что границы между контекстами проведены верно. То есть внутри контекста функции сцеплены по языку сильно, а между контекстами слабо.

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

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

2. Далее я решил сравнивать по свойствам сущностей (атрибутам и методам). Чем больше общих свойств - тем ближе должны быть функции.

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

Так как мапить мне было лень, на этом идея выдохлась (

Возможно у подобного подхода есть потенциал. Оставлю здесь. Надеюсь еще пригодится )

Качества архитектуры
«Вначале была модель» (Книга, И:1:1).

Рассмотрим архитектуру как Большую Модель,
то есть множество моделей системы, описанных разными языками.

Какими качествами должна обладать эта модель?

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

Я же вслед за М. Фаулером и Джорджем Боксом считаю, что модель не может быть правильной или неправильной.
Она может быть полезной или бесполезной:
- «Models are not right or wrong; they are more or less useful» (Martin Fowler).
- «В сущности, все модели неправильны, но некоторые полезны» (George E. P. Box).

2. Полезность
Полезность модели — вопрос интересный.
Том ДеМарко считает, что любая, даже очень простая модель может принести пользу.
Достаточно того, чтобы модель предсказывала что-нибудь хоть чуток наперёд и хоть чуточку точно.

Однако это не даёт ответа на вопрос, стоит ли, например, строить сложную мат. модель производительности или можно обойтись простыми предположениями.
Насколько «полезной» должна быть модель?

Меру полезности, неожиданно, предлагают менеджеры, представляющие буржуазию.
У них это называется «выгода» .
Если прибыль от модели будет выше, чем затраты на её производство и поддержку, то модель безусловно полезна.

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

3. Истинность
И. Ньютон, нисколько не смущаясь, обосновывал истинность своих гипотез их пользой -
«Теория работает, значит она верна» .
Ньютону вторят Басс, Клемантс и Казман: «The right architecture paves the way for system success» .
И даже у Владимира Ильича близкое: «Теория Маркса верна, так как она всесильна» .

Я, вслед за Декартом, с подозрением отношусь к этому подходу.
Это опять нас притягивает к понятию «правильной модели» .

Остановлюсь на архитектурном эквиваленте истинности — целостности.
Пусть модель будет внутренне непротиворечивой — этого достаточно.

4. Полнота
Сразу нет!
Во-первых, это дорого.
Во-вторых, не нужно.
В-третьих, недостижимо (спасибо за разъяснения Геделю).

5. Красота
Модель должна быть красивой.
Зачем — не знаю.
Говорят, красивый инструмент повышает продуктивность. Возможно.
Как оценить красоту, тоже не знаю.
У меня есть только одна метрика для этого качества — лаконичность.

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

Остальное — блажь )

Архитектурные решения «снизу»

В позднем Agile стало модно говорить о возникающих в процессе разработки проектных решениях (Emergent Design) как об архитектуре снизу.

Часто слышу на статусах фразу «Это архитектурное решение принял разработчик».

Корректно ли это?

Архитектурное решение по определению — это значимое и обоснованное проектное решение.

Что значит значимое?
Это значит, что такое решение сложно или даже невозможно отыграть назад.
То есть решение необратимое или сложно обратимое.
Может ли разработчик принять такое решение?
Вполне. )

Что значит обоснованное?
Или иначе — чем обосновывается архитектурное решение?
Архитектурное решение обосновывается потребностями стейкхолдеров.
Это либо решение, которое всех устраивает, либо, наоборот, решение, которое всех не устраивает, но в одинаковой степени (компромисс).
Архитектор, половину рабочего дня проводящий на встречах и в обсуждениях, имеет в виду интересы стейкхолдеров.
Разработчик чаще всего имеет в виду интерес единственного стейкхолдера — себя.

Среднестатистический разработчик думает о том, как сделать проще, быстрее, красивее или, в худшем случае, «правильнее».
Архитектор думает о том, что скажут ИБ, ФСБ, поддержка, архком со своим планом импортозамещения и прочие прочие.

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

P. S.
Мне часто возражают, дескать, наши разработчики знают всё о проекте и способны обосновать свой дизайн.
Отвечаю:
Если разработчик в теме всех стейкхолдерских хотелок, если он активный участник бесчисленных встреч и обсуждений (успевающий еще и покодить), то он и есть архитектор. )

Анализ производительности

Долго искал удобный инструмент для анализа и поддержки модели производительности.
Начинал с Excel. Потом открыл для себя язык R и R Studio.

Остановился на Jupyter Notebook (https://jupyter.org/).

Открытый, интерактивный, хорошо интегрируемый инструмент.
Пишу на любом удобном мне языке:R, Kotlin, Python.

В общем, рекомендую. )

Анализ производительности (пример)

Вдогонку к предыдущему посту небольшой пример на основе реальных данных
(Когда-то моделировал решение под СМЭВ.)
Пристегнул сам блокнот и экспорт результата в PDF

Примеры модели производительности

В личке попросили примеры по перформанс моделированию.
К сожалению, сразу не ответил и потерял чат (

Выложу сюда.
- atm_queue.ipynb
Пример использования simple simulation model (kalasim)
- Cache.ipynb
Расчёт эффективности кэша по пропускной способности (модель QNM)
- MG1.ipynb
Расчёт времени отклика для очереди M/G/1 (модель QNM)
- Scalability.ipynb
Определение масштабируемости системы по модели USL

Математическое моделирование производительности

Так как речь зашла о мат. моделировании производительности, хочу обозначить свою позицию.
- Даже самая продвинутая мат. модель даёт крайне не точное приближение к реальности. Огромное количество факторов влияющих на показатели производительности не учитываются моделью.
- Использую мат. модели (количество) исключительно для представления оптимистичного и пессимистичного сценария, то есть для определения возможных границ значений.
- Вариант, который в SPE (QNM) называют реалистичным, рассматриваю как (крайне) оптимистичный.
- Использую мат. модели (качество) для определения зависимостей нужных качеств. От зависимостей строю тактики улучшения качества.

И небольшой пример реального распределения времени обслуживания для функции выполняющей delay(20) (рисунок).

Вместо красивой линии на 20ms имеем 4 моды из которых я могу объяснить только три )

Онтология в программной архитектуре

К сожалению, тема звучит как насмешка.

Программную архитектуру поддерживают специалисты с инженерным мышлением.
Основной инструмент - эвристика.
"Уха помогает от простуды плотнику, но не помогает слесарю ..."

Термины в нашей области используются, без оглядки на их смысл в других контекстах.
Есть нечто, что надо назвать?
Выдернем первый подходящий понравившийся термин из смежных областей знаний.
И появляются на свет такие оксюмороны как изменяемые сущности (Entity в DDD).

Особое спасибо хочется предъявить Эрику Эвансу за домены и поддомены.

Изначально домен — это просто набор чего-либо встроенный в иерархическую (доменную) структуру.
С легкой руки аналитиков домен (domain) напрочь завязан на понятие предметной области (Subject Area).

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

Теперь опускаемся вниз по доменной структуре, выделяя в пространстве проблем подобласть.
В частности подобласть с единым языком. Как же ее назвать? Естественно поддомен!

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

Не судьба была назвать любую предметную область доменом и выделить в иерархии две их разновидности:
- "проблемную область" (сверху),
- "область общего языка" (снизу)?

Или подход как у Microsoft:
Чем больше путаницы в терминах, тем больше заработаем на обучении?

____

P. S. Написал после очередных объяснялок.
Если кого задел, прошу прощения, накипело)

#ворчалка

Анaлитические шаблоны | Analysis Patterns
https://violettape.github.io/ap_book/cover.html

☝️ Долгожданный перевод первой работы М. Фаулера "Аналитические паттерны".

Ждал с 1997 )

ИМХО одна из лучших работ автора, во многом предвосхитившая идеи DDD.

Качества архитектуры

В чате канала мне подсказали интересную мысль:
"В книге Righting Software Джувел Лёве определяет еще одно качество, которое, вероятно, можно отнести к красоте - это симметричность."

Добавляю в список метрик красоты:
- лаконичность,
- симметричность.

Если есть еще накидывайте в коменты.
Буду очень благодарен )

Вопрос наименования

Как назвать специалиста, формирующего множество моделей системы с целью предсказывать/объяснять её поведение?
Я бы назвал моделистом, но почему-то все называют архитектором. )

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