Все начинается с Архитектуры

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

В жизни Архитектора программного обеспечения редко встречаются моменты беззаботного веселья. Моя задача — сделать так, чтобы программы, составляющие основу наших продуктов, были гибкими, быстрыми, расширяемыми, надежными, согласованными, связанными, не содержали дублирующих компонентов и к тому же допускали использование максимально эффективных методов разработки. На первый взгляд, в этом нет ничего сложного — при условии, что все программисты, а также менеджеры стремятся обеспечить все эти качества, не так ли? Увы, в нашей отрасли отношение к делу, определяемое формулой «я этого не делал и мне это не нужно», распространилось уже в угрожающих масштабах. Иногда, даже когда удается внедрить Архитектуру, менеджеры и разработчики все равно умудряются ее игнорировать. Я бы стал миллионером, если бы получал по доллару за каждую услышанную фразу наподобие следующей: «У меня нет времени для того, чтобы добиваться соответствия этой программы нашей архитектуре, я должен сдать ее немедленно». Подобное отношение может возникнуть из-за незнания, высокомерия или демонстративного небрежения программиста, но, как бы там ни было, итог все один: программной архитектуры либо нет вовсе, либо она внутренне противоречива.

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

Технология как архитектура

Недавно мне пришлось разговаривать с одним из клиентов, и тот, без тени сомнения, заявил, что архитектурой информационных систем его компании является Java Message Service (JMS). Обратите внимание, он не сказал, что архитектура компании опирается на обмен сообщениями или что основу ее реализации составляет JMS. Нет, он просто заявил, что их архитектура — это JMS.

За годы работы мне не раз приходилось слышать подобные заявления, и каждый раз я не перестаю удивляться. JMS сама по себе — это спецификация на интерфейс, т.е. основанный на Java стандарт для доступа к программному обеспечению промежуточного слоя, ориентированному на обмен сообщениями, и для использования подобного программного инструментария. JMS в состоянии помочь в реализации архитектуры, но сам по себе архитектурой не является. Более того, поскольку JMS определяет интерфейс, а не его реализацию, то нет никаких гарантий, что две различные реализации JMS будут полностью взаимозаменяемы. В силу этого утверждение моего клиента оказывается еще более ошибочным, чем это кажется на первый взгляд. То, что он принимает за архитектуру своей компании, на самом деле, не JMS, а лишь реализация JMS от конкретного производителя.

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

Учитывая, сколь высоки затраты на перепроектирование, вне зависимости от объема изменений в базовой технологии, я не перестаю удивляться, почему разработчики сами себя загоняют в ловушку. Возможно, следуя Теории Конспирации, они это делают для того, чтобы обеспечить необходимую секретность своей работы, но большинство ИТ-специалистов из тех, с кем мне приходилось встречаться, просто об этом не думают. Во многом это происходит просто из-за недостатка абстрактного мышления. Одни разработчики не в состоянии отделить имеющиеся задачи от технологий, используемых для их решения. Другие считают, что у них просто нет времени на выработку приемлемых абстракций. Действительно, отношение «Отстаньте от меня, эту программу я должен был сделать еще вчера», о котором я уже упоминал, в ИТ-отрасли превалирует. Может быть, именно тогда, когда мудрец представил себе мир, заполненный реализованными впопыхах системами промежуточного слоя, ему пришла в голову фраза «поспешишь — людей насмешишь»?

Архитектура указывает не только, чем система является, но и также то, чем она не является. Чем больше архитектура содержит абстракций, правил и ограничений, которые определяют, что может делать система, в то же время избегая конкретных «технологий сегодняшнего дня», тем вероятнее, что ее можно будет корректно совершенствовать. Я, например, помогал создавать определения архитектуры для программного обеспечения промежуточного слоя, руководствуясь двумя простыми практическими принципами. Во-первых, создавать детальные определения для важных системных абстракций, или метафор, следя за тем, что все члены команды разработки с ними ознакомлены. А во-вторых, писать ключевые внутренние системные интерфейсы на CORBA IDL.

