что система должна быть «масштабируемой», спросите его, откуда возьмутся новые пользователи и почему. Спросите, сколько их будет и когда это произойдет. Не удовлетворяйтесь ответами «много» и «скоро».
Нечеткие количественные критерии должны задаваться в виде диапазона: минимум, норма, максимум. Если задать такой интервал невозможно, значит, непонятно, какое поведение требуется от системы. В ходе работы над архитектурой можно проверять систему на соответствие этим критериям, чтобы узнать, находится ли она (все еще) в пределах допустимых отклонений. Отклонения в степени соответствия некоторым критериям, происходящие с течением времени, дают полезную обратную связь. Определение этих интервалов и проверка системы на соответствие — дело трудоемкое и дорогостоящее. Если никто не беспокоится о производительности системы (ни о самой характеристике, ни о смысле термина) настолько, чтобы платить за тестирование производительности, скорее всего, этот показатель вообще не является существенным. Сосредоточьтесь при создании архитектуры на тех аспектах системы, которые стоят потраченных усилий.
«Система должна реагировать на входные данные пользователя не более чем за 1500 мс. При стандартной нагрузке (определяемой как…) среднее время отклика должно лежать в интервале от 750 до 1250 мс. Время отклика менее 500 мс не воспринимается пользователями, поэтому его падение ниже этого порога оплачиваться не будет.» А вот это уже можно назвать требованием.
Кейту Брайтуэйту (Keith Braithwaite) впервые заплатили за разработку программного обеспечения в 1996 году, хотя до этого он много лет занимался программированием на любительском уровне. После первого проекта — сопровождения компилятора, написанного с использованием lex и уасс, — он занялся сначала моделированием распространения микроволн для планирования сетей GSM, а затем расчетом на C++ сезонных колебаний спроса на воздушные перевозки. Перейдя на должность консультанта (и одновременно на язык Java), он познакомился с CORBA и EJB, а потом и с тем, что тогда называлось «электронной коммерцией». В настоящее время Кейт работает ведущим консультантом в фирме Zuhlke, где возглавляет Центр гибкой разработки.
Одна строка рабочего кода стоит 500 строк спецификации
Эллисон Рэндал
Проектирование — красивая штука. Систематическое, детальное представление пространства задачи и ее решения обнажает ошибки и выявляет возможности для совершенствования, причем иногда весьма радикальным образом. Спецификации играют в этом важную роль, поскольку они определяют шаблон для построения системы. Очень важно неспешно продумать всю архитектуру — как на макроуровне, рассматривая взаимодействие между компонентами, так и на микроуровне, вникая в поведение самих компонентов.
К сожалению, архитекторы часто увлекаются процессом проектирования, попадая под очарование архитектурных абстракций. Однако сами по себе спецификации не обладают никакой ценностью. Конечной целью программного проекта является реально работающая система. Архитектор всегда должен держать в поле зрения эту цель и помнить, что проектирование — всего лишь средство, а не конечный результат. Архитектор небоскреба, пренебрегающий законами физики ради изящества здания, обречен вскоре пожалеть об этом. Стоит упустить из вида конечную цель — рабочий код, — и у проекта начинаются серьезные неприятности.
Уважайте коллег, работающих над реализацией вашего видения системы. Прислушивайтесь к ним. Если у них возникают проблемы с вашим дизайном, вполне возможно, что они правы, а дизайн ошибочен или, по крайней мере, невнятен. В таких случаях привести дизайн в соответствие практическим требованиям — ваша непосредственная задача, и решить ее вы можете, общаясь с членами вашей команды, которые помогут вам определить, что работает, а что нет. Ни один дизайн не бывает идеальным с самого начала; любой дизайн подвержен изменениям по мере реализации.
Если вы участвуете в проекте и в качестве разработчика, научитесь ценить время, потраченное на написание кода, и не верьте тем, кто говорит, что это лишь отнимает время от работы по созданию архитектуры. Вы обретете гораздо более точное видение проекта на макро- и микроуровнях, после того как сами попробуете вдохнуть жизнь в свое творение.
Эллисон Рэндал (Allison Randal) — главный архитектор и ведущий разработчик проекта с открытым исходным кодом Parrot. За свою 25-летнюю карьеру она разрабатывала буквально все — от игр до средств лингвистического анализа, сайтов электронной коммерции, систем контроля доставки, компиляторов и систем репликации баз данных. Ей довелось побывать проектировщиком языков программирования, руководителем проектов, организатором конференций, редактором и консультантом. Эллисон была президентом фонда ПО с открытым кодом, написала две книги и основала, издательство технической литературы.
Решений на все случаи жизни не существует
Рэнди Стаффорд
Архитектор должен непрерывно развивать и совершенствовать свое «контекстное чутье», поскольку единственного универсального решения для широкого круга разнородных проблем не существует.
Броское выражение «контекстное чутье» впервые использовал (с содержательным описанием его смысла) Эберхардт Рехтин (Eberhardt Rechtin) в своей книге «Systems Architecting: Creating & Building Complex Systems» (Системная архитектура: создание и построение сложных систем) (Prentice Hall, 1991):
«Чтобы узнать основные принципы „эвристического подхода“ к проектированию сложных систем, спросите опытного архитектора, что он делает, когда сталкивается с особенно сложной задачей. Его ответ, скорее всего, будет таким: „Просто использую здравый смысл“. <…> Вместо термина „здравый смысл“ лучше было бы использовать выражение „контекстное чутье“[7] — знание о том, что является разумным в данном контексте. Образование, полученный опыт и изучение примеров позволяют архитектору-практику набрать значительную мощь контекстного чутья к тому моменту, когда ему доверяется решение проблемы системного уровня, — обычно на это уходит лет десять.»
Одна из серьезных проблем в индустрии разработки ПО, как мне кажется, состоит в том, что решение задач часто поручается людям, не успевшим развить достаточное контекстное чутье. Возможно, это связано с тем, что отрасль насчитывает всего два поколения и сейчас переживает стадию взрывного роста; не исключено, что исчезновение этой проблемы можно будет считать признаком зрелости отрасли.
Я часто сталкиваюсь с проявлениями этой проблемы в своей работе консультанта. Вот характерные примеры: отказ от проектирования на основе предметной области (domain-driven design)[8] там, где оно было бы уместным; утрата прагматического взгляда на вещи и чрезмерное увлечение проектированием программного решения, когда речь идет о задаче, не терпящей отлагательств; необоснованные или не имеющие отношения к делу предложения в тот момент, когда работы по оптимизации быстродействия системы заходят в тупик.
Самое важное, что необходимо знать о программных шаблонах, — то, когда их следует и когда не следует применять. То же самое верно в отношении гипотез о глубинных причинах проблемы и соответствующих корректирующих действий. В обеих ситуациях — при создании архитектуры системы и при анализе проблемы — универсального решения «на все случаи жизни»
