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

О важности консоме

Эбен Хьюит

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

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

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

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

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

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

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

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

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

Винаяк Хеджд

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

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

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