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

Небоскребы не масштабируются Майкл Найгард

Разработку программных продуктов часто сравнивают со строительством небоскребов, дамб и дорог. В некоторых важных аспектах это уместное сравнение.

Самая трудная часть строительства не проектирование здания, которое будет стоять на своем месте после завершения, а проработка процесса строительства. Этот процесс начнется с пустой площадки и завершится готовым зданием. За это время каждый рабочий должен иметь возможность применить свои профессиональные навыки, а частично возведенное строение должно оставаться устойчивым. Мы можем извлечь из этой аналогии полезный урок в том, что касается развертывания больших интегрированных систем. (А к категории «интегрированных» относятся практически все корпоративные и веб-приложения!) Традиционное развертывание по схеме «Большого взрыва» выглядит так, словно вы привезли на пустырь груду балок и брусьев, подбросили их в воздух и ожидаете, что они сами сложатся в форме здания.

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

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

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

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

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

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

Нечасто встречаются методы, обеспечивающие более высокую коммерческую ценность в сочетании с улучшением архитектурных качеств, но раннее развертывание отдельных компонентов обладает обоими достоинствами.

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