Кто нуждается в архитекторе?

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

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

Что такое архитектура?

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

Мой первый шаг был направлен на то, чтобы избежать нечеткости, просто позволив своему цинизму проявиться. В некотором смысле, я определяю архитектуру как слово, которое мы используем, когда хотим говорить о дизайне, но хотим приукрасить его, чтобы оно звучало важнее. (Да, вы можете представить себе похожее явление для архитектора.) Однако, как часто бывает, внутри этого цинизма скрыта щепотка правды. Понимание пришло ко мне после чтения поста от Ральфа Джонсона в списке рассылки Extreme Programming. Он был настолько хорош, что я процитирую его полностью.

В предыдущем посте говорилось:

RUP, работая по определению IEEE, определяет архитектуру как «наивысший уровень концепции системы в ее окружении. Архитектура программной системы (на данный момент времени) — это ее организация или структура значимых компонентов, взаимодействующих через интерфейсы, причем эти компоненты состоят из последовательно меньших компонентов и интерфейсов».

Джонсон ответил:

Я был рецензентом на стандарте IEEE, который использовал это определение, и я бесполезно спорил, что это явно полностью ложное определение. Нет никакой наивысшей концепции системы. У клиентов есть одна концепция, у разработчиков — другая. Клиенты совсем не заботятся о структуре значимых компонентов. Итак, возможно, архитектура — это наивысшая концепция, которую разработчики имеют о системе в ее окружении. Давайте забудем о разработчиках, которые понимают только свою небольшую часть. Архитектура — это наивысшая концепция экспертных разработчиков. Что делает компонент значимым? Он значим, потому что так считают экспертные разработчики.

Итак, лучшее определение было бы: «В большинстве успешных проектов программного обеспечения экспертные разработчики, работающие над этим проектом, имеют общее понимание дизайна системы. Это общее понимание называется "архитектурой". Это понимание включает в себя, как система разделена на компоненты и как эти компоненты взаимодействуют через интерфейсы. Эти компоненты обычно состоят из меньших компонентов, но архитектура включает только те компоненты и интерфейсы, которые понятны всем разработчикам».

Это было бы лучшее определение, потому что оно ясно показывает, что архитектура — это социальный конструкт (впрочем, программное обеспечение тоже, но архитектура даже более), потому что она зависит не только от программного обеспечения, но и от того, какая часть программного обеспечения считается важной по групповому консенсусу.

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

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

Является ли что-то частью архитектуры, зависит только от того, считают ли разработчики это важным. Люди, строящие «корпоративные приложения», склонны считать, что устойчивость имеет решающее значение. Когда они начинают рисовать свою архитектуру, они начинают с трех слоев. Они упоминают «и мы используем Oracle для нашей базы данных и имеем свой собственный слой устойчивости для сопоставления объектов с ней». Но в медицинском приложении для обработки изображений Oracle может использоваться без того, чтобы считаться частью архитектуры. Это потому, что большинство сложностей заключается в анализе изображений, а не в их хранении. Извлечение и хранение изображений осуществляется одной небольшой частью приложения, и большинство разработчиков это игнорируют.

Так что это затрудняет объяснение людям, как описывать свою архитектуру. «Расскажите нам, что важно». Архитектура — это о важных вещах. Что бы это ни было.

Роль архитектора

Итак, если архитектура — это важные вещи, то архитектор — это человек (или люди), который беспокоится о важных вещах. И здесь мы подходим к сути различия между видом архитектора из «Матрица: Перезагрузка» и стилем, который олицетворяет Дэйв Райс.

Architectus Reloadus — это человек, который принимает все важные решения. Архитектор делает это, потому что для обеспечения концептуальной целостности системы требуется один ум, и, возможно, потому что архитектор считает, что члены команды недостаточно квалифицированы, чтобы принимать эти решения. Часто такие решения должны приниматься в начале, чтобы у всех остальных был план для следования.

