Помоги проекту - поделись книгой:
Нил Форд, Майкл Хайгард, Билл де Ора и др
97 этюдов для архитекторов программных систем
Опыт ведущих экспертов
Предисловие
Архитекторы программного обеспечения занимают особое место в мире информационных технологий. От архитектора ожидают одинаково глубокого понимания как технологий и программных платформ, используемых в его организации, так и вопросов бизнеса, которому они служат. Хороший архитектор ПО должен в совершенстве знать обе стороны архитектуры — и коммерческую, и технологическую. Эта задача не из простых — вот почему и была написана эта книга.
Перед вами сборник советов от архитекторов ПО со всего света. Их советы затрагивают широкий круг тем — от предотвращения распространенных ошибок до создания выдающихся проектных команд. В сущности, это «сборная солянка» из рекомендаций признанных архитекторов ПО для других архитекторов и тех, кто хочет стать архитектором.
Искренне надеюсь, что эта книга явится источником вдохновения и руководством к действию для многих людей, профессионально занимающихся разработкой программного обеспечения. Хочется надеяться также, что архитекторы программного обеспечения будут использовать эту книгу (а также родственный ей веб-сайт) для обмена рекомендациями и находками в своей профессиональной сфере — возможно, самой сложной на сегодняшний день в области информационных технологий.
Книга «97 этюдов для архитекторов программных систем» очень сильно отличается от всех прочих книг, которые вам доводилось читать. Она была создана совместными усилиями более чем полусотни авторов; все они щедро делились своими мыслями и советами в области проектирования архитектуры программного обеспечения без денежного вознаграждения. Можно сказать, что эта книга следует принципам продуктов с открытым исходным кодом в их истинном смысле. Каждый автор внес свой вклад, написав одну или несколько статей, которые затем были тщательно проработаны и отрецензированы. Лучшие статьи были отобраны для публикации. В этом отношении книга похожа на программный проект с открытым исходным кодом, только здесь вклад участников — не программный код, а знания и мудрость.
Использование всех материалов этой книги также осуществляется на условиях, сходных с условиями распространения ПО с открытым исходным кодом. Каждая статья находится в свободном доступе на условиях лицензии Creative Commons, Attribution 3; это означает, что вы можете использовать отдельные статьи в своей работе, если упоминаете их авторов. Попытки публикации книг в соответствии с принципами распространения продуктов с открытым исходным кодом совершались и прежде, но все они (за немногочисленными исключениями) окончились неудачей. Вероятно, это объясняется трудностями координации вкладов отдельных участников, если проект не имеет четкого модульного разделения. Именно модульность обеспечила успех этой книги. Каждая статья существует независимо от других статей и ценна как в контексте сборника в целом, так и сама по себе.
Пожалуйста, со всеми комментариями и вопросами, касающимися этой книги, обращайтесь к издателю:
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938 (США или Канада)
707-829-0515 (международные или местные звонки)
707 829-0104 (факс)
На сайте издательства имеется веб-страница книги со списком обнаруженных опечаток и другой дополнительной информацией. Страница доступна по адресу:
Сопроводительный сайт книги, на котором размещены все тексты и полные биографии авторов, доступен по адресу:
С комментариями и техническими вопросами по поводу книги обращайтесь по электронной почте:
Дополнительную информацию о книгах, конференциях, ресурсах и O’Reilly Network вы можете найти на сайте издательства O’Reilly:
Логотип Safari® Enabled на обложке вашей любимой книги, посвященной какой-либо технологии, означает, что книга доступна через O’Reilly Network Safari Bookshelf.
Система Safari превосходит обычные электронные книги. Это целая виртуальная библиотека, позволяющая выполнять поиск по тысячам лучших технических книг, копировать примеры кода, загружать главы и быстро находить ответы, когда вам потребуется самая точная и актуальная информация. Safari можно бесплатно опробовать на сайте
Идея книги «97 этюдов для архитекторов программных систем» родилась не на пустом месте. Множество людей заслуживают благодарности за идею этой книги и ее исполнение. Я хочу поблагодарить Джея Циммермана (Jay Zimmerman), предложившего мне провести презентацию «10 вещей, которые должен знать каждый архитектор программного обеспечения» на симпозиуме «No Fluff, Just Stuff»; Брюса Эккеля (Bruce Eckel) за ведение списка рассылки, на базе которого зародилась идея этой книги; Джереми Мейера (Jeremy Meyer) за предложение написать книгу по материалам простой слайдовой презентации; Нитина Борванкара (Nitin Borwankar), предложившего создать общедоступный вики-сайт, чтобы все желающие могли принять участие; участников списка рассылки Брюса, которые, не имея ничего, кроме моих обещаний, приняли решение уделить время этой идее и предложили первые статьи для книги. Хочу поблагодарить также десятки архитекторов программного обеспечения, приложивших серьезные усилия к работе над материалами, которые в результате не вошли в эту книгу. Мне было очень трудно решить, какие статьи должны стать частью книги. Я глубоко благодарен всем, кто внес свой вклад в общую работу, независимо от того, попали их материалы в книгу или нет.
Я благодарен также издательству O’Reilly, которое без предубеждения восприняло идею и поддержало этот никем прежде не опробованный метод работы над книгой. O’Reilly заслуживает благодарности и за согласие лицензировать весь материал на условиях продуктов с открытым исходным кодом (лицензия Creative Commons, Attribution 3) и предоставить свободный доступ к содержимому на веб-сайте. Среди сотрудников O’Reilly мне хотелось бы особо поблагодарить Майка Лукидеса (Mike Loukides), Майка Хендриксона (Mike Hendrickson), Лору Пейнтер (Laura Painter) и Лорел Экерман (Laurel Ackerman). Без их помощи и поддержки этот проект был бы невозможен.
В настоящее время мы (O’Reilly и я) работаем над другими проектами новой уникальной серии «97 Things», которая позволяет воспользоваться коллективным разумом экспертов в различных практических областях. Управление проектами, разработка программного обеспечения, архитектура данных — вот лишь некоторые из тем, над которыми мы сейчас трудимся.
Надеюсь, книга покажется вам интересной, а возможно, даже вдохновит вас на подготовку собственных статей для будущих проектов!
Не ставьте свое резюме выше интересов клиента
Мы, технари, подчас выбираем для использования те или иные технологии, методологии и подходы к решению задач не потому, что они обеспечивают оптимальное решение, а лишь потому, что в глубине души нам хочется упомянуть их в своем резюме. Такой выбор очень редко приводит к положительному результату.
Самым мощным катализатором вашей карьеры будут благодарные заказчики, выстроившиеся в длинную очередь, чтобы порекомендовать вас другим — ведь вы так хорошо для них потрудились. Благосклонность клиентов послужит вам на порядок лучше, чем любой новомодный объект новомодного языка и любая свежеизобретенная парадигма. Хотя для архитектора очень важно (и даже жизненно необходимо) быть в курсе новейших тенденций и технологий, никогда не пытайтесь расширять свой кругозор за счет клиента. Помните, что вам как архитектору доверено благополучие вашей организации; соответственно от вас ожидают, что вы будете честно и грамотно действовать в интересах заказчика, избегая любых конфликтов интересов и сохраняя полную лояльность своей организации. Если предложенный проект недостаточно актуален или перспективен для ваших текущих карьерных целей, найдите другой проект.
А что, если это невозможно, и вы все же вынуждены участвовать в таком проекте? И вам самому, и всем остальным будет лучше, если вы будете выбирать технологию в интересах клиента, а не своего резюме. Подчас трудно устоять перед искушением применить новое модное решение, даже если оно плохо подходит к текущей ситуации.
При правильно выбранном решении вы получаете довольную команду и удовлетворенного клиента, а общая напряженность работы над проектом заметно снижается. Часто это позволяет вам глубже изучить уже знакомую технологию или заняться освоением новинки в свободное время. А может быть, у вас даже высвободится время для посещения курсов живописи, о которых вы всегда мечтали. Ваши близкие это тоже оценят — они заметят разницу в вашем состоянии, когда вы приходите домой после работы.
Всегда ставьте долгосрочные потребности клиента над своими собственными краткосрочными потребностями, — и вы не ошибетесь.
Снижайте неотъемлемую сложность, устраняйте второстепенную сложность
Неотъемлемая сложность
С другой стороны,
«Синдром второстепенной сложности» проявляется во многих инфраструктурах (framework) и фирменных «решениях». Инфраструктуры для решения узких, конкретных задач приносят реальную пользу; чрезмерно сложные инфраструктуры создают больше трудностей, чем устраняют.
Сложные решения привлекают разработчиков, как пламя привлекает мотыльков, причем часто с тем же результатом. Решать сложные задачи интересно, а работа программиста по сути состоит из сплошного разгадывания головоломок. Кто не испытывал азарта при решении какой-нибудь невероятно сложной задачи? Однако в крупномасштабных проектах бывает очень трудно избежать второстепенной сложности, сосредоточившись на работе со сложностью неотъемлемой.
Как этого добиться? Отдавайте предпочтение инфраструктурам, созданным на базе работающего кода, а не в башнях из слоновой кости. Соотносите объем кода, направленного на решение непосредственной задачи, с объемом кода, который просто обслуживает взаимодействие пользователя с приложением. С осторожностью относитесь к решениям, продвигаемым фирмами-разработчиками: такие решения не всегда изначально плохи, но в них часто присутствует второстепенная сложность. Проверяйте соответствие решения поставленной задаче.
Обязанность архитектора — решать проблемы, лежащие в плоскости неотъемлемой сложности, без введения второстепенной сложности.
Возможно, ваша главная проблема не в технологиях
Прямо сейчас где-то терпит бедствие очередной проект системы расчета зарплаты… А скорее всего, и не один.
Почему это случилось? Потому что разработчики выбрали Ruby вместо Java или Python вместо Smalltalk? Потому что решили использовать Postgres, а не Oracle? Или потому что предпочли платформу Windows, хотя следовало выбрать Linux? Как известно, во всех неудачах проектов обычно винят технологию. Но действительно ли ваша задача была настолько сложна, что возможностей Java оказалось для нее недостаточно?
Проекты обычно создаются людьми, и именно от этих людей зависит успех или провал всего проекта. А раз так, стоит немного подумать, как помочь им добиться успеха.
Возможно, в команде есть кто-то, кто, с вашей точки зрения, не справляется со своей работой и тем самым препятствует успеху проекта. Технология, применяемая для решения подобных проблем, очень стара и проверена временем; в сущности, это едва ли не самое важное техническое достижение в истории человечества. То, что вам нужно, называется
При этом простого владения приемами общения как технологией недостаточно. Уважительное отношение к людям, умение предоставлять им кредит доверия — важнейшие навыки, превращающие умного руководителя в эффективного.
Конечно, дело этим отнюдь не исчерпывается, но несколько простых советов существенно повысят эффективность вашего общения с подчиненными:
• Смотрите на обсуждение проблем как на конструктивный диалог, а не как на конфликтную ситуацию.
Исходите из позитивных предположений о людях и рассматривайте общение как возможность задать интересующие вас вопросы; так вы определенно сможете получить больше полезной информации, а ваши собеседники не займут оборонительную позицию.
• Приступайте к беседе только в подходящем для общения настроении.
Если вы рассержены, раздражены, расстроены и вообще выведены из душевного равновесия, ваш собеседник, скорее всего, истолкует ваши невербальные проявления как признак нападения.
• Используйте такие ситуации как возможность достичь взаимной выгоды. Не говорите разработчику, чтобы он вел себя потише на собраниях, поскольку не дает никому говорить; лучше спросите, не поможет ли он вам вовлечь в обсуждение других людей. Объясните, что интровертам необходима более длинная пауза для вступления в разговор, и если он выдержит паузу в пять секунд перед произнесением первых слов, то тем самым очень поможет вам.
Если вы сосредоточены на общей цели, рассматриваете «проблемы» своих собеседников как возможность чему-то научиться, управляете своими эмоциями, то вы не только повысите свою эффективность, но и будете каждый раз узнавать что-то новое.
Общение — король, ясность и лидерство — его верные слуги
Слишком часто архитекторы программного обеспечения обитают в башнях из слоновой кости, спуская оттуда разработчикам спецификации и навязывая им технологии и направления. Сплошь и рядом это приводит к раздорам, за которыми быстро следует «народное восстание». В итоге появляется программный продукт, который не имеет ничего общего с исходными требованиями. Каждый архитектор программного обеспечения должен уметь объяснять своим коллегам цели и задачи программного проекта. Ключами к эффективному общению являются ясность и лидерство.
Большинству архитекторов программного обеспечения не приходит в голову, что они должны быть еще и
Действуйте совместно с разработчиками, а не против них. Учитывайте, что ясность и лидерство важны для взаимодействия со всеми участниками команды (не только с разработчиками, но и с группой тестирования, бизнес-аналитиками и руководителями проектов). Ясность в передаче информации и эффективное проявление лидерства улучшают качество коммуникации, формируют сильную и здоровую рабочую среду.
Если «общение — король», то ясность и лидерство — его верные слуги.
Производительность приложения определяется его архитектурой
Производительность приложения определяется его архитектурой. На первый взгляд кажется, что это утверждение должно быть очевидным, но опыт реальной работы показывает обратное. Например, архитекторы программного обеспечения нередко полагают, что проблемы с производительностью приложения можно решить простым переходом на программную инфраструктуру от другого производителя. Источником этой веры может быть рекламная шумиха вокруг результатов тестирования — например, заявляется, что продукт фирмы-лидера на 25 % превосходит по производительности ближайшего конкурента. Однако если продукт-лидер выполняет операцию за 3 миллисекунды, а конкурирующий продукт — за 4 миллисекунды, заявленные 25 % (одна миллисекунда) значат очень мало на фоне общей низкой производительности, уходящей корнями в неэффективность архитектуры.
Помимо ИТ-менеджеров и команд тестирования производительности есть и другие группы людей, например служба поддержки фирмы-разработчика и авторы книг по управлению производительностью приложений, которые рекомендуют заняться тонкой настройкой инфраструктуры приложения: поиграть с операциями выделения памяти, размерами пулов подключений, размерами пулов потоков и так далее. Но если приложение спроектировано недостаточно эффективно для ожидаемой нагрузки или его функциональная архитектура нерационально использует вычислительные ресурсы, то никакая тонкая настройка не обеспечит желаемого быстродействия и масштабируемости. Потребуется полное перепроектирование внутренней логики и/или стратегии развертывания.
В конечном счете за фасадом продукта любого производителя и архитектуры любого приложения действуют одни и те же фундаментальные принципы распределенной обработки данных и физические закономерности: приложения и используемые ими продукты выполняются как процессы на компьютерах ограниченной мощности, взаимодействуя друг с другом через стеки протоколов и каналы связи с ненулевыми задержками. А значит, людям следует понять и принять мысль о том, что архитектура приложения является главным фактором, определяющим его производительность и масштабируемость. Эти качественные характеристики невозможно улучшить как по волшебству — чудодейственной сменой технологий или тонкой настройкой инфраструктуры. Любые усовершенствования в этих областях требуют упорного труда по тщательной проработке архитектуры.
Ищите истинный смысл требований
Заказчики и конечные пользователи часто под видом требования выдвигают то, что им кажется эффективным решением некоторой задачи. Классический пример такого рода приводит Гарри Хиллейкер (Harry Hillaker), ведущий конструктор истребителя F-16 Falcon. Перед его группой была поставлена цель спроектировать самолет, развивающий скорость М2-2,5, что было (и вероятно, остается) весьма нетривиальной задачей, особенно если сопутствующая цель состоит в создании «дешевого» легкого самолета. Учтите, что сила, необходимая для преодоления сопротивления воздуха, при удвоении скорости полета возрастает вчетверо, и представьте себе, как это обстоятельство влияет на вес самолета.
Когда конструкторская группа спросила заказчиков из ВВС, зачем им нужна скорость М2-2,5, те ответили: «Чтобы самолет мог при необходимости выйти из боя». Когда настоящая потребность стала очевидной, конструкторы смогли решить главную проблему и представить работоспособное решение: подвижный самолет с высокой тяговооруженностью, обеспечивающей хорошее ускорение и маневренность вместо высокой максимальной скорости.
Выводы из этого урока в равной степени справедливы и в области разработки программного обеспечения. Узнав у заказчика истинный смысл запрашиваемой возможности или требования, архитектор сможет проникнуть в суть проблемы и, если повезет, предложить решение более качественное и экономичное по сравнению с тем, на котором настаивает клиент. Повышенное внимание к сути требований упрощает и расстановку приоритетов: самые значимые для заказчика требования становятся определяющими.
Как же следует действовать? В манифесте гибкой (agile) разработки есть принцип, который ко многим случаям подходит очень хорошо: «Сотрудничество важнее контракта». С практической точки зрения это подразумевает проведение семинаров и встреч, на которых архитекторы анализируют потребности заказчика, помогая ему ответить на вопрос «Почему?». Учтите, что поиск ответа на этот вопрос может оказаться весьма непростой задачей, потому что в процессе анализа требований речь зачастую идет о неявных допущениях и подразумеваемых знаниях. На таких встречах следует избегать дискуссий по поводу технических решений, потому что они переводят обсуждение из предметной области заказчика в область программирования.
Встаньте!
Для многих из нас карьера архитектора начиналась с какой-либо чисто технической должности, где успех определялся в основном способностью общаться с компьютерами. Однако в роли архитектора нам приходится общаться главным образом с другими людьми. Обсуждаете ли вы с разработчиками преимущества того или иного шаблона или объясняете руководству плюсы и минусы покупки промежуточного программного обеспечения, залогом успеха являются ваши навыки общения.
Объективно измерить степень влияния архитектора на проект довольно сложно, но одно совершенно ясно: если разработчики постоянно игнорируют указания архитектора, а руководство не придает значения его рекомендациям, «правильность» действий архитектора никак не повлияет на развитие его карьеры. Опытные архитекторы понимают, что они должны «продвигать» свои идеи, а эта задача требует умения эффективно общаться.
На тему межличностного общения написано множество книг, но я хотел бы предложить вашему вниманию один простой и практичный прием, который радикально повысит эффективность вашего общения и соответственно упрочит ваш успех в роли архитектора. В какой бы ситуации вам ни приходилось объяснять свою позицию сразу нескольким слушателям, встаньте. Неважно, где вы при этом находитесь — на официальном анализе проекта системы или неформальном обсуждении пары диаграмм. Встаньте — особенно если все остальные сидят.
Когда вы встаете, окружающие автоматически начинают воспринимать вас как авторитетного и уверенного в себе человека. Вы становитесь центром внимания. Вас будут реже перебивать. Все это окажет существенное влияние на обсуждение независимо от того, будут приняты ваши рекомендации или нет.
Поделиться книгой: