97 этюдов для архитекторов программных систем
Шрифт:
…умеют ими пользоваться
Умение повторно использовать элементы зависит от навыков и квалификации. Конечно, существуют люди, способные (по выражению Дональда Кнута (Donald Knuth)) «попадать в резонанс» с программированием и проектированием. Все мы работали с такими людьми — одаренными разработчиками и архитекторами, которые обладают впечатляющей (и даже пугающей) скоростью и глубиной усвоения информации. Но такие люди встречаются редко. Остальные члены команды, вероятно, просто хорошие, надежные, разумные разработчики и проектировщики. Их необходимо учить.
Может оказаться, что разработчики и проектировщики не знают тот конкретный шаблон,
…считают, что это лучше, чем сделать заново самим
Многие люди — и особенно разработчики — предпочитают решать проблемы самостоятельно, вместо того чтобы обращаться за помощью. Спрашивать о том, как что-то работает, кажется им признаком слабости или даже проявлением невежества. Во многом это зависит от уровня зрелости и склада личности отдельных членов команды — для разных людей слова «лучше, чем сделать заново» означают разные вещи. «Молодые стрелки» всегда предпочитают писать нужный код самостоятельно, потому что это тешит их самолюбие. Более опытные участники чаще готовы принять тот факт, что кто-то другой уже размышлял над такой задачей и способен предложить что-то для ее решения.
Если ваша команда не знает, где искать элементы для повторного использования, или не умеет работать с ними, то, естественно, она самостоятельно создаст их заново. А платить по счетам придется вам.
Джереми Мейер (Jeremy Meyer) занимается проектированием и разработкой программного обеспечения, а также преподаванием в течение почти 20 лет. В настоящее время он является ведущим консультантом Borland Software в области моделирования и проектирования.
«Я» в архитектуре не существует
Дэйв Куик
На самом деле «я» в архитектуре, конечно, существует. Но это не заглавное «Я», привлекающее к себе внимание и доминирующее во всех обсуждениях. Строчной буквы вполне достаточно.
Как это относится к нам — архитекторам программных продуктов? Наше эго подчас оказывается нашим самым опасным врагом. Кто из нас не встречал архитекторов, которые:
• считают, что они понимают требования лучше заказчиков,
• рассматривают разработчиков как ресурс, нанятый для реализации их идей,
• в штыки воспринимают любые сомнения в своих идеях или игнорируют идеи других?
Подозреваю, что любой опытный архитектор когда-нибудь допускал хотя бы одну из этих ошибок. Я допускал их все и извлек болезненные уроки из своих неудач.
Почему это происходит?
Мы уже добивались успеха. Успех и опыт развивают уверенность в себе и позволяют нам стать настоящими архитекторами. Успех ведет к более крупным проектам. Однако грань между уверенностью в себе и самонадеянностью весьма тонка. В какой-то момент проект выходит за рамки наших возможностей. Самонадеянность начинает проявляться тогда, когда мы пересекаем эту черту, но не хотим это признать.
Люди нас уважают. Решение
Все мы люди. Архитектор вкладывает в каждую архитектуру частицу самого себя. Критика ваших творений воспринимается как нападки лично на вас. Поддаться искушению и занять оборонительную позицию легко; научиться не делать это сложно. Гордиться своими достижениями легко; научиться без специальных усилий чувствовать пределы своих возможностей сложно.
Как этого избежать?
Требования не лгут. При наличии корректных, полных требований хороша будет любая архитектура, которая им удовлетворяет. Тесно взаимодействуйте с заказчиком, чтобы и он, и вы правильно понимали смысл каждого требования для бизнеса. Архитектуру формируете не вы, а требования. Вы всего лишь должны приложить максимум усилий, чтобы обеспечить их выполнение.
Сосредоточьтесь на своей команде. Члены команды — это не просто ресурс; это ваши помощники по проектированию и ваша «страховочная сетка». Из людей, которые чувствуют себя недооцененными, обычно получается плохая «подстраховка». Архитектура формируется командой, а не лично вами. Вы даете указания, но трудную работу выполняют все вместе. Их помощь нужна вам в не меньшей степени, чем им — ваша.
Проверяйте свою работу. Модель — не архитектура, а всего лишь ваше понимание того, как должна работать архитектура. Работайте вместе с командой над созданием тестов, показывающих, как архитектура проекта поддерживает каждое из требований.
Наблюдайте за собой. Большинству из нас приходится побеждать в себе природную склонность защищать свою работу, заботиться только о собственных эгоистических интересах и считать себя самым умным человеком в комнате. Под давлением эти склонности всплывают на поверхность. Уделяйте ежедневно несколько минут размышлениям о том, как происходило ваше взаимодействие с окружающими. Отнеслись ли вы к идеям всех своих собеседников с должным уважением и признательностью? Не было ли с вашей стороны отрицательной реакции на ценные предложения? Действительно ли вы понимаете, почему кто-то не согласился с вашим подходом?
Исключение «Я» из архитектуры не гарантирует успеха. Оно всего лишь устраняет распространенный источник ошибок, происходящих только по вашей вине.
Биография автора приведена ранее.
Посмотрите с высоты 300 метров
Эрик Дорненбург
Нам, архитекторам, хочется знать, насколько хороша та программа, над которой мы работаем. Качество программы имеет очевидный внешний аспект — программа должна представлять ценность для пользователей, — но у него есть и более тонкий внутренний аспект, относящийся к ясности дизайна, — к тому, насколько легко нам понимать, сопровождать и расширять программный продукт. Если от нас настойчиво требуют определения качества, обычно мы в конце концов говорим: «Я узнаю это, когда увижу». Но как можно увидеть качество?