У який момент файл конфігурації стає мовою програмування?

Я вже деякий час розмірковую над конфігураційними файлами та їхнім відношенням до коду, і залежно від дня та напрямку вітру мої думки, здається, змінюються. Все більше і більше, хоча я постійно повертаюся до усвідомлення, яке я вперше здобув під час вивчення Lisp: між даними та кодом мало різниці. Це здається подвійним для конфігураційних файлів. Якщо розглянути його у правильному світлі, сценарій Perl - це трохи більше, ніж конфігураційний файл для perl. Це, як правило, має досить важкі наслідки для таких завдань, як забезпечення якості та розподіл праці, наприклад, хто повинен відповідати за зміну конфігураційних файлів.

Перехід від конфігураційного файлу до повноцінної мови, як правило, відбувається повільно і, здається, зумовлений бажанням мати загальну систему. Здається, більшість проектів починаються з невеликих кількох елементів конфігурації, наприклад, де писати журнали, де шукати дані, імена користувачів, паролі тощо. Але потім вони починають рости: функції починають вмикати або вимикати, таймінги та порядок операцій починають контролюватися, і, неминуче, хтось хоче почати додавати до цього логіку (наприклад, використовуйте 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 "і не мають мене в полі To:, слід відкидати"). Інший приклад - програма, яка дозволяє користувачеві визначити нову складну комерційну пропозицію. Ви також можете подумати про такі програми, як Cognos, які дозволяють своїм користувачам створювати складні звіти баз даних. Клієнт електронної пошти, ймовірно, запропонує користувачеві простий інтерфейс для визначення правил, і це створить складний конфігураційний файл (або, можливо, трохи коду). З іншої сторони, визначена користувачем конфігурація комерційних пропозицій може бути збережена в базі даних структурованим способом (ні простий ключ = структура значень, ні частина коду). А деякі інші програми можуть навіть дозволити користувачеві кодувати на python або VB, або на іншій мові, що підтримує автоматизацію. Іншими словами ... ваш пробіг може відрізнятися.

Гаразд. У вас буде кілька користувачів, які хочуть дійсно просту конфігурацію, ви повинні надати їх їм. У той же час у вас будуть постійні запити "Чи можете ви це додати? Як мені це зробити у файлі конфігурації?", Я не розумію, чому ви не можете підтримувати обидві групи.

Проект, над яким я зараз працюю, використовує Lua для свого конфігураційного файлу. Lua - це мова сценаріїв, і вона працює досить добре в цьому сценарії. Існує приклад нашої конфігурації за замовчуванням .

Ви зауважите, що це в основному оператори key = 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, він обґрунтовано вважається мовою програмування. Згідно з цим визначенням, формат файлу для опису рівнів Sokoban вважається мовою програмування (див. Тут ). Існують і інші рівні складності нижче Тьюрінга, які також можуть враховуватись, наприклад, регулярні граматики та автоматичні дані .

Інший спосіб подивитися на це полягає в тому, що багато конфігураційних файлів здатні лише до розмітки даних, тоді як відповідна мова програмування повинна мати можливість реалізувати алгоритми . Наприклад, JSON - це формат файлу конфігурації, тоді як сценарій ECMA - мова програмування.

Ось мої думки:

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 підключається до демона і продовжує створювати об'єкти в демоні та з'єднувати їх, щоб створити бажану конфігурацію. Як тільки все налаштовано, демон можна залишити для самостійного запуску. Звичайно, переваги полягають у тому, що ви отримуєте повноцінну мову програмування для написання своїх конфігураційних файлів, і оскільки у вас вже є спосіб розмовляти з демоном з іншої програми, ви можете використовувати його для налагодження та отримання статистики. Основним недоліком є ​​необхідність мати справу з повідомленнями іншої програми, що надходять у будь-який час.

Файл налаштування : "Яка моя мета?"
Ви : "Налаштуйте масло".
Файл конфігурації : "Ok ..."
Файл конфігурації : "Яка моя мета?"
Ви : "Ви налаштовуєте масло".
Файл конфігурації : "Боже мій".

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

2. Так і ні. Якщо ви намагаєтеся спростити код програми? Так. Вам слід спробувати зробити все, що ви пишете, простим і чітким. Не складніше, ніж це повинно бути. Те саме стосується вашої конфігурації. Однак це дуже специфічно для програми. Жорстке кодування того, що має бути в конфігурі, оскільки це зробить вашу конфігурацію "занадто складною", це поганий дизайн. Насправді, намагаючись «зробити все просто», ось чому конфігураційні файли в кінцевому підсумку стають гігантським безладом. Іноді найпростішим кроком є ​​модулярізація. Ось чому ваші конфігураційні файли повинні бути написані на добре відомій загальній програмовій мові - а не на якійсь жахливій мові конфігурації (читайте: всі "мови конфігурації" відмовні ).

3. Знову ж, хто повинен змінювати конфігураційні файли, повністю залежить від програми. Але я погоджуюся з miniquark, хто розгортає додаток, повинен відповідати за конфігурацію.

4. Джерело контролює все, що можна. Джерело контролю є чудовим. Ви можете дуже легко повертати речі назад, і у вас є повна історія внесених змін та запис того, хто вніс ці зміни. То чому б ні?