Создание определений в терминах IDL (а не на Java или на C++) позволяет повторно использовать интерфейсы для различных языков и описывать основные компоненты сервисных интерфейсов, не вдаваясь в излишние детали реализации. Оба принципа дают возможность любому разработчику с помощью Web-браузера и выбранного редактора (предпочтительно, конечно, emacs) выразить основные элементы и правила архитектуры на приемлемо высоком уровне абстракции.

Недостаток опыта в создании абстракций может особенно негативно проявиться в контексте сервис-ориентированных архитектур (service oriented architecture, SOA) [1]. Развертывание SOA требует, чтобы сначала были определены абстракции сервисов. Этим она отличается от традиционного подхода, при котором сначала пишут приложения, а затем создают конкретные сервисы, необходимые этому приложению. При использовании SOA цель состоит в том, чтобы создать сервисы на приемлемом уровне абстракции, рассчитанные на многократное использование в различных приложениях, а не жестко привязанные к одному приложению.

Кодирование vs. проектирование

Когда я занимал должность главного архитектора, мой работодатель решил внедрить в компании методологию экстремального программирования (eXtremal Programming, XP) [2, 3]. И хотя некоторые разработчики решительно возражали против принятия XP, в конечном итоге, мы были вынуждены на него согласиться, когда наш генеральный директор, в прошлом также разработчик, впрямую этого потребовал. Поскольку XP во многом опирается на подход, похожий на весьма успешные методы итеративной разработки, которые я внедрил в компании несколькими годами ранее, я активно поддержал указание генерального директора.

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

Внедрение XP у многих вызвало негативную реакцию. Громче всех свое недовольство высказывали как раз разработчики, обладавшие большим опытом проектирования программ и создания абстракций. Они жаловались на то, что XP заставляет забыть об архитектуре и проектировании и заменяет их «программированием по-ковбойски». Они утверждали, что XP дает разработчикам свободу писать все, что они хотят, так что в результате система работает вовсе не так, как ожидалось [4]. Предполагалось, что так называемый «рефакторинг» станет методическим способом совершенствования реализации программного обеспечения, не затрагивая его внешний интерфейс или методы использования. Однако, к сожалению, этот подход зачастую используют просто как оправдание бесконечным переделкам. Хотя XP, конечно же, не оправдывает подобную чепуху, он может способствовать формированию менталитета «одинокого стрелка», особенно при отсутствии должного общения с другими членами команды. XP и другие итеративные методы рассчитаны на то, что каждый член команды знает, что делают другие. Фактически, XP поддерживает парное программирование, при котором два разработчика сидят за одной клавиатурой и интерактивно предпринимают действия, реализующие проект и его тесты. Такой подход, в частности, помогает уберечься от негативных эффектов деятельности ковбоев от программирования.

Те, кто противится внедрению XP, могут стать его сторонниками, если мы примем методологию формирования архитектуры на базе моделей (model-driven architecture, MDA) [5]. MDA, следуя традициям структурного и объектно-ориентированного программирования, поддерживает открытое проектирование. Однако, в отличие от них, MDA рассматривает код как результат, который инструментарий генерирует на основе проектных моделей, а не как текст, написанный разработчиком. Аргументы в поддержку MDA кажутся вполне логичными. Действительно, вся история программной разработки — это эволюция от написания машинного кода к созданию программ на языке Ассемблера и дальше, к программированию на языках высокого уровня, таких как Java и C++. С каждым последующим шагом увеличивался и уровень абстракции. Естественный прогресс — это движение от низкоуровневого программирования, при котором вы только пишете код, к высокоуровневой разработке путем создания моделей системы, оставляя при этом сам процесс «программирования» инструментальным средствам генерации кода. К этим попыткам относятся использование шаблонов анализа [6] и метаданные для создания платформонезависимой модели (platform independent model, PIM), на основе которой инструментарий генерирует код, называемый платформозависимой моделью (platform specific model, PSM), для конкретной платформы или системы промежуточного слоя (скажем, J2EE, CORBA или MOM). PSM не только позволяет использовать шаблоны, специфические для нижележащей платформы, но и общие шаблоны проектирования [7]. В определенном смысле MDA требует наличия инструментальных средств, которые играют роль, аналогичную роли инструментария, который ранее приходилось использовать для определения и проектирования модульных интегральных схем.

