您的应用程序的哪些部分没有编码？我认为最明显的例子之一就是数据库凭证——硬编码被认为是不好的。在大多数情况下，很容易决定是否要外部化或编码。对我来说，规则很简单。如果出现以下情况，应将应用程序的某些部分外部化：
你有什么要补充的吗？
这与这个关于 spring cfg的问题有点相关。Spring 配置对我来说似乎不太明显，因为在我的实践中，除了开发人员之外，任何人都不会修改它。而外化的道路可以带你走很远，到整个项目都被“配置”，而不是编码——那么在哪里停下来呢？
因此，请根据您的经验在此处发布一些示例，当您从配置而不是编码的东西中受益时 - 比如 spring 中的依赖注入配置等。如果您使用 spring - 在不重新编译的情况下多久更改一次配置？
在应用程序的不同部署之间需要有所不同的任何内容。也就是说，任何特定于环境的东西。
示例包括：
您的应用程序使用的任何信息都是“数据”，并且可能会根据其安装位置而改变。像：
除了明显变化的东西（路径、服务器、端口等）之外，有些人认为您应该能够轻松更改任何可能合理更改的内容，例如，假设您有一个在业务逻辑上运行的通用引擎（a规则引擎）。
然后，您将在“配置文件”上定义规则，最终不亚于使用 DSL 而不是通用目的语言进行编程。好处是它更接近域，因此更容易和更易于维护，并且您可以轻松更改原本需要新构建的东西。
这背后的主要论点是，你认为永远不会改变的事情最终总是会改变，所以你最好做好准备。
想到路径和服务器名称/地址..
我还将添加加密密钥（它们本身应该被加密）......
基本上，经验法则是应用程序在进行常规功能操作之前需要的信息，它必须手头有数据（即本地和未联网）。
请注意，此数据不应该是动态变化的或大量的，否则它应该在数据库中。
我同意你的两个条件，这就是为什么我：
员工的电子邮件/姓名，因为员工可以来去匆匆……（不过，您通常应该尝试将他们排除在应用程序之外）
配置文件应包括：
最后一个有点开放，但非常重要。我发现预见客户将来可能想要更改的变量非常有用。如果更改不频繁，我或他们可以编辑配置文件。如果它变得很常见，那么将选项添加到 GUI 中是微不足道的，它不是硬编码的。
我使用 Spring 连接没有 GUI（事务开关）的 J2SE 应用程序中的所有 bean。这样我就很容易在每个部署中拥有不同的配置（我们在不同的国家运行这个东西），而不必编写任何不同的代码。当我使用普通 JDBC（或 Spring JDBC）时，我喜欢的另一件事是与代码分开管理所有 SQL 语句。就像在属性文件或 XML 或其他东西中一样，有时甚至作为将使用该语句的 bean 中的字符串属性（当只有一个 bean 将使用该语句时，例如 DAO）。
对于 Spring 应用程序，我实际上区分了两种类型的配置：
项目外部化为“部署时间”或“环境特定”的属性文件：服务器 IP/地址、文件系统位置等
Spring XML 配置可以做很多事情，比如指示整体应用程序结构，通过 AOP 应用行为等。
我打算使用spring JDBC或者vanilla JDBC进行数据持久化，这里我们决定将Java代码中的所有SQL都外部化，这样在SQL查询调优和优化方面可以更好地处理，我们不需要打扰爪哇代码。