97 этюдов для архитекторов программных систем

Как же следует действовать? В манифесте гибкой (agile) разработки есть принцип, который ко многим случаям подходит очень хорошо: «Сотрудничество важнее контракта». С практической точки зрения это подразумевает проведение семинаров и встреч, на которых архитекторы анализируют потребности заказчика, помогая ему ответить на вопрос «Почему?». Учтите, что поиск ответа на этот вопрос может оказаться весьма непростой задачей, потому что в процессе анализа требований речь зачастую идет о неявных допущениях и подразумеваемых знаниях. На таких встречах следует избегать дискуссий по поводу технических решений, потому что они переводят обсуждение из предметной области заказчика в область программирования.

Эйнар Ландре (Einar Landre) — профессионал в области программного обеспечения с 25-летним опытом работы в качестве разработчика, архитектора, менеджера, консультанта и автора/лектора. В настоящее время работает в группе коммерческих приложений фирмы StatoilHydro, где занимается разработкой приложений, критических для бизнеса, оценкой архитектуры и оптимизацией процессов разработки. Основные сферы его интересов — сервис-ориентированные архитектуры, проектирование на основе предметной области (domain-driven design), применение мультиагентов и проектирование интенсивно используемых крупномасштабных сетевых систем.

Встаньте! Уди Дахан

Для многих из нас карьера архитектора начиналась с какой-либо чисто технической должности, где успех определялся в основном способностью общаться с компьютерами. Однако в роли архитектора нам приходится общаться главным образом с другими людьми. Обсуждаете ли вы с разработчиками преимущества того или иного шаблона или объясняете руководству плюсы и минусы покупки промежуточного программного обеспечения, залогом успеха являются ваши навыки общения.

Объективно измерить степень влияния архитектора на проект довольно сложно, но одно совершенно ясно: если разработчики постоянно игнорируют указания архитектора, а руководство не придает значения его рекомендациям, «правильность» действий архитектора никак не повлияет на развитие его карьеры. Опытные архитекторы понимают, что они должны «продвигать» свои идеи, а эта задача требует умения эффективно общаться.

На тему межличностного общения написано множество книг, но я хотел бы предложить вашему вниманию один простой и практичный прием, который радикально повысит эффективность вашего общения и соответственно упрочит ваш успех в роли архитектора. В какой бы ситуации вам ни приходилось объяснять свою позицию сразу нескольким слушателям, встаньте. Неважно, где вы при этом находитесь — на официальном анализе проекта системы или неформальном обсуждении пары диаграмм. Встаньте — особенно если все остальные сидят.

Когда вы встаете, окружающие автоматически начинают воспринимать вас как авторитетного и уверенного в себе человека. Вы становитесь центром внимания. Вас будут реже перебивать. Все это окажет существенное влияние на обсуждение независимо от того, будут приняты ваши рекомендации или нет.

Также следует отметить, что стоящий человек более интенсивно использует жестикуляцию и мимику. Если вы общаетесь с группой из 10 и более человек, вставание поможет установить зрительный контакт со всей аудиторией. Зрительный контакт, жестикуляция, мимика и другие визуальные элементы играют важную роль в общении. Кроме того, положение стоя изменяет тональность и громкость голоса, а также темп речи: вы начинаете говорить так, чтобы вас было слышно в большом помещении, делая паузы для выделения важных моментов. Все эти элементы вносят существенный вклад в эффективность общения.

Хотите повысить эффективность передачи своих идей в процессе общения более чем вдвое? Это очень просто: встаньте.

Уди Дахан (Udi Dahan) — Шаман от Программирования; его заслуги были признаны корпорацией Microsoft и в течение трех лет оценивались престижным званием «Наиболее ценного специалиста» (Most Valuable Professional) в области архитектуры решений. В качестве советника по коммуникационным технологиям Уди работает с компанией Microsoft над WCF, WF и Oslo. Он также участвует в работе консультативных комитетов Microsoft Software Factories Initiative и проекта Prism группы Patterns & Practices. Он оказывает консультации в области современных архитектур и обучает клиентов по всему миру. Его основной специальностью является проектирование сервис-ориентированных, масштабируемых и безопасных архитектур на базе платформы. NET.

Сбои неизбежны Майкл Найгард

Оборудование подвержено сбоям, поэтому мы вводим в наши системы избыточность. Она позволяет пережить отдельные сбои оборудования, но повышает вероятность того, что в любой момент времени в системе будет присутствовать хотя бы одна неисправность.

Программный код тоже подвержен сбоям. Наши приложения строятся на основе программного кода, а значит, они тоже уязвимы. Мы реализуем средства мониторинга, сообщающие о сбоях приложения, однако в основе этих средств тоже лежит программный код, а значит, они сами подвержены сбоям. Люди тоже совершают ошибки, поэтому мы стараемся автоматизировать наши действия, диагностику и рабочие процессы. Автоматизация снижает вероятность ошибок, обусловленных нарушениями правил, но повышает вероятность ошибок, возникающих из-за отсутствия правил. Ни одна автоматизированная система не способна реагировать на такой спектр ситуаций, как человек.

Поэтому мы добавляем к средствам автоматизации механизмы мониторинга. Новое программное обеспечение, новые возможности для ошибок.

Сети строятся из оборудования, программного обеспечения и очень длинных линий связи. А значит, и сети подвержены сбоям. Даже если сеть работает нормально, ее поведение формально не прогнозируемо, потому что пространство состояний большой сети с практической точки зрения бесконечно. Отдельные компоненты могут обладать детерминированным поведением, но поведение их совокупности по сути своей хаотично.

Любой механизм безопасности, который мы применяем для устранения некоторой разновидности ошибок, вводит новые виды сбоев. Мы организуем кластеризацию, чтобы приложение автоматически переходило со сбойного сервера на рабочий, но теперь при капризах кластерной сети возникает риск «расщепления мощностей». [5]

Стоит напомнить, что авария на Тримайл-Айленд [6] произошла в основном из-за клапана сброса давления — механизма безопасности, который должен был предотвращать некоторые виды сбоев, связанных с избыточным давлением.

5

Ситуация, при которой каждая сторона убеждена в полной неработоспособности другой стороны и продолжает захватывать ресурсы так, как если бы другой стороне никакие ресурсы не принадлежали. — Примеч. перев.

6

Крупнейшая авария в ядерной энергетике США, сопровождавшаяся частичным расплавлением активной зоны реактора. — Примеч. перев.

Стало быть, сбои в системах в любом случае неизбежны. Так что же нам делать?

Осознайте один факт: независимо ни от чего в вашей системе будут происходить различные сбои. Отрицая их неизбежность, вы утрачиваете возможность контроля и изоляции этих сбоев. Но, приняв этот факт, вы сможете спроектировать реакцию своей системы на конкретные сбои. По аналогии с тем, как конструкторы автомобилей создают зоны деформации (области, деформирующиеся в первую очередь и гасящие энергию столкновения для пассивной защиты пассажиров), вы можете спроектировать защитные режимы сбоев, которые будут изолировать повреждения и защищать остальные компоненты системы.

Если этого не сделать, вам придется иметь дело со всеми непредсказуемыми — и обычно опасными — сбоями, возникающими в ходе работы системы.

Майкл Найгард (Michael Nygard) написал книгу «Release It! Design and Deploy Production-Ready Software» (Выпускаем в свет! Разработка и внедрение ПО, готового к выпуску) (Pragmatic Bookshelf), получившую премию Jolt Productivity в 2008 году. Другие его публикации можно найти по адресу http://www.michaelnygard.com/blog.