如何组织代码以便我们可以移动和更新它而无需编辑配置文件的位置？

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”，似乎只是一种额外的灵活性，没有额外的不便。它确实要求我们在一些包装脚本中定义这个常量，但如果没有定义，我们可以回退到旧方法。如果严格应用该方法，结果将是服务器文档根目录中所需的所有脚本将只是定义配置目录的简单包装器。这看起来很酷。人们经常说，将重要代码放在文档根目录之外更安全。