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
Цикломатическая
