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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

---

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

Answer 2

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

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

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

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

Answer 3

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

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 }

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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

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

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

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

Answer 9

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

num_threads = 13
hostname = 'myhost'

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

Answer 10

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

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

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

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

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

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

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

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

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

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