Ориентированность MDA на инструментарий (что, на первый взгляд, кажется достоинством), на практике может иметь негативный эффект. Пользователи программ промежуточного уровня знают, что стандарты помогают максимально ослабить зависимость от программных продуктов конкретной компании и минимизировать затраты при переходе на другие, также соответствующие стандартам продукты. При правильном использовании стандарты также позволяют организациям, созданным в результате приобретений или слияний нескольких предприятий, без труда интегрировать свои программные системы, вместо того, чтобы полностью отказываться от некоторых систем и заменять их другими. К сожалению, инструментарий, который требуется для MDA, может легко перенести «привязанность к производителю» с самого программного обеспечения на инструментарий, который создает это программное обеспечение. Верно и то, что стандарты на инструментарий, которые сейчас создаются, могут предотвратить эту проблему, но, в общем, потребуется время на то, чтобы эти стандарты стали зрелыми настолько, чтобы инструментальные средства разных производителей действительно могли работать друг с другом.

Апологеты XP и MDA могут с этим не согласиться, но у обоих подходов есть нечто общее, а именно, понятие метафоры. В терминах XP, метафора — это слово или короткая фраза, которая выражает основную идею проекта. Метафоры XP несколько напоминают названия ключевых объектов в модели MDA. В XP допускается использование слов для выражения метафор, в то время как MDA использует языки моделирования и диаграммы, но намерения в обоих случаях одни и те же: выразить основные элементы системной архитектуры максимально кратко, но при этом содержательно.

Лично я больше склоняюсь к XP, а не к MDA. XP вращается непосредственно вокруг главной ценности, составляющей основу программной системы: самого кода. Без кода не существует системы. Судя по моему опыту, сторонники MDA предпочитают рассматривать код как побочный результат, который инструментарий просто генерирует на основе подходящих моделей. Хотя я не сомневаюсь, что в один прекрасный день мы поймем истинную цель движения к более высокому уровню абстракции, думаю, что это произойдет очень нескоро. Переход от одного уровня абстракции к другому на практике — вещь довольно сложная [8]. Специалисты по MDA признают, что пройдут годы, прежде чем можно будет на самом деле генерировать код сложных программ промежуточного слоя, которые смогут корректно решать такие задачи, как многопоточность, транзакции, балансировка нагрузки и автоматическое восстановление после сбоев. Прежде чем настанет этот день, мы разработаем еще множество систем, и пока я остаюсь сторонником итераций, разделяемого кода, тесного сотрудничества с пользователями и методов рефакторинга, аналогичных тем, что предлагает XP.

Две головы лучше

Описанный выше подход, четко определяющий метафоры системы, а также интерфейсы и контракты средствами абстрактных языков наподобие IDL, можно реализовать и в рамках XP, и в рамках MDA. Конечно, у каждого свой опыт, но лично я считаю, что, когда эти принципы реализуются на основе открытого и активного общения между членами группы, они позволяют легко избежать необходимости готовить многословные документы с описанием архитектуры или использовать специализированный инструментарий для рисования и хранения диаграмм Unified Modeling Language.

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

Литература

1. S. Vinoski, "Service Discovery 101", IEEE Internet Computing, vol. 7, no. 1, 2003.
2. K. Beck, Extreme Programming Explained: Embrace Change, Addison Wesley Longman, 1999.
3. C. Poole, J.W. Huisman, "Using Extreme Programming in a Maintenance Environment", IEEE Software, vol. 18, no. 6, 2001.
4. M. Fowler, Refactoring: Improving the Design of Existing Code, Addison Wesley Longman, 1999.
5. D. Frankel, Model Driven Architecture: Applying MDA to Enterprise Computing, John Wiley & Sons, 2003.
6. M. Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997.
7. E. Gamma et al., Design Patterns - Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.
8. S. Vinoski, "It's Just a Mapping Problem", IEEE Internet Computing, vol. 7, no. 3, 2003.

Steve Vinoski, Do You Know Where Your Architecture Is? IEEE Internet Computing, September-October 2003.

На пути к интеграции

Если компании не удалось выстроить системную архитектуру, то ее специалистам придется переписывать систему при внедрении каждой новой технологии.