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