97 этюдов для архитекторов программных систем - Нил Форд Страница 15

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

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

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

Биография автора приведена ранее.

Программирование — это часть процесса проектирования

Эйнар Ландре

Кристен Нигаард (Kristen Nygaard), отец объектно-ориентированного программирования и языка программирования Simula, говорил, что программирование — это изучение. Осознание того факта, что программирование, а точнее разработка программного обеспечения, является процессом изучения и творческого поиска, а не процессом производства и конструирования, имеет фундаментальное значение для совершенствования приемов разработки. Идеи из традиционных инженерных дисциплин в области разработки ПО не работают. Возникающие при этом проблемы документировались и анализировались ведущими мыслителями нашей области в течение более чем 30 лет. Например, в 1987 году Фредерик Брукс (Frederick Brooks, Jr.) в «Отчете оперативной группы Научного совета Министерства обороны по военному программному обеспечению» утверждал, что документно-ориентированный подход по принципу «сначала спецификация, потом разработка» лежит в основе многих проблем программного обеспечения.

Откуда же индустрия разработки программного обеспечения может черпать практические идеи для совершенствования своих методик? Как насчет отраслей производства сложных товаров массового производства: автомобилей, лекарств, полупроводников?

Возьмем автомобилестроение. Планирование новой модели начинается с выбора концепции или прототипа. Это в первую очередь механизм архитектурного позиционирования. BMW Х6 — пример новой концепции, объединяющей свойства внедорожника и купе, которую BMW называет sports activity coupe. Прежде чем вы получили возможность приобрести новый Х6, BMW потратила тысячи часов и миллионы долларов на проектирование машины и процесса ее производства. Когда BMW получает ваш заказ, одна из сборочных линий переключается и выдает версию Х6, выполненную по вашему личному заказу.

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

В своей статье «Как проектировать ПО?»[15] Джек Ривз (Jack Reeves) высказывает мнение, что единственным артефактом разработки ПО, действительно описывающим дизайн (в том смысле, как понимается и используется это понятие в классических инженерных дисциплинах), является исходный код. Собственно производство ПО автоматизировано и обеспечивается сценариями компиляции, сборки и тестирования.

Соглашаясь с тем, что создание исходного кода является частью проектирования, а не производства, мы получаем возможность применить полезные методы управления, работоспособность которых была проверена временем. Это методы управления творческой и непрогнозируемой работой, такой как разработка новой машины, нового лекарственного препарата или новой компьютерной игры. Речь идет о методах гибкого (agile) управления и бережливого (lean) производства (например, SCRUM). Эти методы направлены на то, чтобы максимизировать эффективность вложений с позиций ценности для потребителя.

Чтобы с выгодой использовать эти методы в области разработки ПО, необходимо запомнить: программирование является частью процесса проектирования, а не производства.

Биография автора приведена ранее.

Предоставьте разработчикам независимость

Филип Нельсон

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

У разработчика редко находится время для того, чтобы откинуться в кресле и подумать над тем, насколько слаженной является работа системы в целом. В то же время все внимание архитектора должно быть сосредоточено именно на этом. Пока разработчики во весь опор создают классы, методы, тесты, интерфейсы и базы данных, вы следите за тем, как эти компоненты работают в сочетании друг с другом. Ищите «узкие места» и пытайтесь устранить их. У ваших людей возникают проблемы с написанием тестов? Улучшите интерфейсы и ограничьте зависимости. Непонятно, где абстракция действительно необходима, а где можно обойтись без нее? Добейтесь лучшего понимания предметной области. Не знаете, в каком порядке создавать компоненты системы? Составьте план проекта. Разработчики повторяют одни и те же ошибки при использовании спроектированного вами API? Сделайте дизайн более понятным. Разработчики плохо понимают ваш дизайн? Пообщайтесь с ними и все подробно разъясните. Вы сами плохо понимаете, где масштабирование уместно, а где нет? Поработайте с заказчиками и разберитесь в их бизнес-модели.

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