Статьи

Автор: Терри Янг

Введение

Сколько раз было так, что небольшое изменение в требованиях приводило к необходимости внесения изменений в код какой-либо части системы? Вместо того чтобы просто изменить настройки, требовалось сделать запрос на изменение, запланировать время разработки, изменить код, протестировать и заново развернуть программное обеспечение.
Ну уж нет, с нас довольно! На этот раз все будет иначе. В программное обеспечение новой разрабатываемой системы мы заложим широкие возможности для настройки. Для всего, что может потребовать изменений, необходимо предусмотреть соответствующие настройки в ресурсе конфигурации. Сопровождение системы будет простым делом. Перегруженность сервера? Нет проблем. Можно перекинуть компонент системы на другой сервер. Меняем один параметр настройки здесь, другой там, и система продолжает свою работу.
Вот и подошел срок. Каждый компонент системы полностью протестирован и готов к работе. Все готово к тестированию интеграции. Специалисты по обеспечению качества устанавливают различные компоненты и запускают систему. Что такое? Одна часть системы не запустилась. Оказалось, не хватает ресурса конфигурации. После прослеживания и установки недостающего ресурса — вторая попытка.
Систему опять не удалось запустить — другая ошибка, связанная с конфигурацией. В этот раз вызвавший проблему ресурс есть, но не в том месте, где его мог найти компонент. Что ж, и это исправили. Пробуем еще раз.
Ну вот… Система снова не запустилась как надо. Похоже, конфликт портов между компонентами. Как оказалось, несколько компонентов получают свою информацию из одного и того же раздела в совместно используемом ресурсе конфигурации. Устранили и эту неприятность, переходим к очередной попытке.
Так. Теперь один из компонентов сообщает, что не хватает значений конфигурации. Да уж, для этого компонента требуется конфигурирование большого числа параметров, а от документации мало толку. После продолжительных консультаций с группой разработки наконец-то получено несколько нужных значений.
Отлично, теперь система запустилась и работает. Однако при выполнении одного из тестов в журнале событий стали появляться сообщения об ошибках. После длительного процесса отладки источник проблемы обнаружен. Невероятно, но факт: еще одна проблема, связанная с конфигурированием. Было задано слишком малое значение.
После увеличения значения в настройках пробуем тест снова. Еще проблемы — оказывается, нельзя просто взять и увеличить значение этого параметра. Надо настроить еще два других значения конфигурации. Надеемся, теперь настройки согласованы друг с другом.
После выполнения нескольких тестов снова проявилась проблема. Надо настроить другой параметр конфигурации. Но загвоздка в том, что этот параметр применяется к компоненту, установленному на нескольких компьютерах, на каждом из которых есть собственный ресурс конфигурации. Значит, изменение следует внести в несколько мест.
Все это разочаровывает и раздражает! Даже больше чем раздражает — это ставит нас в неудобное положение. Вместо системы, которую удобно сопровождать, мы получили настоящий кошмар конфигурирования!

Проблемы конфигурирования

Что же теперь делать? Очевидно, конфигурация нашей системы слишком сложна. Слишком много ресурсов конфигурации и слишком много различных мест их расположения. Слишком много параметров для настройки, а в документации недостаточно информации для выбора нужных значений.
Было ли все так на самом деле? И да, и нет. Описанные в этой истории события происходили не в одном проекте. С какими-то из этих проблем конфигурирования я сталкивался в одних разработках, с остальными — в других. Эта история о том, что при плохой реализации конфигурирование компонентов, приложений и системы может стать головной болью, а не спасением (то есть, возможностью решения задач с помощью простого изменения параметра настройки). В воображении это могло представляться легким делом, а на деле можно попасть в весьма затруднительное положение.
В связи с концепцией конфигурируемости мне вспомнилось время, когда я был мальчиком и любил строить модели. Было веселее и приятнее строить модели, в которых имелись варианты выбора. В моделях автомобилей можно было выбирать устройство двигателя, разные фары, разные спойлеры и т. п. Конечно, чем больше было возможностей для выбора, тем выше становилась вероятность неправильно соединить детали (особенно если не читать инструкции) и остаться с лишними деталями, которые, по идее, должны были быть в изделии. К счастью, от моделей требовалось только, чтобы они стояли на месте и хорошо смотрелись. Они не должны были ездить. Программные системы — другое дело.
Конфигурируемость — это такая же часть программной системы. Нужно не просто предусмотреть параметры настройки. Чтобы это было эффективно, требуется с самого начала рассматривать и тщательно проектировать конфигурируемость всей программной системы. Как говорилось в одной старой рекламе масляных фильтров для автомобилей: «Можешь заплатить сейчас, а можешь позднее. Но позднее будет дороже…» (или нечто в этом роде).

