В какой момент файл конфигурации становится языком программирования?

Я уже некоторое время обдумывал конфигурационные файлы и их отношение к коду, и в зависимости от дня и направления ветра мое мнение, похоже, меняется. Хотя я все больше и больше возвращаюсь к осознанию, которое я впервые получил во время изучения Лиспа: между данными и кодом нет большой разницы. Это кажется вдвойне верным для файлов конфигурации. Если смотреть в правильном свете, сценарий Perl - это немного больше, чем файл конфигурации для perl. Это, как правило, имеет довольно тяжелые последствия для таких задач, как QA и разделения труда, например, кто должен нести ответственность за изменение файлов конфигурации.

Переход от файла конфигурации к полноценному языку обычно происходит медленно и, по-видимому, обусловлен желанием иметь общую систему. Большинство проектов, кажется, начинаются с малого с нескольких элементов конфигурации, например, где писать журналы, где искать данные, имена пользователей и пароли и т. Д. Но затем они начинают расти: функции начинают можно включать и выключать, время и порядок операций начинают контролироваться, и, неизбежно, кто-то захочет начать добавлять к нему логику (например, используйте 10, если машина - X, и 15, если машина - Y). В какой-то момент файл конфигурации становится языком предметной области, причем плохо написанным.

Теперь, когда я приступил к подготовке сцены, вот мои вопросы:

1. Какова истинная цель файла конфигурации?
2. Следует ли попытаться сделать файлы конфигурации простыми?
3. Кто должен нести ответственность за внесение в них изменений (разработчики, пользователи, администраторы и т. Д.)?
4. Должны ли они контролироваться источником (см. Вопрос 3)?

Как я уже сказал ранее, мои ответы на эти вопросы постоянно меняются, но сейчас я думаю:

1. чтобы позволить непрограммистам быстро изменять большие куски поведения
2. да, все, что не является грубым, должно быть в коде
3. пользователи должны нести ответственность за файлы конфигурации, а программисты должны нести ответственность за уровень конфигурации между файлами конфигурации и кодом, который дает более точный контроль над приложением.
4. нет, но более мелкозернистый средний слой должен быть

Очень интересные вопросы!

Я стараюсь ограничивать свои файлы конфигурации очень простым форматом «ключ = значение», потому что я полностью согласен с вами, что файлы конфигурации могут очень быстро превратиться в полноценные программы. Например, любой, кто когда-либо пытался «настроить» OpenSER, знает, о чем вы говорите: это не конфигурация, это (болезненное) программирование.

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

Итак, чтобы ответить на ваши вопросы:

1. Какова истинная цель файла конфигурации?

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

2. Следует ли попытаться сделать файлы конфигурации простыми?

   Определенно. Как вы предположили, «программирование» в файле конфигурации - это ужасно. Я считаю, что этого следует избегать.

3. Кто должен нести ответственность за внесение в них изменений (разработчики, пользователи, администраторы и т. Д.)?

   В общем, я бы сказал админам, которые разворачивают приложение.

4. Должны ли они контролироваться источником (см. Вопрос 3)?

   Я обычно не исходный контроль конфигурационные файлы сами, но я сделать исходный контроль конфигурационный файл шаблона, со всеми параметрами и их значения по умолчанию, и комментарии , описывающие то , что они делают. Например, если файл конфигурации имеет имя database.conf, я обычно использую исходный код файла с именем database.conf.template. Сейчас я, конечно, говорю о том, чем занимаюсь как разработчик . Как администратор , я могу контролировать исходный код фактических настроек, которые я выбираю для каждой установки. Например, мы управляем несколькими сотнями серверов удаленно, и нам нужно отслеживать их конфигурации: мы решили сделать это с помощью системы контроля версий.

редактировать: Хотя я считаю, что вышесказанное верно для большинства приложений, конечно, всегда есть исключения. Например, ваше приложение может позволять своим пользователям динамически настраивать сложные правила. Большинство почтовых клиентов позволяют пользователям определять правила для управления своими электронными письмами (например, «все электронные письма, приходящие от 'john doe' и не содержащие меня в поле« Кому: », должны быть отброшены»). Другой пример - приложение, которое позволяет пользователю определять новое сложное коммерческое предложение. Вы также можете подумать о таких приложениях, как Cognos, которые позволяют пользователям создавать сложные отчеты по базам данных. Почтовый клиент, вероятно, предложит пользователю простой интерфейс для определения правил, и это сгенерирует сложный файл конфигурации (или даже, возможно, немного кода). С другой стороны, пользовательская конфигурация коммерческих предложений может быть сохранена в базе данных в структурированном виде (ни простая структура ключ = значение, ни часть кода). А некоторые другие приложения могут даже позволить пользователю писать код на Python, VB или каком-либо другом языке с возможностью автоматизации. Другими словами ... ваш пробег может отличаться.

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

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

