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

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

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

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

Ричард Монсон-Хейфел (Richard Monson-Haefel) — независимый разработчик ПО, соавтор всех пяти изданий «Enterprise JavaBeans» и обоих изданий «Java Message Service» (все книги опубликованы, издательством O’Reilly). Занимается проектированием и разработкой multitouch-интерфейсов, является ведущим специалистом в области корпоративной обработки данных.

Проблема пользовательского признания Норман Карновейл

Люди не всегда рады появлению новых систем или крупным обновлениям. Это может поставить под угрозу успешное завершение проекта.

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

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

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

• Люди боятся новых (непроверенных) технологий.

• Люди стараются избежать дополнительных затрат.

• Люди просто не любят изменения.

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

К числу других эффективных мер относится обучение, запланированные демонстрации системы (на ранних стадиях жизненного цикла проекта) и распространение информации о том, какую пользу принесет новая система.

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

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

О важности консоме Эбен Хьюит

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

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

Архитектор программного обеспечения должен постоянно избавлять мысли от примесей, многократно фильтровать свои идеи, пока не будет выявлена сущность каждого требования к системе. Словно Гамлет, держащий череп Йорика, мы спрашиваем себя: что представляет собой данная возможность? Каковы ее свойства? Ее связи? Мы проясняем свои концепции, чтобы отношения в архитектуре поддавались проверке и были внутренне согласованными.

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

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

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

В какой момент работу над архитектурой можно считать завершенной? Когда она станет абсолютно прозрачной и вы сможете прочитать дату на монетке.

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

Для пользователя интерфейс — это и есть система Винаяк Хеджд

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