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

Это особенно справедливо для тех продуктов, в которых пользовательский интерфейс пишется не на том языке программирования, на котором создается вся остальная система.

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

Винаяк Хеджд (Vinayak Hegde) — технофил, интересующийся компьютерами, фотографией и предпринимательством. В настоящее время, работает архитектором в компании Akamai Technologies.

Лучшие программы не строят — их выращивают

Билл де Ора

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

Самым верным предвестником провала программного продукта является его размер. Если задуматься, нет никакого смысла начинать с проектирования крупномасштабной системы. Тем не менее в какой-то момент у каждого из нас возникает соблазн действовать именно так. Помимо неизбежной побочной сложности и инерции, проектирование системы крупного размера с самого начала увеличивает масштаб проекта, что повышает вероятность его провала, затрудняет тестирование, делает проект менее стабильным, приводит к появлению лишних и бесполезных частей, обычно повышает затраты на реализацию и часто вводит в него негативную политическую составляющую. Поэтому сопротивляйтесь искушению спроектировать крупную завершенную систему, которая «с запасом» удовлетворяет имеющимся ожиданиям и поставленным требованиям, как бы соблазнительно ни выглядел такой подход. Крупномасштабным должно быть ваше видение системы, а не ее дизайн. И вы, и ваша система должны научиться адаптироваться к неизбежному изменению ситуации и требований.

Как этого добиться? Лучший метод снабдить программную систему способностью развиваться и адаптироваться — заставить ее развиваться и адаптироваться с самого начала. Вы начинаете с небольшой работоспособной системы, рабочего подмножества предполагаемой архитектуры — простейшей конфигурации, какая только может работать. Такой зародыш системы обладает многими полезными свойствами и может рассказать вам о заложенной архитектуре столько, сколько никогда не расскажет большая система (и тем более подборка документов с описанием архитектуры). Вы с большей вероятностью будете участвовать в его реализации. Миниатюрность упрощает тестирование и снижает уровень связанности. Для создания такого зародыша потребуется группа меньшего размера, что сократит затраты на координацию проекта. За его свойствами будет проще наблюдать. Его будет проще развертывать. По нему вы и ваша группа сможете как можно раньше понять, какие решения работают, а какие нет. Он покажет вам, в каких местах развитие системы затруднено, где она наверняка кристаллизуется и станет хрупкой. Где она может сломаться. И, что самое важное, вы сможете с самого начала предъявить нечто понятное и осязаемое заинтересованным сторонам проекта, помогая им как можно раньше вникнуть в общий дизайн системы.

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

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

Примечания

1

IETF (Internet Engineering Task Force) — рабочая группа по развитию Интернета. — Примеч. перев.

2

Фолксономия (folksonomy) — «народная классификация» — выполняемая силами пользователей организация информационного контента посредством назначения специальных меток (тегов). Часто противопоставляется таксономии как принципу иерархической категоризации информации. — Примеч. науч. ред.

3

Термин «мемовод» (meme wrangler) придумал сам Нил Форд. Он считает, что «…это гораздо лучше обесценившегося термина „архитектор“. Очень жаль, что из-за отсутствия отраслевой системы сертификации эту (номинально самую высокую) должность присваивают себе люди, полностью утратившие связь с реальностью». — Примеч. перев.

4

«Великодушный пожизненный диктатор» (Benevolent Dictator For Life, BDFL) — шутливый термин в области разработки свободного ПО, которым именуют главу или основателя проекта, сохраняющего за собой право принимать окончательные решения (см. http://ru.wikipedia.org/wiki/BDFL). — Примеч. перев.

5

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

6

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

7

Английское слово sense в зависимости от ситуации может переводиться и как «смысл», и как «чувство, чутье», поэтому в английском тексте перекличка терминов (common sense — «здравый смысл» и contextual sense — «контекстное чутье») выглядит более явной. — Примеч. ред.

8

См. Эрик Эванс (Eric Evans) «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Проектирование на основе предметной области: как совладать с присущей программам сложностью) (Addison-Wesley Professional).

9

DTD (Document Type Definition) — определение типа документа — преамбула документа, определяющая в языках структурной разметки данных (SGML, XML) состав и структуру документа. — Примеч. ред.

10

ETL (Extract, Transform, Load — извлечение, преобразование, загрузка) — один из основных процессов в управлении хранилищами данных (см. http://ru.wikipedia.org/wiki/ETL) — Примеч. ред.

11

Опционное мышление (options thinking) — подход к оценке эффективности проектов с точки зрения концепции реальных опционов (см. http://ru.wikipedia.org/wiki/Реальный_опцион), представляющий собой поиск дополнительных возможностей, не учитываемых при традиционном анализе. Опционное мышление применимо к широкому спектру проектов: слияния и поглощения, банковское кредитование, инновационные проекты и т. п. — Примеч. ред.

12

Автор обыгрывает стандартное предупреждение, размещаемое на выпуклых автомобильных зеркалах заднего вида: «Предметы находятся ближе, чем их отражение в зеркале». — Примеч. ред.

13

Количество зависимостей (class fan out) определяется количеством классов, на которых основана реализация данного класса. Квадрат этой величины определяет стоимость поддержки текущей функциональности. — Примеч. науч. ред.

14

Цикломатическая