Мелкие изменения в дизайне накапливаются, и вскоре выясняется, что необходимо внести одно большое изменение. И вот ваша исходная концепция разбивается вдребезги, и вам приходится снова браться за карандаш и бумагу. Вы решаете, что проблема требует более тщательного, более подробного проектирования, усердно трудитесь и добиваетесь более четкого, более глубокого и более совершенного видения.
А затем повторяется та же история. Снова там и сям появляются изменения, подрывающие ваш замысел; разработчики накладывают все новые заплатки, пытаясь хоть как-то удержать расползающийся по швам дизайн, но в конечном итоге только разваливают его окончательно. И вы восклицаете: «Конечно же, ошибки будут ведь система для этого не предназначалась!» Проектирование это исследовательский процесс; в ходе реализации обнаруживается новая информация, которую часто бывает невозможно предсказать заранее. Принимая как факт, что проектирование это эмпирический процесс в постоянно изменяющемся мире, мы понимаем, что процесс проектирования должен быть гибким и непрерывным. Если вы упорно цепляетесь за исходный дизайн и пытаетесь втиснуть действительность в его рамки, итог предопределен. Вам следует осознать, что все всегда получается не так, как задумано.
Питер Гиллард-Мосс (Peter Gillard-Moss) сотрудник ThoughtWorks и мемеолог широкого профиля из США. Работает в сфере информационных технологии с 2000 года; участвовал во многих проектах, от общедоступных медиасайтов и электронной коммерции до банковских приложений и корпоративных интрасетей.
Выбирайте инфраструктуры, хорошо сочетающиеся с другими Эрик Готорн
Лучше всего, если каждая инфраструктура или сторонняя библиотека будет относиться к отдельной логической области и решать обособленную задачу, не вторгаясь в область других задействованных инфраструктур.
Обязательно изучите перекрытия логических областей и функциональности инфраструктур-кандидатов. Если понадобится, нарисуйте диаграмму Венна. Две модели данных, существенно перекрывающиеся в предметной области, или две реализации, решающие очень похожие задачи немного различающимися способами, порождают излишнюю сложность: придется находить соответствия между концептуальными различиями или представлениями либо приделывать заплатки из неуклюжего связующего кода. В итоге вы, скорее всего, получите не только громоздкий связующий код, но и сведете функциональные и репрезентативные возможности системы к наименьшему общему знаменателю двух инфраструктур.
Чтобы снизить вероятность функционального перекрытия, выбирайте инфраструктуры с высоким отношением полезной нагрузки к балласту в контексте требований вашей системы. Полезная
нагрузка это функциональность или возможности представления данных, необходимые вашему проекту, а балласт то, насколько инфраструктура стремится охватить все что можно и решить все задачи на свете. Требует ли инфраструктура смешивать управление данными и их представление? Как сильно ее модель данных или набор пакетов/классов выходят за пределы того, что необходимо вашей системе? Придется ли вам присягнуть ей на верность и впредь ограничить выбор инфраструктур теми, что соответствуют ее рамкам? Ограничивает ли ее избыточная сложность возможности взаимодействия? Если уж инфраструктура отягощена большим количеством балласта, она должна обеспечивать хотя бы 75 % необходимой функциональности проекта.
Система должна состоять из неперекрывающихся инфраструктур блистательных в своей области, но при этом простых, компактных и гибких.
Эрик Готорн (Eric Hawthorne) профессионально занимается созданием архитектуры, проектированием и разработкой объектно-ориентированных программ и распределенных систем с 1998 года. Первые 10 лет его карьеры прошли в Macdonald Dettwiler канадской системотехнической компании, где среди прочего он имел возможность поучиться архитектурным тонкостям у самого Филиппа Крачтена (Philippe Kruchten).
Подготовьте убедительное экономическое обоснование И Чжоу
Психология массового сознания говорит также, что большинство людей считает воспринимаемое реальностью. А значит, если вы сможете управлять тем, как люди воспринимают предложенный вами подход к решению тех или иных архитектурных вопросов, вы практически гарантированно сможете управлять и их реакцией на ваше предложение. Как управлять восприятием заинтересованных сторон? Подготовьте для своей архитектуры надежное экономическое обоснование. Люди, которые финансируют ваши идеи, почти всегда руководствуются деловыми соображениями.
На протяжении своей карьеры я неоднократно применял следующий процесс из пяти шагов для успешного продвижения своих архитектурных решений:
1. Сформулируйте ценностное предложение. Составьте пояснительную записку относительно того, почему деловые интересы вашей организации требуют применения определенной программной архитектуры. Для этого необходимо сравнить предлагаемые вами архитектурные решения с имеющимися решениями или возможными альтернативами. Основное внимание следует уделить возможности повышения производительности и эффективности бизнеса, а не замечательным свойствам технологий.