97 этюдов для архитекторов программных систем
Шрифт:
Выбор технологии, используемой для решения задачи, — важная часть работы архитектора программного обеспечения. Тщательно выбирайте свое оружие и не спешите его менять. Дайте вашим прежним успехам лечь в основу будущих достижений и расширяйте свой арсенал технологий постепенно и разумно.
Биография автора приведена ранее.
Ваш клиент — не ваш клиент
Эбен Хьюит
Принимая участие во встречах по сбору требований в ходе проектирования программных продуктов,
Ваш клиент — не ваш клиент. Вашим клиентом является клиент вашего клиента. Если выигрывает клиент вашего клиента, то выигрывает и ваш клиент. А это означает, что выигрываете вы.
Если вы пишете приложение электронной коммерции, позаботьтесь о том, что потребуется посетителям, которые будут совершать покупки на вашем сайте. Им потребуется безопасная передача данных. Им потребуется шифрование хранимых данных. Ваш клиент, возможно, даже не упомянет об этих требованиях. Если вы знаете, что ваш клиент упустил что-то, что нужно его клиентам, займитесь этой проблемой и объясните ему, почему вы это сделали.
Если ваш клиент намеренно и осознанно игнорирует важные аспекты, нужные его клиенту (а это время от времени случается), возможно, от проекта стоит отказаться. Если ваш клиент не желает ежегодно платить за SSL и предпочитает хранить данные кредитных карт в текстовом виде, потому что это удешевит разработку системы, будет ошибкой просто согласиться. Соглашаясь работать над реализацией заведомо плохих требований, вы уничтожаете клиентов своего клиента.
Встречи по сбору требований — это не диспуты о реализации. Не позволяйте своему клиенту углубляться в вопросы реализации, если только речь не идет об абсолютно необходимых или хорошо понятных задачах. Пусть ваш клиент опишет свой идеал, свою концепцию и цели, вместо того чтобы диктовать решение (и вообще использовать технические термины).
Как обеспечить такую дисциплину на встречах с клиентом? На самом деле эта задача только выглядит сложной. Помните, что вы должны заботиться о клиенте своего клиента. Хотя чек выписывает ваш клиент, вы должны четко дать ему понять, что будете следовать лучшим рекомендациям и можете сделать то, что действительно необходимо клиенту, а не то, что он считает таковым. Конечно, это повлечет за собой длительные споры и потребует умения четко формулировать, что именно вы делаете и почему.
Как и многое в жизни, сказанное лучше всего иллюстрируется стихами. В 1649 году Ричард Лавлейс написал стихотворение «Лукасте по поводу ухода на войну». Оно заканчивается строками: «Ведь если бы я предал честь, я предал бы тебя».
Мы предаем наших клиентов, когда игнорируем интересы их клиентов.
Биография автора приведена ранее.
Все будет не так, как задумано
Питер Гиллард-Мосс
Все будет не так, как задумано. Очень легко попасть в ловушку и преисполниться уверенности в том, что реализация будет полностью соответствовать вашим планам, после того как вы потратили массу времени на проектирование. Детальное проектирование создает иллюзию, что вы предусмотрели все до мельчайших подробностей. Чем подробнее детали, чем глубже ваши исследования, тем больше вы доверяете своему дизайну. Но это впечатление обманчиво: все получится не так, как задумано.
Реальность такова, что, как бы глубоко вы ни прорабатывали дизайн, как бы тщательно ни обдумывали детали, результат все равно будет отличаться от того, каким вы его себе представляли. Что-нибудь непременно произойдет — и в дизайн вмешается какой-либо внешний фактор: неверная информация, ограничение, странное поведение чужого кода… А может быть, вы где-то ошибетесь: упущение, неверное предположение, какой-то пропущенный нюанс… Или что-нибудь изменится — требования, технология, — или кто-то найдет лучшее решение.
Мелкие изменения в дизайне накапливаются,
А затем повторяется та же история. Снова там и сям появляются изменения, подрывающие ваш замысел; разработчики накладывают все новые заплатки, пытаясь хоть как-то удержать расползающийся по швам дизайн, но в конечном итоге только разваливают его окончательно. И вы восклицаете: «Конечно же, ошибки будут — ведь система для этого не предназначалась!» Проектирование — это исследовательский процесс; в ходе реализации обнаруживается новая информация, которую часто бывает невозможно предсказать заранее. Принимая как факт, что проектирование — это эмпирический процесс в постоянно изменяющемся мире, мы понимаем, что процесс проектирования должен быть гибким и непрерывным. Если вы упорно цепляетесь за исходный дизайн и пытаетесь втиснуть действительность в его рамки, итог предопределен. Вам следует осознать, что все всегда получается не так, как задумано.
Питер Гиллард-Мосс (Peter Gillard-Moss) — сотрудник ThoughtWorks и мемеолог широкого профиля из США. Работает в сфере информационных технологии с 2000 года; участвовал во многих проектах, от общедоступных медиасайтов и электронной коммерции до банковских приложений и корпоративных интрасетей.
Выбирайте инфраструктуры, хорошо сочетающиеся с другими
Эрик Готорн
При выборе программных инфраструктур, которые будут положены в основу вашей системы, необходимо учитывать не только качество и возможности каждой инфраструктуры (framework), но и то, как они будут взаимодействовать друг с другом и насколько легко будет адаптировать их к новым программным элементам, которые вам, возможно, придется добавить в ходе эволюции системы. Из этого следует, что выбранные инфраструктуры должны быть неперекрывающимися, простыми, компактными и специализированными.
Лучше всего, если каждая инфраструктура или сторонняя библиотека будет относиться к отдельной логической области и решать обособленную задачу, не вторгаясь в область других задействованных инфраструктур.
Обязательно изучите перекрытия логических областей и функциональности инфраструктур-кандидатов. Если понадобится, нарисуйте диаграмму Венна. Две модели данных, существенно перекрывающиеся в предметной области, или две реализации, решающие очень похожие задачи немного различающимися способами, порождают излишнюю сложность: придется находить соответствия между концептуальными различиями или представлениями либо приделывать заплатки из неуклюжего связующего кода. В итоге вы, скорее всего, получите не только громоздкий связующий код, но и сведете функциональные и репрезентативные возможности системы к наименьшему общему знаменателю двух инфраструктур.
Чтобы снизить вероятность функционального перекрытия, выбирайте инфраструктуры с высоким отношением полезной нагрузки к балласту в контексте требований вашей системы. Полезная нагрузка — это функциональность или возможности представления данных, необходимые вашему проекту, а балласт — то, насколько инфраструктура стремится охватить все что можно и решить все задачи на свете. Требует ли инфраструктура смешивать управление данными и их представление? Как сильно ее модель данных или набор пакетов/классов выходят за пределы того, что необходимо вашей системе? Придется ли вам присягнуть ей на верность и впредь ограничить выбор инфраструктур теми, что соответствуют ее рамкам? Ограничивает ли ее избыточная сложность возможности взаимодействия? Если уж инфраструктура отягощена большим количеством балласта, она должна обеспечивать хотя бы 75 % необходимой функциональности проекта.