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

Джереми Мейер (Jeremy Meyer) занимается проектированием и разработкой программного обеспечения, а также преподаванием в течение почти 20 лет. В настоящее время он является ведущим консультантом Borland Software в области моделирования и проектирования.

На самом деле «я» в архитектуре, конечно, существует. Но это не заглавное «Я», привлекающее к себе внимание и доминирующее во всех обсуждениях. Строчной буквы вполне достаточно.

Как это относится к нам — архитекторам программных продуктов? Наше эго подчас оказывается нашим самым опасным врагом. Кто из нас не встречал архитекторов, которые:

• считают, что они понимают требования лучше заказчиков,

• рассматривают разработчиков как ресурс, нанятый для реализации их идей,

• в штыки воспринимают любые сомнения в своих идеях или игнорируют идеи других?

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

Почему это происходит?

Мы уже добивались успеха. Успех и опыт развивают уверенность в себе и позволяют нам стать настоящими архитекторами. Успех ведет к более крупным проектам. Однако грань между уверенностью в себе и самонадеянностью весьма тонка. В какой-то момент проект выходит за рамки наших возможностей. Самонадеянность начинает проявляться тогда, когда мы пересекаем эту черту, но не хотим это признать.

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

Все мы люди. Архитектор вкладывает в каждую архитектуру частицу самого себя. Критика ваших творений воспринимается как нападки лично на вас. Поддаться искушению и занять оборонительную позицию легко; научиться не делать это сложно. Гордиться своими достижениями легко; научиться без специальных усилий чувствовать пределы своих возможностей сложно.

Как этого избежать?

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

Сосредоточьтесь на своей команде. Члены команды — это не просто ресурс; это ваши помощники по проектированию и ваша «страховочная сетка». Из людей, которые чувствуют себя недооцененными, обычно получается плохая «подстраховка». Архитектура формируется командой, а не лично вами. Вы даете указания, но трудную работу выполняют все вместе. Их помощь нужна вам в не меньшей степени, чем им — ваша.

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

Наблюдайте за собой. Большинству из нас приходится побеждать в себе природную склонность защищать свою работу, заботиться только о собственных эгоистических интересах и считать себя самым умным человеком в комнате. Под давлением эти склонности всплывают на поверхность. Уделяйте ежедневно несколько минут размышлениям о том, как происходило ваше взаимодействие с окружающими. Отнеслись ли вы к идеям всех своих собеседников с должным уважением и признательностью? Не было ли с вашей стороны отрицательной реакции на ценные предложения? Действительно ли вы понимаете, почему кто-то не согласился с вашим подходом?

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

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

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

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

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

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

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