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

«Срезание углов» сейчас обойдется слишком дорого потом Скот Макфи

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

Допустим, кто-то сказал вам, что модульные тесты не приносят непосредственной пользы, и вы даете своим разработчикам указание не углубляться в их создание. Впоследствии это значительно затруднит модификацию готовой системы и породит чувство неуверенности во внесенных изменениях. Относительно небольшие изменения потребуют гораздо большего объема ручного тестирования, что приведет к нестабильности и росту затрат на сопровождение, а получившийся дизайн нельзя будет назвать полностью тестируемым (не говоря уже о соответствии принципу «опережающего тестирования»).[37]

Серьезной архитектурной ошибкой является и попытка приспособить существующую систему к тем целям, для которых она не предназначалась, под тем предлогом, что использование существующей системы может каким-то образом снизить затраты. Например, архитектурные компоненты BPEL[38] в сочетании с триггерами баз данных можно приспособить для реализации системы на основе асинхронной передачи сообщений. Такие решения обычно возникают из соображений удобства либо потому, что эта архитектура известна вам или клиенту. Однако действительным основанием для такого выбора могут послужить только четко сформулированные требования — это обязательное условие. Неудачные решения на ранней стадии проекта обходятся очень дорого, когда архитектуру системы приходится изменять в соответствии с новыми требованиями.

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

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

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

Скот Макфи (Scot Mcphee) — австралийский разработчик и архитектор с 15-летним опытом программирования и проектирования приложений. Последние 8 лет работал главным образом с технологиями семейства J2EE.