Архитектура программного обеспечения с человеческим лицом

Автор: Цыбульник Виталий Александрович
Источник: RSDN Magazine #2-2010
Опубликовано: 16.01.2011
Версия текста: 1.2
Введение
Архитектура часто строится эволюционно
Шаблоны проектирования и лучшие практики всегда используются субъективно
Архитекторы программного обеспечения – живые люди
Заключение
Список литературы

Введение

На протяжении последних двух десятков лет "человеческие" аспекты разработки программного обеспечения стали центральной темой среди исследователей и практикующих профессионалов. Оказалось, что разработка программного обеспечения намного точнее поддаётся пониманию и контролю, если её рассматривать как социальную активность, а не как инженерную дисциплину [1]. Частично это происходит потому, что "software is soft" [2], т.е. "программное обеспечение гибко". Существующие инженерные практики не работают так хорошо для непостоянных требований и стремительно изменяющихся условий разработки. Но ещё более важным является тот факт, что программное обеспечение есть продукт чистой человеческой мысли, что само по себе возводит "человеческий фактор" в разряд ключевых аспектов дальнейшего исследования, понимания и улучшения процесса разработки программного обеспечения.

Результатом такой "человеко-центристской" эры в разработке ПО стало то, что некоторые важные этапы процесса разработки были пересмотрены и признаны не только инженерным, но и социальным предметом. Среди них и построение архитектуры программного обеспечения. "Архитектура ПО" - невероятно перегруженный и неоднозначный термин. Существует несколько формальных определений, таких как "архитектура – это высший уровень концепции системы в её контексте" или "архитектура – это набор инженерных решений, которые необходимо принять на ранних стадиях проекта", но исследователи и практики часто не соглашаются с такими определениями [3], так что, пожалуй, всё ещё не существует лучшего определения, чем ироничное, данное Ральфом Джонсоном: "Архитектура – это важные вещи, чем бы они ни были". Поскольку "важность" есть понятие очень субъективное, то присутствует огромная роль человеческого фактора в самом определении понятия архитектуры. Но даже если считать, что архитектура – это набор инженерных решений (таких, как использование шаблонов проектирования, объектной модели и т.п.), то и в этих решениях присутствует значительная доля человеческих факторов, поэтому в этой статье автор хотел бы обратить внимание, попытаться подытожить и пропустить через призму собственного опыта основные человеческие аспекты архитектуры программного обеспечения.

Архитектура часто строится эволюционно

Архитектура программного обеспечения как дисциплина впервые появилась в 1970-ых и унаследовала очень многое от гражданской архитектуры. Методы, применяемые в архитектуре ПО, были довольно формальными, а весь концепт архитектуры предполагал "предварительную" разработку. Однако когда плановая стадия проектирования стала включаться во всё более и более широкий круг проектов, выяснилось, что строгая и тщательно продуманная архитектура, разработанная до начала написания кода, не всегда работает хорошо в проектах по разработке программного обеспечения. Это ознаменовало начало "гибкой" (agile) эры в разработке ПО. Идея гибкой эволюционной архитектуры хорошо продемонстрирована Мартином Фаулером (Martin Fowler) в его работе [3]. Фаулер предложил начинать построение архитектуры с наиболее простого из возможных для данных требований решения (т.н. "принцип YAGNI"), а затем "растить" архитектуру по мере развития проекта и изменения требований, используя технику рефакторинга для совершения безопасных поэтапных изменений. Даже для архитектуры базы данных, традиционно относимых к наиболее "фундаментальным" частям архитектуры приложений, Фаулер успешно использует рефакторинг и другие гибкие методики для её эволюционного развития [5].

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

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

Шаблоны проектирования и лучшие практики всегда используются субъективно

Шаблоны проектирования (design patterns) на самом деле не являются такими уж конкретными, особенно в отношении вопроса, где и когда их использовать. Алистар Коуберн (Alistair Cockburn) а своей блестящей статье [4] продемонстрировал, что даже на использование хорошо известных шаблонов проектирования существенно влияют социальные факторы, личные предпочтения и предвзятость проектировщика. Архитектурные решения - это всегда компромиссы между различными интересами, внешними силами, принципами и ответными силами, так что этот баланс уникален для каждого проектировщика и проектной среды. Коуберн представил 15 соответствующих шаблонов, которые показывают влияние социальных аспектов на архитектурные решения. В итоге в его статье выявлению социального фундамента архитектурных решений придаётся намного больше значения, чем инженерной базе этих решений.

