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

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

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

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

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

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

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

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

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

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

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

В своем труде, посвященном бережливой разработке (lean development), Мэри и Том Поппендик (Магу и Tom Poppendieck) описывают методику принятия решений. Они считают, что принятие окончательного решения следует откладывать до самого ответственного момента — той точки, когда отсутствие у команды решения приведет к тому, что решение будет принято за нее, а бездействие повлечет за собой необратимые (или труднообратимые) последствия. И это разумно: ведь чем позднее принимается решение, тем больше информации для его принятия. Однако во многих случаях «больше информации» не равносильно «достаточно информации», а лучшие решения, как всем хорошо известно, принимаются «задним числом». Что это означает для хорошего архитектора?