Шесть важных вопросов

Одна из причин, приводящих к кошмару конфигурирования, — это ограничение проектирования только ответом на вопрос «Что?», например: «Что должно конфигурироваться?». Чтобы сделать конфигурируемость положительным качеством программной системы, надо находить ответы на вопросы: «Где должен конфигурироваться этот элемент?», «Когда и/или зачем требуется конфигурирование этого элемента?», «Как нужно конфигурировать этот элемент?».

Что?

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

Где?

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

Зачем? и Когда?

Ответы на вопросы «Зачем?» и «Когда?» помогают определить, какие элементы конфигурации являются обязательными, а какие — необязательными. Например, какой-нибудь элемент может конфигурироваться, только если требуется тонкая настройка производительности системы. В этом случае конфигурирование этого элемента должно быть необязательным. Такой элемент не обязан присутствовать в ресурсе конфигурации. В его отсутствие программа должна использовать приемлемое значение по умолчанию. Конечно, когда элемент указан в ресурсе конфигурации, он перекрывает значение по умолчанию. Следование такой стратегии позволяет обеспечить гибкую конфигурируемость системы и при этом облегчает ее первоначальную настройку и запуск.

Как?

Задумываясь над вопросом «Как?», я пытаюсь представить себе человека, которому предстоит задавать значения конфигурации. Как определить, какое значение следует ввести? Что изменится от того, какое значение будет введено? В каких ситуациях какие значения следует выбрать? Удивительно, но ответы на эти вопросы далеко не всегда можно найти! В документации лишь указывается на необходимость выбрать или ввести значение в этом поле. Нередко это приводит впоследствии к большим проблемам, когда обнаруживается, что введенное значение не подходило для этой установки. Не забывайте предоставить достаточную информацию, по которой человек, настраивающий или сопровождающий систему, сможет задать верное значение для настраиваемого параметра. Часто бывает удобно, чтобы справочная информация находилась прямо в ресурсе конфигурации, поскольку по прошествии некоторого времени бывает сложно найти отдельную документацию.
В случаях, когда настройки некоторых элементов зависят от настройки другого элемента, эта взаимосвязь обязательно должна быть четко описана в ресурсе конфигурации. Например, можно оформить зависимые элементы в виде подпунктов независимого элемента и обязательно документировать их связь. По возможности нужно делать так, чтобы программа перекрывала некорректные зависимые параметры настройки приемлемыми значениями по умолчанию и выдавала предупреждение, а не закрывалась бы с сообщением об ошибке.
Стратегия упрощения применима и к средствам управления конфигурацией тоже. Бывает склонность к тому, чтобы разместить как можно больше элементов конфигурации на одной странице. Это отпугивает человека, пытающегося сконфигурировать программное обеспечение. Даже если элементы конфигурации распределены по нескольким вкладкам, это все еще может выглядеть устрашающе. Вместо этого лучше показывать на главной странице или вкладках только обязательные элементы, а необязательные скрывать за ссылками или кнопками с заголовками типа «Дополнительные параметры».

Заключение

Как можно понять из названия этой статьи, одной из целей конфигурируемости является удобство сопровождения и технической поддержки программной системы или приложения. Применяя правильные средства, можно также улучшить управляемость. Удобством сопровождения называют «удобство модификации программной системы или компонента для устранения неполадок, повышения производительности или корректировки других свойств, а также для приспособления к изменениям рабочей среды» [IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: Institute of Electrical and Electronics Engineers, 1990]. Ключевое слово здесь — удобство.

Вопросы для критического осмысления

1. Преимущества обеспечения конфигурируемости элемента перевешивают недостатки его конфигурируемости?
2. Где должен конфигурироваться элемент? Является ли он локальным для приложения или глобальным для всей системы?
3. Зачем и когда должен конфигурироваться элемент? Является ли он обязательным или необязательным?
4. Как определить нужное значение для элемента конфигурации? Достаточно ли предоставленной информации, для того чтобы человек смог правильно сконфигурировать этот элемент?