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

Question

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

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

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

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

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

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

Answer 1

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

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

Answer 2

Зависит от того, что вы согласны с другими разработчиками в команде. Используете ли вы файлы конфигурации просто как файлы конфигурации, или вы создаете приложение Model Driven .

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

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

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

Answer 8

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

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