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

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

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

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

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

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

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

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

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

15

Журнал «Компьютерра», опубликовавший русский перевод этой статьи и авторское послесловие к ней, сделал ее темой номера («Компьютерра», № 17 (589), 5 мая 2005 г., http://offline.computerra.ru/2005/589/). — Примеч. ред.

Прим ред. FB2: Ссылка устарела, статья доступна по ссылке https://old.computerra.ru/2005/589/207308/

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

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

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

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

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

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

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

Филип Нельсон (Philip Nelson) — технический специалист широкого профиля. На заре своей карьеры он имел дело с аппаратным обеспечением компьютеров, затем занялся сетями, системами и администрированием и в конечном итоге пришел к разработке программного обеспечения и архитектуры, обнаружив, что там-то и происходит самое интересное. Он работал над программными решениями для транспорта, финансов, производства, маркетинга и многих других отраслей, связанных с инфраструктурой.

Время меняет все Филип Нельсон

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

Выбирайте достойную задачу

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