Сообщений 30 
Оценка 125 
Оценить 
| Сообщений 30 Оценка 125 Оценить
|
|
Введение
Архитектура часто строится эволюционно Шаблоны проектирования и лучшие практики всегда используются субъективно Архитекторы программного обеспечения – живые люди Заключение Список литературы |  |
На протяжении последних двух десятков лет "человеческие" аспекты разработки программного обеспечения стали центральной темой среди исследователей и практикующих профессионалов. Оказалось, что разработка программного обеспечения намного точнее поддаётся пониманию и контролю, если её рассматривать как социальную активность, а не как инженерную дисциплину [1]. Частично это происходит потому, что "software is soft" [2], т.е. "программное обеспечение гибко". Существующие инженерные практики не работают так хорошо для непостоянных требований и стремительно изменяющихся условий разработки. Но ещё более важным является тот факт, что программное обеспечение есть продукт чистой человеческой мысли, что само по себе возводит "человеческий фактор" в разряд ключевых аспектов дальнейшего исследования, понимания и улучшения процесса разработки программного обеспечения.
Результатом такой "человеко-центристской" эры в разработке ПО стало то, что некоторые важные этапы процесса разработки были пересмотрены и признаны не только инженерным, но и социальным предметом. Среди них и построение архитектуры программного обеспечения. "Архитектура ПО" - невероятно перегруженный и неоднозначный термин. Существует несколько формальных определений, таких как "архитектура – это высший уровень концепции системы в её контексте" или "архитектура – это набор инженерных решений, которые необходимо принять на ранних стадиях проекта", но исследователи и практики часто не соглашаются с такими определениями [3], так что, пожалуй, всё ещё не существует лучшего определения, чем ироничное, данное Ральфом Джонсоном: "Архитектура – это важные вещи, чем бы они ни были". Поскольку "важность" есть понятие очень субъективное, то присутствует огромная роль человеческого фактора в самом определении понятия архитектуры. Но даже если считать, что архитектура – это набор инженерных решений (таких, как использование шаблонов проектирования, объектной модели и т.п.), то и в этих решениях присутствует значительная доля человеческих факторов, поэтому в этой статье автор хотел бы обратить внимание, попытаться подытожить и пропустить через призму собственного опыта основные человеческие аспекты архитектуры программного обеспечения.
Архитектура программного обеспечения как дисциплина впервые появилась в 1970-ых и унаследовала очень многое от гражданской архитектуры. Методы, применяемые в архитектуре ПО, были довольно формальными, а весь концепт архитектуры предполагал "предварительную" разработку. Однако когда плановая стадия проектирования стала включаться во всё более и более широкий круг проектов, выяснилось, что строгая и тщательно продуманная архитектура, разработанная до начала написания кода, не всегда работает хорошо в проектах по разработке программного обеспечения. Это ознаменовало начало "гибкой" (agile) эры в разработке ПО. Идея гибкой эволюционной архитектуры хорошо продемонстрирована Мартином Фаулером (Martin Fowler) в его работе [3]. Фаулер предложил начинать построение архитектуры с наиболее простого из возможных для данных требований решения (т.н. "принцип YAGNI"), а затем "растить" архитектуру по мере развития проекта и изменения требований, используя технику рефакторинга для совершения безопасных поэтапных изменений. Даже для архитектуры базы данных, традиционно относимых к наиболее "фундаментальным" частям архитектуры приложений, Фаулер успешно использует рефакторинг и другие гибкие методики для её эволюционного развития [5].
Эволюционная природа архитектуры – это очень важный тезис с точки зрения её человеческих аспектов. Он означает, что на самом деле архитектура не является статичным концептом, построенным на основе академических методик, а призвана быть динамичным, субъективным, нелинейным процессом с большим количеством неизвестных параметров. Т.е. на данном этапе архитектура некоторых классов приложений всё ещё ближе к ручной работе или даже искусству, чем промышленному инженерному процессу.
Более 5 лет своей профессиональной карьеры автор занимался построением и развитием архитектуры малых и средних проектов, большей частью стартапов. Из опыта этой работы замечено, что отлично спланированная и построенная заранее архитектура почти никогда не помогает успеху такого проекта. Малые проекты и стартапы почти никогда не располагают достаточными ресурсами и очень редко имеют устоявшиеся требования к системе, так что тщательно построенная на ранних стадиях архитектура может привести к существенному перерасходу времени и ресурсов или быстро устареть по причине существенно изменяющихся требований. Только человеческая интуиция и эволюционный подход позволяют техническому лидеру или архитектору найти шаткий баланс между всеми этими противоречивыми факторами и привести подобные проекты к успеху.
Шаблоны проектирования (design patterns) на самом деле не являются такими уж конкретными, особенно в отношении вопроса, где и когда их использовать. Алистар Коуберн (Alistair Cockburn) а своей блестящей статье [4] продемонстрировал, что даже на использование хорошо известных шаблонов проектирования существенно влияют социальные факторы, личные предпочтения и предвзятость проектировщика. Архитектурные решения - это всегда компромиссы между различными интересами, внешними силами, принципами и ответными силами, так что этот баланс уникален для каждого проектировщика и проектной среды. Коуберн представил 15 соответствующих шаблонов, которые показывают влияние социальных аспектов на архитектурные решения. В итоге в его статье выявлению социального фундамента архитектурных решений придаётся намного больше значения, чем инженерной базе этих решений.
Если же вернуться к эволюционной природе архитектуры, то влияние нетехнических факторов оказывается ещё более сильным. Автор в своей практике использовал три "стиля" применения шаблонов проектирования:
Выбор подходящего стиля использования шаблонов делается на основании политики, ресурсов и требований, и выбор этот часто делается архитектором на основании неполных данных о будущем проекта, что делает его очень человеко-зависимым.
Существует также значительная неясность в определении роли архитектора в проектах по разработке ПО. Некоторые руководители испытывают большие трудности с наймом на позицию "архитектор", поскольку они и сами до конца не понимают обязанностей архитектора. Однако, как только правильный человек появляется в команде, ни у кого уже не возникает сомнений в его соответствии роли архитектора, даже если отсутствует точное представление о значении этой роли.
Мартин Фаулер выделяет архитектурные роли [6]:
"Architectus Reloadus" - человек, принимающий все важные решения в проекте и делающий это потому, что "единый разум необходим для обеспечения концептуальной целостности системы", а также, вероятно, и потому, что "архитектор не верит в достаточно высокий для принятия таких решений уровень членов своей команды".
"Architectus Oryzus" - человек, осведомлённый обо всём, что происходит в проекте, следящий за всеми трудностями и помогающий их устранить до того, как они превратятся в серьёзные проблемы, программирующий вместе с разработчиками, работающий над требованиями, помогающий предвидеть и объяснять технические последствия нетехнических идей и требований, и т.п.
Однако наличие этих двух типов архитекторов автор скорее объяснил бы просто наличием двух разных типов людей, по-разному играющих одну и ту же роль архитектора в силу различного характера и набора умений.
Люк Хохман (Luke Hohmann) разделяет архитекторов на "технитекторов" ("tarchitect", технический архитектор) и "маркетекторов" ("marchitect", маркетинговый архитектор) согласно технической или бизнес-перспективе системной архитектуры [7]. Однако такие склонности в работе архитектора могут быть также объяснены индивидуальной сферой интересов разных людей, выполняющих задачу проектирования программного продукта.
Попросту говоря, "архитектор" – это не просто роль в процессе разработки ПО, в реальной жизни это очень конкретный человек с очень конкретным набором человеческих качеств, таких как знания, умения, опыт и коммуникационные способности. Более того, архитектор почти никогда не работает в одиночку, он работает в команде, так что суммарные умения команды, предпочтения, и особенно коммуникации внутри команды играют основополагающую роль для успешного проектирования архитектуры. Опыт работы автора в небольших динамичных проектах и командах говорит о том, что вероятность успеха такого проекта выше, если архитектор может объяснить разработчикам важные проектные решения с помощью листка бумаги с квадратиками, чем если архитектор создаёт идеальные UML диаграммы, на разработку, понимание командой и внедрение которых тратится на порядок больше сил и времени.
Проектирование архитектуры в проектах по разработке программного обеспечения имеет первоочередное значение как для технического, так и маркетингового успеха проекта, поэтому анализ факторов, влияющих на архитектурные решения в проекте заслуживает пристального внимания. В статье автор подытожил и дополнил из собственного опыта утверждение о том, что характеристики людей имеют первоочередное значение для процесса разработки ПО в целом [8] и проектирования архитектуры в частности. К основным человеческим аспектам отнесено эволюционное построение архитектуры, социальные особенности применения шаблонов проектирования и существенное влияние индивидуальных человеческих качеств на выполнение функций архитектора. Человеческая интуиция и реакция на быстро изменяющиеся условия динамичных проектов, коммуникации, личные предпочтения и уникальное сочетание умений и опыта – все эти человеческие факторы влияют на общую картину проекта и ключевые архитектурные решения намного больше, чем все остальные инженерные факторы, такие как знание шаблонов проектирования, подходящая объектная структура, детальные UML-диаграммы и т.п. Инженерные техники – это всего лишь хорошие инструменты, используемые живыми людьми со всеми вытекающими из этого последствиями. Выводы статьи могут быть использованы в первую очередь руководителями проектов по разработке ПО для найма и оценки работы архитекторов, а также для более точного планирования и управления процессом проектирования программных продуктов. Некоторые наблюдения и заключения также могут быть полезны самим архитекторам для лучшего понимания их роли в проекте и факторов, влияющих на её успешное выполнение.
| Сообщений 30 Оценка 125 Оценить
|