Disclaimer: Статья Мартина Фаулера была опубликована в 2003 годув журнале IEEE Software. В сети (но не на Хабре) есть замечательный перевод пятилетней давности от Сергея Теплякова (SergeyT).
Недавно я встретил в коридоре явно раздраженного коллегу, Дэйва Райса (Dave Rice). Мой вводный вопрос вызвал резкое заявление: «Нам надо игнорировать любого кандидата, имеющего пункт «Архитектор» в резюме». Смущало в этой странной фразе то, что мы же сами, обычно, представляем Дейва как одного из наших ведущих архитекторов.
Причиной его «титульного психоза» являлся тот факт, что по меркам даже нашей индустрии, смысл слов «архитектор» и «архитектура» чрезвычайно переоценен. Многим кажется, что к термину «архитектор программного обеспечения» отлично подходит тот самодовольный и все контролирующий образ из финальных сцен «Матрица: Перезагрузка». Но даже в компаниях относящихся с большим презрением к такому отображению, все равно, существует жизненно важная роль технического лидера, в сущности – архитектора, такого, как сам Дейв.
Что такое архитектура?
Когда я изводил себя по поводу названия книги «Архитектура корпоративных программных приложений» (Patterns of Enterprise Application Architectureб Addison-Wesley, 2002), каждый наш рецензент соглашался, что «архитектура» попала в заголовок по праву. Однако у всех нас возникли сложности с попытками дать определение этому слову. Так как это была моя книга, я чувствовал, что был обязан разделаться с этим понятием.
Первым порывом уйти от неясности было – удариться в цинизм. В известном смысле я определял архитектуру как слово, которые мы используем, когда хотим обсудить дизайн, пытаясь, при этом, придать ему побольше важности. (Да, это же можно применить и к архитекторам). Как это часто случается, однако, в любом разливе цинизма обнаруживается капля истины. Понимание пришло ко мне после прочтения сообщения Ральфа Джонсона (Ralph Johnson) из списка рассылки «Экстремальное программирование». Переписка была настолько хороша, что я приведу ее тут полностью.
В предыдущем сообщении говорилось:
RUP, опираясь на определение IEEE, описывает архитектуру как «самое высокоуровневое понятие о системе в рамках ее среды. Архитектура программной системы (в заданный момент времени) – это ее организация или структура важных компонент, взаимодействующих через интерфейсы, где каждая из компонент собрана, в свою очередь, из еще более мелких составных частей и интерфейсов».
Джонсон ответил:
Я был рецензентом упомянутого стандарта IEEE и доказывал, безрезультатно, что это было целиком и полностью фальшивое определение. Нет никакого высокоуровневого понятия о системе. У пользователей свое видение системы, отличающееся от того, чем оперируют разработчики. Пользователям вообще нет никакого дела до структуры важных составных частей. Да, возможно архитектура и является самым высокоуровневым представлением разработчиков о системе в рамках среды. Но давайте забудем о тех разработчиках, которым доступно понимание лишь своего небольшого участка. Архитектура – это самое высокоуровневое представление системы разработчиками-экспертами. Что делает определенный компонент важным? Он важен, потому что так сказал эксперт.
Таким образом, лучшим определением могло бы быть: «В наиболее успешных проектах разработки ПО, наиболее высококвалифицированные разработчики, работающие над данным проектом, имеют одинаковое представление о дизайне системы. Такое совместное понимание и называется «архитектура». Это понимание включает в себя то, как система делится на компоненты и как эти компоненты взаимодействуют между собой через интерфейсы. Данные компоненты обычно составлены из более мелких частей, однако архитектура включает в себя только те составные элементы и интерфейсы, которые понятны сразу всем разработчикам».
Такое определение могло бы оказаться лучшим потому, что становится ясно, архитектура – это общественный конструкт (да, само программное обеспечение тоже, но архитектура в еще большей степени), потому что она зависит не просто от ПО, но от того, какие части ПО признаны важными в результате согласованного мнения группы.
Есть и другой способ определения архитектуры, вроде такого: «архитектура – это набор решений, которые должны быть приняты на ранней стадии проекта». Такой вариант я тоже критиковал, указывая, что архитектура – это решения которые вы хотели бы принять правильно в самом начале проекта, при том, что не факт, что они окажутся более удачными, чем любые другие.
В любом случае – по второму определению, для большинства проектов, язык программирования окажется частью архитектуры, а по первому – нет.
Является ли что-либо частью архитектуры – полностью зависит от того, расценивается ли это как важное разработчиками. Люди, которые создают «корпоративные» приложения считают критически важной персистентность. Когда они начинают обрисовывать архитектуру, сразу получают три уровня. Упомянут что-то вроде «мы используем Oracle в качестве нашей базы данных и создадим свой слой хранения для отображения в нем объектов». А вот приложение для медицинских снимков может включать технологии Oracle без рассмотрения их с архитектурной точки зрения. Так происходит потому, что самые большие трудности для них заключаются в обработке изображений, а не в хранении. Получение и сохранение изображений обеспечивается лишь маленькой частью приложения и большинство разработчиков ее попросту игнорируют.
Именно это делает сложным делом объяснение людям того, как им описывать архитектуру. «Скажите нам, что здесь важно». Архитектура о важных вещах. Чтобы под ними не подразумевалось.
Роль архитектора
Итак, если архитектура — это о важных вещах, тогда архитектор — это персона (или группа людей), который заботится о важных вещах. И тут мы подходим к сути отличия вида архитектора из «Матрица: Перезагрузка» с тем стилем, который представлен в лице Дэйва Райса.
Аркитектус Рилаудус (Architectus Reloadus) – это персонаж, который принимает все важные решения. Архитектор занимается этим, потому что для обеспечения концептуально целостной системы необходим единый взгляд и, возможно, потому что архитектор не считает членов команды достаточно квалифицированными, чтобы принимать такие решения. Часто такие решения нужно принимать на самых ранних стадиях, чтобы у всех остальных имелся план, которому они могли бы следовать.
Аркитектус Оризус (Architectus Oryzus) это другой зверь (если не получается угадать, попробуйте archives.nd.edu/latgramm.htm). Такой тип архитектора должен быть очень внимателен к тому, что происходит в проекте, выискивая важные вопросы и решая их до того, как они превратились в серьезные проблемы. Когда я наблюдаю за архитектором такого рода – я вижу, что самая заметная часть его работы – это интенсивное сотрудничество. По утрам такой архитектор программирует вместе с разработчиками, выискивая наиболее общий «стопорящий» код. Днем этот архитектор участвует в собраниях по определению требований, помогая объяснять разработчикам требований технические последствия некоторых из их идей через нетехнические понятия, такие как стоимость разработки, например.
Во многих отношениях самым важным занятием Аркитектуса Оризуса является наставничество для команды, подъем ее до уровня, на котором она сможет решать более сложные вопросы. Повышение способностей команды дает в руки архитектору гораздо более сильный рычаг, чем из положения одинокого руководителя, что, в свою очередь, помогает избегать опасности стать архитектурной пробкой проекта. Это подводит нас к эмпирическому правилу: ценность архитектора обратно пропорциональна количеству решений, которые он или она принимают.
На недавнем выездном собрании ThoughtWorks я обсуждал с некоторыми из коллег тему архитекторов. Мне показалось интересным, что мы быстро пришли к единому мнению о природе должности, имея в виду Аркитектуса Оризуса, но вот подобрать ему название было уже непросто. Аркитектус Рилаудус же, слишком знаком нам, чтобы причислять его к «архитекторам», и, кроме того, основан на некорректной метафоре (см. тут). Майк Ту (Mike Two) предложил лучшее название из тех, что мне довелось услышать: проводник, в альпинистском смысле. Проводник – это более опытный и умелый член команды, который учит остальных участников группы лучше справляться с опасностями самостоятельно, и, в тоже время, всегда оказывается рядом в особо сложных случаях.
Избавляясь от архитектуры ПО
Люблю писать провоцирующие заголовки, лучшие из которых, как и в данном случае, содержат важный, но не всегда очевидный изначально, смысл. Вспомните второе определение от Джонсона: «Архитектура — это решения, которые вы хотели бы принять без ошибок еще на ранних стадиях проекта». Почему людям кажется, что некоторые моменты надо решить правильно уже в самом начале проекта? Суть в том, что они, очевидно, считают данные элементы слишком сложными для изменения в будущем. Т.е. в итоге мы можем перефразировать определение архитектуры как «элементы, которые люди считают сложными для изменения в будущем».
Общепринятым в построении корпоративного приложения, например, считается необходимость определиться со схемой базы данных с самого начала. Потому что изменить схему базы действительно сложно, особенно если приложение уже используется. В одном из наших проектов, администратор БД Прамод Садалаж (Pramod Sadalage) придумал систему, позволявшую нам менять схему (и переносить данные) без проблем (см. тут, а тут перевод). Сделав это, он исключил схему БД их разряда архитектурных элементов. Я считаю это решение замечательным, так как оно позволило нам лучше справляться с изменениями.
Экономист Энрико Занинотто (Enrico Zaninotto), в восхитительном выступлении на конференции XP2002, представил основные идеи, стоящие за идеей agile на производстве и в разработке программного обеспечения. Один момент, который показался мне особенно интересным, заключался в его комментарии о том, что необратимость была одним из первичных факторов, приводившим к сложности. Он рассматривал agile методы в промышленности и в индустрии разработки ПО как сдвиг парадигмы в поисках способа борьбы с необратимостью, в противовес попыткам избавиться от других предпосылок, приводящих к запутанности. Я считаю, что одна из главных задач архитектора – избавляться от архитектуры, находя способы предотвращения необратимости в дизайне ПО.
И снова вернемся к Джонсону, в этот раз привожу ответ на мое письмо:
Одно из различий между строительной архитектурой и архитектурой программного обеспечения заключается в том, что многие строительные решения очень трудно изменить. Сложно, хотя все еще возможно, вернуться в начало и изменить подвал.
Никаких теоретически обоснованных причин считать что-либо трудно изменяемым в программном обеспечении нет. Если Вы выберите любой отдельный аспект ПО – его легко изменить, но сложность в том, что мы не знаем, как сделать легко исправляемым сразу все вместе. Попытки сделать что-либо легко изменяемым немного усложняют всю систему, попытки сделать все изменяемым приводят к тому, что вся система становится очень сложной. Запутанность – вот, что усложняет изменение программного обеспечения. Это и дупликация.
Суть моего замечания по поводу Аспектно-ориентированного программирования состоит в том, что мы уже имеем достаточно хорошие способы выделения аспектов программ, имеем, но не используем. Не думаю, что реальная проблема будет решена за счет лучших техник выделения аспектов. Мы не знаем, которые аспекты нужно выделять, не знаем, когда они стоят отдельного рассмотрения, а когда нет.
Программное обеспечение не ограничено физическими законами мира как те же здания. Оно ограничено фантазией, дизайном, организацией. Если коротко – оно ограничено человеческими свойствами, не характеристиками мира. «Мы встретили врага, и он оказался нами».
Мартин Фаулер, ведущий научный сотрудник в ThoughtWorks