Если же вернуться к эволюционной природе архитектуры, то влияние нетехнических факторов оказывается ещё более сильным. Автор в своей практике использовал три "стиля" применения шаблонов проектирования:

  1. Статическое, полное использование шаблонов, когда разработка архитектуры происходит перед началом работы над кодом. Использование шаблона реализуется от начала и до конца при кодировании соответствующей функциональности. Инвестируется больше времени и ресурсов на ранней стадии с тем, чтобы получить большую экономию при сопровождении и доработке.
  2. Эволюционное использование шаблонов направлено на более равномерное распределение ресурсов по стадиям проектов. Уменьшаются инвестиции в начале проекта, быстрее получаются первые результаты в виде функциональности, однако требуются разовые инвестиции на внедрение шаблона при переходе на сопровождение/доработку. При таком подходе на ранних стадиях проекта функциональность реализуется полностью или частично без использования шаблона, создаются тесты. На этапе же исправления ошибок, доработки функциональности или совершенствования системы (как правило, перед началом разработки новой функциональности или усовершенствования старой) с помощью рефакторинга код преобразуется к нужному шаблону проектирования. 
  3. Неиспользование шаблонов в некоторых случаях оказывается оправданным. Например, при работа над старым кодом, в случае крайне ограниченных ресурсов/сроков в сочетании с невысокими требованиями к качеству/сопровождаемости продукта.

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

Архитекторы программного обеспечения – живые люди

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

Мартин Фаулер выделяет архитектурные роли [6]:

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

"Architectus Oryzus" - человек, осведомлённый обо всём, что происходит в проекте, следящий за всеми трудностями и помогающий их устранить до того, как они превратятся в серьёзные проблемы, программирующий вместе с разработчиками, работающий над требованиями, помогающий предвидеть и объяснять технические последствия нетехнических идей и требований, и т.п.

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

Люк Хохман (Luke Hohmann) разделяет архитекторов на "технитекторов" ("tarchitect", технический архитектор) и "маркетекторов" ("marchitect", маркетинговый архитектор) согласно технической или бизнес-перспективе системной архитектуры [7]. Однако такие склонности в работе архитектора могут быть также объяснены индивидуальной сферой интересов разных людей, выполняющих задачу проектирования программного продукта.

Попросту говоря, "архитектор" – это не просто роль в процессе разработки ПО, в реальной жизни это очень конкретный человек с очень конкретным набором человеческих качеств, таких как знания, умения, опыт и коммуникационные способности. Более того, архитектор почти никогда не работает в одиночку, он работает в команде, так что суммарные умения команды, предпочтения, и особенно коммуникации внутри команды играют основополагающую роль для успешного проектирования архитектуры. Опыт работы автора в небольших динамичных проектах и командах говорит о том, что вероятность успеха такого проекта выше, если архитектор может объяснить разработчикам важные проектные решения с помощью листка бумаги с квадратиками, чем если архитектор создаёт идеальные UML диаграммы, на разработку, понимание командой и внедрение которых тратится на порядок больше сил и времени.

Заключение

Проектирование архитектуры в проектах по разработке программного обеспечения имеет первоочередное значение как для технического, так и маркетингового успеха проекта, поэтому анализ факторов, влияющих на архитектурные решения в проекте заслуживает пристального внимания. В статье автор подытожил и дополнил из собственного опыта утверждение о том, что характеристики людей имеют первоочередное значение для процесса разработки ПО в целом [8] и проектирования архитектуры в частности. К основным человеческим аспектам отнесено эволюционное построение архитектуры, социальные особенности применения шаблонов проектирования и существенное влияние индивидуальных человеческих качеств на выполнение функций архитектора. Человеческая интуиция и реакция на быстро изменяющиеся условия динамичных проектов, коммуникации, личные предпочтения и уникальное сочетание умений и опыта – все эти человеческие факторы влияют на общую картину проекта и ключевые архитектурные решения намного больше, чем все остальные инженерные факторы, такие как знание шаблонов проектирования, подходящая объектная структура, детальные UML-диаграммы и т.п. Инженерные техники – это всего лишь хорошие инструменты, используемые живыми людьми со всеми вытекающими из этого последствиями. Выводы статьи могут быть использованы в первую очередь руководителями проектов по разработке ПО для найма и оценки работы архитекторов, а также для более точного планирования и управления процессом проектирования программных продуктов. Некоторые наблюдения и заключения также могут быть полезны самим архитекторам для лучшего понимания их роли в проекте и факторов, влияющих на её успешное выполнение.

Список литературы

  1. Alistair Cockburn: “The end of software engineering and the start of economic-cooperative gaming”, Humans and Technology Technical Report, January 2004
  2. Martin Fowler: “Keeping Software Soft”, Distributed Computing, December 1998
  3. Martin Fowler: “Is Design Dead?”, XP 2000, July 2000
  4. Alistair Cockburn: “The Interaction of Social Issues and Software Architecture”, COMMUNICATIONS OF THE ACM , Vol. 39, No. 10, October 1996
  5. Martin Fowler, Pramod Sadalage “Evolutionary Database Design”, martinfowler.com, January 2003
  6. Martin Fowler: “Who Needs an Architect?”, IEEE Software, July/August 2003
  7. Luke Hohmann: “The Difference between Marketecture and Tarchitecture”, IEEE Software, July/August 2003
  8. Alistair Cockburn: “Characterizing people as non-linear, first-order components in software development”, Humans and Technology, October 1999


Эта статья опубликована в журнале RSDN Magazine #2-2010. Информацию о журнале можно найти здесь