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

Question

Проблема, которую я считаю, заключается в том, как написать код, который может легко узнать местоположение требуемого конфигурационного файла и, тем не менее, переносится без каких-либо изменений из среды в другую. Мы не хотим редактировать местоположение файла конфигурации, чтобы адаптировать код к каждой новой среде, скажем, каждый раз, когда мы перемещаем код из среды разработки в производство. Метод не должен полагаться на ресурсы, которые не являются общедоступными, такие как доступ к пользовательским переменным среды или доступ к определенному каталогу. Например, может показаться, что использование DOCUMENT_ROOT в качестве базового расположения для файла конфигурации - это путь, но это не универсально. Во-первых, в среде командной строки DOCUMENT_ROOT не имеет смысла. Во-вторых, программисту может быть предоставлен доступ только к подпапке только DOCUMENT_ROOT. Другое требование состоит в том, что файл конфигурации может зависеть от значений, известных во время выполнения, например, пользователя, который вызывает приложение, как в этом вопросе How to load a config file based on user selection from "unknown" location.

Вопрос не в том, что наилучшее расположение файла конфигурации в определенных средах, например Location to put user configuration files in windows. Программистам все равно нужно было бы найти лучшее место, чтобы конечные пользователи могли легко найти файл конфигурации. Вопрос в том, как это местоположение, независимо от того, что оно есть, даже если оно зависит от значений, известных во время выполнения, может передаваться в код переносимым образом.

Answer 1

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

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

В Linux у них есть папка/etc для файлов конфигурации. Таким образом, понятие универсально согласованного стандарта в очень большом контексте уже существует. Это та же идея, что и предлагаемая здесь, за исключением того, что она является одной и той же константой для всех машин, и кто-то может не иметь доступа к этому уровню сервера. Более того, мы теряем возможность иметь разные конфигурационные каталоги для разных сценариев оболочки. Разрешить универсальный стандарт быть постоянным именем, например, 'CONFIG_DIRECTORY', вместо постоянной константы '/ etc', выглядит просто дополнительной гибкостью без каких-либо дополнительных неудобств. Это требует, чтобы мы определили эту константу в некотором сценарии оболочки, но мы можем вернуться к старому подходу, если он не определен. Результат, если подход строго применяется, будет заключаться в том, что все сценарии, требуемые в корневом документе сервера, будут только простыми оболочками, которые определяют каталог конфигурации. Это кажется крутым. Часто люди говорят, что безопаснее иметь важный код вне корня документа.