97 этюдов для архитекторов программных систем

Форд Нил

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

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

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

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

Винаяк Хеджд (Vinayak Hegde) — технофил, интересующийся компьютерами, фотографией и предпринимательством. В настоящее время, работает архитектором в компании Akamai Technologies.

Лучшие программы не строят — их выращивают

Билл де Ора

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

Самым верным предвестником провала программного продукта является его размер. Если задуматься, нет никакого смысла начинать с проектирования крупномасштабной системы. Тем не менее в какой-то момент у каждого из нас возникает соблазн действовать именно так. Помимо неизбежной побочной сложности и инерции, проектирование системы крупного размера с самого начала увеличивает

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

Как этого добиться? Лучший метод снабдить программную систему способностью развиваться и адаптироваться — заставить ее развиваться и адаптироваться с самого начала. Вы начинаете с небольшой работоспособной системы, рабочего подмножества предполагаемой архитектуры — простейшей конфигурации, какая только может работать. Такой зародыш системы обладает многими полезными свойствами и может рассказать вам о заложенной архитектуре столько, сколько никогда не расскажет большая система (и тем более подборка документов с описанием архитектуры). Вы с большей вероятностью будете участвовать в его реализации. Миниатюрность упрощает тестирование и снижает уровень связанности. Для создания такого зародыша потребуется группа меньшего размера, что сократит затраты на координацию проекта. За его свойствами будет проще наблюдать. Его будет проще развертывать. По нему вы и ваша группа сможете как можно раньше понять, какие решения работают, а какие нет. Он покажет вам, в каких местах развитие системы затруднено, где она наверняка кристаллизуется и станет хрупкой. Где она может сломаться. И, что самое важное, вы сможете с самого начала предъявить нечто понятное и осязаемое заинтересованным сторонам проекта, помогая им как можно раньше вникнуть в общий дизайн системы.

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

Биография автора приведена ранее.