Вы заметите, что это в основном операторы key = value, где value может быть любым из встроенных типов Lua. Самое сложное - это списки, и они не такие уж сложные (это просто вопрос синтаксиса).

Теперь я просто жду, когда кто-нибудь спросит, как устанавливать случайное значение порта своего сервера при каждом его запуске ...

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

key = val
key2 = val
name = `hostname`

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

Вместо этого я решил, что у меня будет две формы:

1. Если файл начинается с "#!" и был исполняемым, я бы проанализировал результат его запуска.

2. В противном случае я бы прочитал это как есть

Это означает, что теперь я могу позволить людям писать «файлы конфигурации», которые выглядят следующим образом:

 #!/usr/bin/perl
if ( -x /bin/foo ) 
{
   print <<EOF;
foo=me
bar=you
EOF
}
else
{
   print <<EOF;
foo=bar
bar=foo
EOF
}

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

Каждая (достаточно долгоживущая) схема конфигурационного файла со временем становится языком программирования. Учитывая все описанные вами последствия, разработчику конфигурационного файла было бы разумно понять, что он создает язык программирования, и планировать его соответствующим образом, чтобы не обременять будущих пользователей плохим наследием.

У меня другая философия относительно файлов конфигурации. Данные о том, как следует запускать приложение, по-прежнему являются данными и, следовательно, принадлежат хранилищу данных, а не коду (файл конфигурации IMO - это код). Если конечным пользователям необходимо иметь возможность изменять данные, тогда приложение должно предоставить интерфейс для этого.

Я использую только файлы конфигурации, чтобы указывать на хранилища данных.

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

Другой способ взглянуть на это состоит в том, что многие файлы конфигурации способны только к разметке данных, тогда как правильный язык программирования должен уметь реализовывать алгоритмы . Например, JSON - это формат файла конфигурации, тогда как ECMA Script - это язык программирования.

Вот мои мысли:

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

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

3. Зависит от того, что и почему вносятся изменения. Если пользователи собираются его менять, нужно сделать интерфейс, чтобы скрыть их от деталей. То же самое часто бывает и с не разработчиками в целом.

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

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

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

• Либо я использую возможности конфигурации операционных систем (например, plist, gconf или что-то еще),
• Или простой плоский файл, который может обрабатываться чем-то вроде стандартного анализатора INI.
• Укусите пулю и подключите легкий синтаксический анализатор языка, обычно lua, иногда tcl, в приложение,
• Или храните данные в SQLite или аналогичной реляционной базе данных.

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

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

Это зависит от того, с чем вы согласны с другими разработчиками в команде. Вы используете файлы конфигурации как файлы конфигурации или создаете приложение на основе модели ?

Симптомы превращения файла конфигурации в язык программирования:

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

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

Хороший подход - использовать красиво оформленный язык, скажем, python или ruby, и использовать его для создания DSL для вашей конфигурации. Таким образом, ваш язык конфигурации может оставаться простым на первый взгляд, но на самом деле оставаться полноценным языком программирования.

Я считаю, что ваш вопрос очень актуален, учитывая переход к «свободным интерфейсам». Многие разработчики «увидели свет» в отношении приложений, сконфигурированных с помощью XML. Использование XML может быть очень подробным и трудным для правильного редактирования (особенно, если не указана схема). Наличие свободного интерфейса позволяет разработчику настроить приложение на предметно-ориентированном языке с помощью некоторых пар ключ-значение из файла конфигурации в виде простого текста (или, возможно, параметров командной строки). Это также упрощает установку и настройку новых экземпляров приложения для тестирования или чего-то еще.

Вот мои ответы на ваш вопрос:

• Какова истинная цель файла конфигурации?

Файл конфигурации - это способ позволить пользователю настроить поведение своей программы во время выполнения.

• Следует ли попытаться сделать файлы конфигурации простыми?

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

• Кто должен нести ответственность за внесение в них изменений (разработчики, пользователи, администраторы и т. Д.)?

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

• Должны ли они контролироваться источником (см. Вопрос 3)?

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

Я видел программы на Python, в которых файл конфигурации представляет собой код. Если вам не нужно делать ничего особенного (условные выражения и т. Д.), Он не сильно отличается от других стилей конфигурации. например, я мог бы создать файл config.pyс такими вещами:

