97 этюдов для архитекторов программных систем

Исключение «Я» из архитектуры не гарантирует успеха. Оно всего лишь устраняет распространенный источник ошибок, происходящих только по вашей вине.

Биография автора приведена ранее.

Посмотрите с высоты 300 метров

Эрик Дорненбург

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

Маленькие квадратики на архитектурных диаграммах представляют целые системы, а линии между ними могут обозначать все что угодно: зависимости, потоки данных или совместно используемые ресурсы (например, шину). Такие диаграммы изображают систему с высоты 10 километров, примерно в таком же масштабе, в котором мы видим ландшафт с самолета. Единственной альтернативой, как правило, является исходный код, который можно сравнить с видом на уровне земной поверхности. Оба представления не в силах передать сколько-нибудь существенной информации о качестве программного продукта: одно находится на слишком высоком уровне, а другое настолько перегружено деталями, что за ними не видно структуры. Очевидно, не хватает промежуточного варианта — взгляда с высоты 300 метров.

«Вид с высоты 300 метров» предоставляет информацию на нужном уровне. Он объединяет большие объемы данных и различные метрики (количество методов, количество зависимостей,[13] цикломатическая сложность[14]

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

Создавать такие представления вручную и поддерживать их синхронизацию с программой — безнадежное занятие. Нужны инструменты, которые способны создавать такие представления на основе единственного надежного источника информации — исходного кода. Для некоторых представлений, скажем для структурной матрицы решений (design structure matrix), существуют коммерческие инструменты, однако специализированные представления на удивление легко создаются посредством объединения небольших инструментов, извлекающих данные и метрики, с общими пакетами визуализации. Простой пример: вывод Checkstyle (по сути, набор метрик уровня классов и методов) загружается в электронную таблицу для построения диаграмм. Те же метрики могут отображаться и в формате ТгееМар с использованием инструментария InfoViz. Отличным инструментом для отображения графов сложных зависимостей является также GraphViz.

Как только подходящее представление найдено, качество программного продукта начинает восприниматься менее субъективно. Появляется возможность сравнивать разрабатываемый продукт с другими подобными системами. Сравнение разных версий одной системы позволяет выявлять тенденции, а сравнение представлений различных подсистем способно выявить резкие отклонения от нормы. Даже с одной-единственной диаграммой мы можем положиться на свое эстетическое чувство и умение подмечать закономерности. Хорошо сбалансированное дерево, вероятно, отражает удачную иерархию классов; гармоничный набор прямоугольников может изображать код, организованный в виде классов правильного размера. В большинстве случаев работает весьма простой принцип: то, что хорошо выглядит, скорее всего, хорошо устроено.

Эрик Дорненбург (Erik Doernenburg) — технический директор компании ThoughtWorks, Inc.; он помогает клиентам в проектировании и реализации крупномасштабных систем уровня предприятия.

Пробуйте, прежде чем сделать выбор

Эрик Дорненбург

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