Позвольте мне задать вам совершенно серьезный контр-вопрос: в чем, на ваш взгляд, разница между «данными» и «кодом»?
Когда я слышу слово «данные», я думаю «государство». По определению, данные - это то, для чего предназначено само приложение, и, следовательно, та самая вещь, о которой приложение никогда не узнает во время компиляции. Не возможно , чтобы данные жесткого кода, потому что как только вы жестко закодировать его, становится поведение - не данные.
Тип данных зависит от приложения; коммерческая система выставления счетов может хранить информацию о клиентах и заказах в базе данных SQL, а программа векторной графики может хранить геометрические данные и метаданные в двоичном файле. В обоих случаях и между ними существует четкое и неразрывное разделение кода и данных. Данные принадлежат пользователю , а не программисту, поэтому они никогда не могут быть жестко запрограммированы.
Похоже, вы говорите о том, чтобы использовать наиболее технически точное описание, доступное для моего текущего словаря: информацию, управляющую поведением программы, которая не написана на основном языке программирования, используемом для разработки большинства приложений.
Даже это определение, которое значительно менее неоднозначно, чем просто слово «данные», имеет несколько проблем. Например, что, если значимые части программы написаны на разных языках? Я лично работал над несколькими проектами, в которых примерно 50% C # и 50% JavaScript. Является ли код JavaScript "данными"? Большинство людей сказали бы нет. Как насчет HTML, это «данные»? Большинство людей все равно сказали бы нет.
Как насчет CSS? Это данные или код? Если мы думаем о коде как о чем-то, что контролирует поведение программы, то CSS на самом деле не код, потому что он только (ну, в основном) влияет на внешний вид, а не на поведение. Но на самом деле это не данные; пользователь не владеет им, приложение даже не владеет им. Это эквивалент кода для дизайнера пользовательского интерфейса. Это code- как , но не совсем код.
Я мог бы назвать CSS своего рода конфигурацией, но более практичным определением является то, что это просто код на предметно-ориентированном языке . Это то, что часто представляют ваши XML, YAML и другие «отформатированные файлы». И причина, по которой мы используем предметно-ориентированный язык, заключается в том, что, вообще говоря, он одновременно более лаконичен и более выразителен в своей конкретной области, чем кодирование той же информации на языке программирования общего назначения, таком как C или C # или Java.
Вы узнаете следующий формат?
{
name: 'Jane Doe',
age: 27,
interests: ['cats', 'shoes']
}
Я уверен, что большинство людей делают; это JSON . И вот что интересного в JSON: в JavaScript это явно код, а на любом другом языке - четко отформатированные данные. Почти каждый основной язык программирования имеет по крайней мере одну библиотеку для "анализа" JSON.
Если мы используем тот же самый синтаксис внутри функции в файле JavaScript, он не может быть ничем иным, кроме кода. И все же, если мы возьмем этот JSON, поместим его в .jsonфайл и проанализируем в приложении Java, вдруг это «данные». Это действительно имеет смысл?
Я утверждаю, что «data-ness», «configuration-ness» или «code-ness» присуще тому , что описывается, а не тому, как оно описывается.
Если вашей программе нужен словарь из 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, пути к каталогам и так далее. Они могут быть одинаковыми на вашем устройстве разработки и на производстве, но, вероятно, нет, и системные администраторы решат, как они будут выглядеть в производстве, а не как разработчики. Таким образом, вам нужен способ применения одной группы настроек на некоторых машинах и других настроек на других машинах - например, внешних файлов конфигурации (или настроек в базе данных и т. Д.)
Но я подчеркиваю, что просто поместить некоторые «данные» в «файл» - это не то же самое, что перенести их в конфигурацию. Помещение словаря слов в текстовый файл не означает, что вы хотите, чтобы пользователи (или ИТ-специалисты) изменили его, это просто способ облегчить разработчикам понимание того, что происходит, и, при необходимости, сделать случайные изменения. Аналогичным образом, размещение той же информации в таблице базы данных не обязательно считается экстернализацией поведения, если таблица предназначена только для чтения и / или администраторы БД не должны с ней связываться. Конфигурация подразумевает, что данные являются изменяемыми, но в действительности это определяется процессом и обязанностями, а не выбором формата.
Итак, подведем итог:
«Код» не является жестко определенным термином. Если вы расширите свое определение, включив в него предметно-ориентированные языки и все остальное, что влияет на поведение, большая часть этого очевидного трения просто исчезнет, и все это будет иметь смысл. Вы можете иметь не скомпилированный DSL-код в плоском файле.
«Данные» подразумевают информацию, которая принадлежит пользователю (-ам) или, по крайней мере, кому-либо, кроме разработчиков, и обычно недоступна во время разработки. Это не может быть жестко закодировано, даже если вы захотите это сделать. За возможным исключением самоизменяющегося кода , разделение между кодом и данными является вопросом определения, а не личных предпочтений.
«Мягкое кодирование» может быть ужасной практикой, когда чрезмерно применяется, но не каждый случай экстернализации обязательно представляет собой мягкое кодирование, и многие случаи хранения информации в «плоских файлах» не обязательно являются добросовестной попыткой экстернализации.
Конфигурация представляет собой особый тип Soft-кодирование , что является необходимым , поскольку знания о том , что приложение может понадобиться для работы в различных средах. Развертывание отдельного файла конфигурации вместе с приложением является гораздо менее трудоемким (и гораздо менее опасным), чем развертывание другой версии кода в каждой среде. Таким образом, некоторые типы программного кодирования действительно полезны.