num_threads = 13
hostname = 'myhost'

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

Да, файлы конфигурации должны быть простыми. Сами они не должны содержать «логики» - воспринимайте их как список выражений в операторах if, а не как условные операторы в целом.

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

Одна из целей работы в «Осло» в Microsoft - разрешить (но не требовать) разрешение этой проблемы.

1. Приложение будет поставляться с моделями любых новых компонентов, которые оно включает. Он также будет использовать существующие модели. Например, он может включать веб-службу, поэтому может повторно использовать системную модель веб-службы.
2. Модели будут включать метаданные, описывающие их, в том числе достаточно информации для инструментов для доступа к ним в текстовом или графическом виде.
3. Детали моделей будут соответствовать «комплектации».

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

Я буду противником и сообщу, что это только язык, когда он воплощает больше, чем может быть представлено XML; или иначе, когда XML считается языком.

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

В конечном счете, «язык» - это мягкая абстракция, но да, края неоднозначны.

Код наших приложений становится менее важным ... Есть сценарии, есть всевозможные атрибуты, которые определяют поведение классов, методов, аргументов методов и свойств. Пользователи могут определять триггеры базы данных и ограничения базы данных. Могут быть очень сложные файлы конфигурации. Иногда пользователь может определить стили XSLT для управления вводом и выводом, потому что наши системы должны быть открытыми (SOA). И есть такие вещи, как BizzTalk, которые тоже требуют сложной настройки. Пользователи могут определять сложные рабочие процессы.

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

Я большой поклонник использования программ Python в качестве файлов конфигурации, особенно для демонов. Мне нравится делать демон полностью свободным от конфигурации, за исключением «порта конфигурации». Затем программа python подключается к демону и приступает к созданию объектов в демоне и связывает их вместе, чтобы создать желаемую конфигурацию. После того, как все настроено, демон может работать сам по себе. Преимущества, конечно же, заключаются в том, что вы получаете полноценный язык программирования для написания ваших файлов конфигурации, и, поскольку у вас уже есть способ общаться с демоном из другой программы, вы можете использовать его для отладки и получения статистики. Основным недостатком является необходимость иметь дело с сообщениями из другой программы, поступающими в любое время.

Файл конфигурации : "Какова моя цель?"
Вы : "Настроить масло".
Файл конфигурации : "Хорошо ..."
Файл конфигурации : "Какова моя цель?"
Вы : "Настроить масло".
Файл конфигурации : «Боже мой».

1. Не существует "истинного назначения" файла конфигурации. Все, что имеет смысл для вашего приложения. В общем, вещи, которые различаются (или могут отличаться) на разных машинах и не меняются в середине выполнения вашего приложения, вероятно, должны быть в файле конфигурации. Значения по умолчанию, порты и адреса для других служб - отличные кандидаты. Ключи и секреты также являются отличными кандидатами, но их следует обрабатывать отдельно от вашей обычной конфигурации из соображений безопасности. Я не согласен с тем, что целью файла конфигурации является возможность быстрого внесения изменений. Цель должна заключаться в обеспечении гибкости в настройке вашего приложения. Если файл конфигурации - это быстрый и простой способ обеспечить такую ​​гибкость, тем лучше, но вы не должны предполагать, что ваши файлы конфигурации будут часто меняться.

2. Да и нет. Стоит ли попытаться сделать код вашего приложения простым? Да. Вы должны попытаться сделать все, что вы пишете, простым и точным. Не сложнее, чем должно быть. То же самое и с вашей конфигурацией. Однако это очень зависит от приложения. Жесткое кодирование того, что должно быть в конфигурации, потому что это сделало бы вашу конфигурацию «слишком сложной» - плохой дизайн. Фактически, попытка «сделать вещи простыми» - вот почему файлы конфигурации превращаются в огромный беспорядок. Иногда самый простой шаг - это модульность. Вот почему ваши файлы конфигурации должны быть написаны на хорошо известном языке программирования общего назначения, а не на каком-то ужасном языке конфигурации (читайте: все «языки конфигурации» - отстой ).

3. Опять же, кто должен изменять файлы конфигурации, полностью зависит от приложения. Но я согласен с miniquark, тот, кто развертывает приложение, должен отвечать за настройку.

4. Контролируйте все, что можете. Контроль версий великолепен. Вы можете очень легко откатить данные, и у вас есть полная история внесенных вами изменений и записи о том, кто эти изменения внес. Так почему не?