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

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

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

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

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

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

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

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

Лучшее — враг хорошего Грег Найберг

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

Мой совет: не поддавайтесь искушению довести дизайн или реализацию системы до совершенства! Ориентируйтесь на отметку «достаточно хорошо» и остановитесь, когда вы доберетесь до нее.

«Что именно означает „достаточно хорошо“?» — спросите вы. Это означает, что оставшиеся недочеты не оказывают сколько-нибудь заметного влияния на функциональность, удобство сопровождения или производительность системы. Архитектура и дизайн идут рука об руку. Реализованная система работает и соответствует требованиям к производительности. Программный код понятен, лаконичен и хорошо документирован. Можно ли сделать лучше? Конечно, но и так достаточно хорошо — поэтому остановитесь. Заявите о своей победе и переходите к следующей задаче.

Я считаю, что стремление к идеальному дизайну и идеальной реализации приводит к излишне усложненным и запутанным решениям, которые в конечном итоге затрудняют сопровождение системы.