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

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

Нечеткие количественные критерии должны задаваться в виде диапазона: минимум, норма, максимум. Если задать такой интервал невозможно, значит, непонятно, какое поведение требуется от системы. В ходе работы над архитектурой можно проверять систему на соответствие этим критериям, чтобы узнать, находится ли она (все еще) в пределах допустимых отклонений. Отклонения в степени соответствия некоторым критериям, происходящие с течением времени, дают полезную обратную связь. Определение этих интервалов и проверка системы на соответствие — дело трудоемкое и дорогостоящее. Если никто не беспокоится о производительности системы (ни о самой характеристике, ни о смысле термина) настолько, чтобы платить за тестирование производительности, скорее всего, этот показатель вообще не является существенным. Сосредоточьтесь при создании архитектуры на тех аспектах системы, которые стоят потраченных усилий.

«Система должна реагировать на входные данные пользователя не более чем за 1500 мс. При стандартной нагрузке (определяемой как…) среднее время отклика должно лежать в интервале от 750 до 1250 мс. Время отклика менее 500 мс не воспринимается пользователями, поэтому его падение ниже этого порога оплачиваться не будет.» А вот это уже можно назвать требованием.

Кейту Брайтуэйту (Keith Braithwaite) впервые заплатили за разработку программного обеспечения в 1996 году, хотя до этого он много лет занимался программированием на любительском уровне. После первого проекта — сопровождения компилятора, написанного с использованием lex и уасс, — он занялся сначала моделированием распространения микроволн для планирования сетей GSM, а затем расчетом на C++ сезонных колебаний спроса на воздушные перевозки. Перейдя на должность консультанта (и одновременно на язык Java), он познакомился с CORBA и EJB, а потом и с тем, что тогда называлось «электронной коммерцией». В настоящее время Кейт работает ведущим консультантом в фирме Zuhlke, где возглавляет Центр гибкой разработки.

Одна строка рабочего кода стоит 500 строк спецификации Эллисон Рэндал

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

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