Архитектура и скорая разработка: брак, развод или дружба?

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

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

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

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

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

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

Значение архитектуры для скорой разработки

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

Архитектура — это то, что придает вам скорость. Как бы строго вы ни придерживались agile-методов, архитектура, мешающая вносить необходимые изменения по той причине, что она плохо разработана или не отвечает поставленным задачам, будет тормозить любой качественный процесс. Такая архитектура будет играть против команды разработчиков и потока требований, а не в поддержку реализации системы с углублением понимания ее назначения.

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

Что архитектуре нужно от процесса

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

Напомним, что архитектура выражает знания. Разработка ПО — это умственный труд, подразумевающий обучение технологиям; выяснение желаний заказчика; обучение общению с теми, кто формирует требования к продукту; обучение самой разработке системы, от методов до инженерных решений; обучение совместной работе и т. д. Короче, знания приходят вместе c обучением, а на него нужно время, и именно оно структурируется процессом.

В начале любого проекта разработки, как целого продукта так и очередной версии, лежит точка наименьших знаний — максимального невежества. Учитывая это, безответственно принимать все важные решения заранее. С другой стороны, в конце проекта знаний максимум, но возможностей для их использования уже меньше всего. Иначе говоря, архитектуре от процесса нужно пространство и время для обучения, поэтому нельзя заранее составить полный план и объявить его окончательным: разработка архитектуры должна идти эмпирическим путем, и каждое архитектурное решение нужно рассматривать как требующую проверки гипотезу, которая станет основанием для следующего решения.

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

***

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

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

Фрэнк Бушманн (buschmann@siemens.com) — главный архитектор департамента системной архитектуры и платформы Siemens Corporate Technology; Кевлин Хенни (kevlin@cubralan.com) — независимый консультант по программной архитектуре, процессам разработки, методам и практике программирования.