97 этюдов для архитекторов программных систем
Шрифт:
Если смотреть на вещи реалистично, наша база фундаментальных (то есть абсолютных и теоретически истинных) знаний о разработке программ мала по сравнению с тем, что необходимо для успешного развития проекта. Чтобы компенсировать эту нехватку знаний, мы строим догадки, полагаемся на интуицию, а порой даже просто выбираем наудачу. Таким образом, в ходе любого крупного проекта по разработке программного обеспечения возникают эмпирические данные о том, что работает, а что нет. Мы шаг за шагом накапливаем опыт изменений, который хотим применять к отрасли в целом.
На индивидуальном уровне каждый из нас стремится повысить свою квалификацию и понять, как строить все более и более крупные системы. Задачи,
Процесс обсуждения всегда помогает выявить слабости обсуждаемого предмета. Нельзя сказать, что вы что-то понимаете, если вы не можете это «что-то» легко объяснить. Только когда мы излагаем свои объяснения и обсуждаем их с другими, наш опыт преобразуется в знания.
Кроме того, даже если мы получили некий опыт, сделанные из него выводы могут оказаться не совсем правильными в более широком контексте. Возможно, мы были не настолько успешны или не настолько умны, как нам хотелось бы. Конечно, проверять свои знания в реальных условиях страшно, особенно когда нечто ценное для нас оборачивается мифом, ошибкой или заблуждением; оказаться неправым всегда неприятно.
Все мы люди, поэтому то, что происходит в наших головах, не всегда правильно и не каждая возникающая у нас мысль разумна. Только когда мы осознаем свою неидеальность, перед нами открывается путь к совершенствованию. Старая поговорка «На ошибках учатся» по-прежнему верна. Если наши идеи и убеждения не выдерживают проверки обсуждением, об этом лучше узнать до того, как мы положим их в основу своих решений.
Делясь обретенными знаниями и опытом, мы способствуем движению нашей отрасли вперед; мы сознаем, что это также помогает нам лучше понимать происходящее и исправлять ошибки. С учетом того, в каком состоянии пребывает значительная часть наших программ, очень важно использовать любую возможность рассказать другим о том, что мы поняли, узнали или полагаем, что узнали. Если мы поможем тем, кто нас окружает, стать лучше, они помогут нам в полной мере раскрыть наш потенциал.
Пол У. Хомер (Paul W. Homer) — программист, писатель и фотограф-любитель. Занялся разработкой программного обеспечения несколько десятилетий назад и с тех пор неустанно работает над построением все более сложных систем.
Патология шаблонов
Чед Лавинь
Шаблоны проектирования — один из самых полезных инструментов в арсенале архитектора программного обеспечения. Использование шаблонов позволяет создавать типовые решения, которые проще понять и объяснить другим. Сама идея шаблонов напрямую ассоциируется с качественным проектированием. Из-за этого у нас часто возникает соблазн продемонстрировать свою искушенность, включив в проект большое количество шаблонов. Если вы поймали себя на том, что упорно втискиваете свои любимые шаблоны в пространство задачи, где они неуместны, то не исключено, что вы стали жертвой патологии шаблонов.
Многие проекты страдают от такого положения дел. Глядя на них, так и видишь, как архитектор проекта поднимает взгляд от последней страницы сборника шаблонов, потирает руки и произносит: «Так, с какого шаблона начнем?..». Этот образ действий отчасти сродни
Шаблоны — не панацея, а их использование не всегда служит признаком хорошего дизайна. Они представляют собой всего лишь повторно применимые решения типичных задач, найденные и описанные другими разработчиками, чтобы нам было легче узнать «уже изобретенный велосипед», если он попадется нам на глаза. Наша задача — выявить те проблемы, для которых создавались эти решения, и правильно применить подходящий шаблон проектирования. Не позволяйте своему желанию продемонстрировать мастерское владение шаблонами проектирования взять верх над прагматизмом. Направьте свои усилия на проектирование систем, обеспечивающих эффективное решение бизнес-задач, и используйте шаблоны для решения тех проблем, для которых они предназначены.
Чед Лавинь (Chad. LaVigne) — архитектор программных решений и внештатный технический специалист фирмы TEKSystems, Inc. (Балтимор). Работает в основном в Миннеаполисе, занимается проектированием и реализацией решений на базе технологий Enterprise Java.
Не увлекайтесь архитектурными метафорами
Дэвид Инг
Архитекторы обожают иметь дело с метафорами. Метафоры позволяют придать осязаемость абстрактным, сложным и ускользающим от понимания темам. При общении с другими членами команды или в процессе обсуждения архитектуры с конечным пользователем возникает неодолимый соблазн подобрать выразительную, хорошо знакомую по реальному миру метафору, которая описала бы то, что вы пытаетесь построить.
Обычно все начинается хорошо: собеседники находят общий язык, и кажется, что все идет в нужном направлении. Метафора развивается и растет до тех пор, пока не начинает жить собственной жизнью. Люди относятся к ней благосклонно — прогресс налицо!
А затем обычно наступает момент, когда архитектурная метафора вдруг становится опасной и восстает против своих создателей. Вот как это может происходить:
• Ваша метафора начинает нравиться заказчику больше, чем сама разрабатываемая система, то есть все заинтересованные стороны начинают верить в красивую иллюзию, созданную метафорой, не желая разбираться, что за ней на самом деле скрывается.
Пример: «Мы строим транспортную систему по принципу перемещения корабля между несколькими причалами».
Вы представляете себе контейнеровоз, бороздящий просторы Тихого океана, — я же имел в виду гребную лодку в бассейне, притом с одним веслом.
• Команда разработчиков начинает считать метафору более весомой по сравнению с реальной бизнес-задачей. А вы из любви к своей метафоре начинаете оправдывать странные решения.
Пример: «Мы сказали, что система будет похожа на картотечный шкаф, поэтому нам придется выводить данные в алфавитном порядке. Я знаю, что этот шкаф имеет шесть измерений, бесконечную длину и встроенные часы, но мы уже сделали иконку — а картотека должна вести себя как картотека…».