Дозвольте поставити вам цілком серйозне зустрічне запитання: чим, на ваш погляд, різниця між "даними" та "кодом"?
Коли я чую слово "дані", я думаю "стан". Дані, за визначенням, це те, що сама програма призначена для управління, а тому сама річ, про яку програма ніколи не може знати про час компіляції. Неможливо ввімкнути дані жорсткого коду, тому що як тільки ви його жорстко кодуєте, це стає поведінкою, а не даними.
Тип даних змінюється залежно від програми; комерційна система виставлення рахунків може зберігати інформацію про клієнтів і замовляти в базі даних SQL, а векторно-графічна програма може зберігати дані геометрії та метадані у двійковому файлі. І в обох цих випадках, і в усьому між ними існує чітке і нерозривне розділення коду та даних. Дані належать користувачеві , а не програмісту, тому вони ніколи не можуть бути жорстко кодованими.
Те, про що вам здається, йдеться про те, щоб використовувати найбільш технічно точний опис, доступний моєму поточному словнику: інформація, що регулює поведінку програми, яка не пишеться основною мовою програмування, яка використовується для розробки більшості додатків.
Навіть це визначення, яке є значно менш неоднозначним, ніж просто слово "дані", має кілька проблем. Наприклад, що робити, якщо значні частини програми написані різними мовами? Я особисто працював над декількома проектами, які складають близько 50% C # і 50% JavaScript. Чи код JavaScript "дані"? Більшість людей скажуть "ні". Що з HTML, це "дані"? Більшість людей все одно скажуть ні.
Що з CSS? Це дані чи код? Якщо ми вважаємо код тим, що контролює поведінку програми, то CSS насправді не є кодом, оскільки він впливає лише на зовнішній вигляд, а не на поведінку. Але це насправді не дані; користувач не володіє ним, додаток навіть не є ним. Це еквівалент коду для дизайнера інтерфейсу. Це схоже на код, але не зовсім код.
Я можу назвати CSS своєрідною конфігурацією, але більш практичним визначенням є те, що це просто код на доменній мові . Ось що часто представляють ваші XML, YAML та інші "відформатовані файли". І тому, що ми використовуємо мову, що залежить від домену, є те, що, як правило, він є одночасно більш стислим і виразним у своєму конкретному домені, ніж кодування тієї самої інформації на загальноприйнятій мові програмування, як C або C # або Java.
Ви впізнаєте наступний формат?
{
name: 'Jane Doe',
age: 27,
interests: ['cats', 'shoes']
}
Я впевнений, що це робить більшість людей; це JSON . І ось що цікаво про JSON: У JavaScript це чітко код, а в іншій мові - чітко відформатовані дані. Практично в кожній окремій мові програмування є принаймні одна бібліотека для "розбору" JSON.
Якщо ми використовуємо такий самий синтаксис всередині функції у файлі JavaScript, він не може бути іншим, крім коду. І все ж, якщо ми візьмемо той JSON, засуньте його у .jsonфайл та розберемо у додатку Java, раптом це "дані". Це справді має сенс?
Я стверджую, що "дані-ніс" або "конфігурація-ніс" або "кодо-ніс" притаманні тому , що описується, а не тому, як це описується.
Якщо вашій програмі потрібен словник в 1 мільйон слів, щоб, скажімо, генерувати випадкову парольну фразу, ви хочете її кодувати так:
var words = new List<string>();
words.Add("aa");
words.Add("aah");
words.Add("ahhed");
// snip 172836 more lines
words.Add("zyzzyva");
words.Add("zyzzyvas");
Або ви просто засуньте всі ці слова в текстовий файл з обмеженими рядками і скажете програмі прочитати з нього? Насправді не важливо, якщо список слів ніколи не змінюється, це не питання про те, що ви жорстко чи м'яко кодуєте (що багато хто справедливо вважає анти-шаблоном, коли неправильно застосовується), це просто питання про який формат є найбільш ефективним і полегшує опис "речей", якими б не були "речі". Це досить важливо, називаєте ви це кодом або даними; це інформація, яка потрібна вашій програмі для запуску, а формат плоских файлів - це найзручніший спосіб управління та обслуговування.
Якщо припустити, що ви дотримуєтеся належних практик, усі ці речі так чи інакше переходять у контроль джерел, тому ви можете також назвати його кодом, просто кодом в іншому і, можливо, дуже мінімалістичному форматі. Або ви можете назвати його конфігурацією, але єдине, що справді відрізняє код від конфігурації, це чи ви документуєте його чи не повідомте кінцевим користувачам, як його змінити. Можливо, ви можете придумати якийсь хибний аргумент про інтерпретацію конфігурації під час запуску або під час виконання, а не під час компіляції, але тоді ви б почали описувати декілька динамічно набраних мов і майже напевно що-небудь із механізмом сценаріїв, вбудованим всередину нього (наприклад, більшість ігор). Код і конфігурація - це все, що ви вирішите позначати як, ні більше, ні менше.
Тепер, є це небезпека для експортування інформації, яка на самому ділі не безпечно змінити (див «м'яке кодування» вище). Якщо ви екстерналізуєте свій масив голосних у файлі конфігурації та документуєте його як файл конфігурації своїм кінцевим користувачам, ви даєте їм майже бездоганний спосіб миттєво зламати додаток, наприклад, поставивши "q" як голосну. Але це не є принциповою проблемою з "розділенням коду та даних", це просто поганий дизайнерський сенс.
Те, що я кажу молодшим розробникам, - це те, що вони завжди повинні екстерналізувати налаштування, які вони очікують змінити в кожному середовищі. Це включає такі речі, як рядки з'єднання, імена користувачів, ключі API, шляхи до каталогу тощо. Вони можуть бути однаковими на вашому коробці розробників і на виробництві, але, мабуть, ні, і сисадміни вирішать, як вони хочуть, щоб це виглядало у виробництві, а не в чортах. Отже, вам потрібен спосіб застосування однієї групи налаштувань, застосованих на деяких машинах, а інших налаштувань, застосованих на інших машинах - ерго, зовнішні файли конфігурації (або налаштування в базі даних тощо).
Але підкреслюю, що просто вводити якісь "дані" у "файл" - це не те саме, що ексстерналізувати їх як конфігурацію. Введення словника слів у текстовий файл не означає, що ви хочете, щоб користувачі (або ІТ) його міняли, це лише спосіб полегшити розробникам зрозуміти, що, до біса, і, якщо потрібно, зробити епізодичні зміни. Аналогічно, введення тієї самої інформації в таблицю бази даних не обов'язково вважається екстерналізацією поведінки, якщо таблиця є лише для читання і / або DBA доручається ніколи не накручувати її. Конфігурація означає, що дані є змінними, але насправді це визначається процесом та обов'язками, а не вибором формату.
Отже, підсумовуючи:
"Код" не є жорстко визначеним терміном. Якщо ви розширите своє визначення, щоб включити доменні мови та все інше, що впливає на поведінку, багато цього очевидного тертя просто зникне, і це матиме сенс. Ви можете мати некомпільований DSL "код" у плоскому файлі.
"Дані" мають на увазі інформацію, що належить користувачеві або користувачам або принаймні комусь, крім розробників, і, як правило, не доступна під час проектування. Це не може бути жорстко закодовано, навіть якщо ви цього хотіли. За можливим винятком коду , що самозмінюється , розділення між кодом та даними є питанням визначення, а не особистих переваг.
"М'яке кодування" може бути жахливою практикою при надмірному застосуванні, але не кожен екземпляр екстерналізації обов'язково становить програмне кодування, і багато випадків зберігання інформації у "плоских файлах" не обов'язково є добросовісною спробою екстерналізації.
Конфігурація являє собою особливий тип Soft-кодування , що є необхідним , оскільки знання про те , що додаток може знадобитися для роботи в різних середовищах. Розгортання окремого файлу конфігурації разом із додатком набагато менше роботи (і набагато менш небезпечно), ніж розгортання різної версії коду у кожному середовищі. Тож деякі види програмного кодування насправді корисні.