Architectus Oryzus — это другое животное (если вы не догадались, попробуйте www.nd.edu/~archives/latgramm.htm). Этот тип архитектора должен быть очень осведомлен о том, что происходит в проекте, следить за важными вопросами и решать их до того, как они станут серьезной проблемой. Когда я вижу такого архитектора, самая заметная часть работы — это интенсивное сотрудничество. Утром архитектор программирует с разработчиком, пытаясь собрать общий код блокировки. Во второй половине дня архитектор участвует в сеансе требований, помогая объяснить людям, занимающимся требованиями, технические последствия некоторых их идей на нетехническом языке — таких, как затраты на разработку.

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

На недавнем ретрите ThoughtWorks некоторые мои коллеги и я обсуждали вопрос архитекторов. Мне было интересно, что мы быстро договорились о сути работы, следуя Architectus Oryzus, но нам было трудно найти подходящее название. Architectus Reloadus слишком распространен, чтобы мы чувствовали себя комфортно с «архитектором», и это основано на ошибочной метафоре (см. http://martinfowler.com/bliki/BuildingArchitect.html). Майк Ту предложил лучшее название, которое я слышал: гид, как в альпинизме. Гид — это более опытный и умелый член команды, который обучает других членов команды лучше справляться самим, но всегда присутствует для действительно сложных задач.

Избавление от архитектуры программного обеспечения

Я люблю писать шокирующие заголовки, и лучшие, как этот, имеют важное значение, которое не сразу очевидно. Вспомните второе определение Джонсона: «Архитектура — это решения, которые вы хотели бы принять правильно в начале проекта». Почему люди чувствуют необходимость правильно принимать некоторые вещи в начале проекта? Ответ, конечно же, в том, что они считают эти вещи трудными для изменения. Так что вы можете в конечном итоге определить архитектуру как «вещи, которые люди считают трудными для изменения».

Считается, что если вы строите корпоративное приложение, вы должны правильно настроить схему базы данных на раннем этапе, потому что трудно изменить схему базы данных, особенно после того, как вы запустили систему. На одном из наших проектов администратор базы данных, Промод Садалаге, разработал систему, которая позволила нам легко изменять схему базы данных (и мигрировать данные) (см. http://martinfowler.com/articles/evodb.html).

Что делает компонент значимым?

Он значим, потому что так считают экспертные разработчики.

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

На увлекательной лекции на конференции XP 2002 (http://martinfowler.com/articles/xp2002.html) Энрико Занинотто, экономист, проанализировал основополагающие идеи, стоящие за гибкими методами в производстве и разработке программного обеспечения. Один аспект, который я нашел особенно интересным, был его комментарий, что необратимость была одним из основных факторов сложности. Он видел гибкие методы в производстве и разработке программного обеспечения как сдвиг, направленный на снижение необратимости, в отличие от борьбы с другими факторами сложности. Я думаю, что одной из самых важных задач архитектора является устранение архитектуры путем нахождения способов устранения необратимости в дизайне программного обеспечения.

Вот снова Джонсон, на этот раз в ответ на мое электронное письмо:

«Одним из отличий архитектуры зданий от архитектуры программного обеспечения является то, что многие решения о здании трудно изменить. Трудно вернуться и изменить ваш подвал, хотя это возможно.

Нет теоретической причины, по которой что-то в программном обеспечении трудно изменить. Если вы выберете любой аспект программного обеспечения, вы можете сделать его легким для изменения, но мы не знаем, как сделать все легким для изменения. Делая что-то легким для изменения, мы делаем всю систему немного более сложной, а делая все легким для изменения, мы делаем всю систему очень сложной. Сложность — это то, что делает программное обеспечение трудным для изменения. Это, и дублирование.

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

Программное обеспечение не ограничено физикой, как здания. Оно ограничено воображением, дизайном, организацией. Короче говоря, оно ограничено свойствами людей, а не свойствами мира. «Мы встретили врага, и это мы сами».

Мартин Фаулер является главным научным сотрудником компании ThoughtWorks, занимающейся интернет-доставкой систем и консалтингом. Свяжитесь с ним по адресу [email protected].