Главная » Архитектура ПО » Посмотрите с высоты 300 метров

0

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

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

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

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

Количество зависимостей (class fan out) определяется количеством классов, на которых основана реализация данного класса. Квадрат этой величины определяет стоимость поддержки текущей функциональности. – Примеч. науч. ред.

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

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

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

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

Цикломатическая сложность (cyclomatic complexity) определяется путем подсчета условных и логических операторов, циклов, операторов switch, блоков обработки исключений и т. д. в телах всех методов для определения минимального числа путей выполнения программы. Этот показатель определяет сложность покрытия кода тестами. Значение этого показателя, превышающее 10 (в общем случае), означает срочную потребность в рефакторинге кода. – Примеч. науч. ред.

Источник: Форд Н., Найгард М., де Ора Б., 97 этюдов для архитекторов программных систем. – Пер. с англ. – СПб.: Сим- вол-Плюс, 2010. – 224 с., ил.

По теме:

  • Комментарии