我不完全确定如何措辞，但我会尝试。
假设您在程序的某些部分中有一些设置，您 80% 确信您将永远不必再次修改。你怎么知道在可变代码上画线？您知道将设置一直保存到用户定义的 XML 文件是多余的。但是，您也知道，稍后可能需要更改这些设置的可能性为 20%，因此在橡胶与道路相遇的地方对其进行编码也不是最佳选择。
我想我想问的是，你应该让你的程序容易改变抽象树多远？
许多示例之一是手动为网站编写 HTML 代码，而不是让程序自动生成它。直接编写 HTML 代码不会花费太多时间。编写程序以自动生成 HTML 代码需要更长的时间。
这是一个很好的问题，但没有绝对的答案：
正如爱因斯坦所说：
让事情尽可能简单，但不要简单。
简单是相对的。对设计中抽象层的数量做出最佳决定是伟大架构师的伟大之处。一个好的架构师应该总是评估特定的情况并做出最好的权衡。没有银弹。
我试一试，我的理念如下：
1 - 保留一个配置文件和解析器类/函数，它们非常简单，尽可能简单，让您高枕无忧，无论何时需要它，您都可以得到它，而无需实例化一个可笑的过度膨胀的 XML 处理配置文件解析器。我的配置文件如下所示：
DBHostname -> XX.XX.XXX.XX
DBUsername -> foomonger
DBName -> fooDb
DBPassword -> xxxxx
ImageUploadsDir -> /uploads/images/
...
我使用我的白痴朋友 ConfigHelper 生成的静态辅助方法（小型应用程序）或单例实例（大型 MVC 驱动的应用程序）从中提取我需要的东西，他太笨了，他不知道如何产生开销。
在我的平均工作日中，我多次遇到这种困境：我应该把它放在 config.txt 中还是应该让它成为一个类常量？我的回答是我只是不知道——直到很久以后。如果事实证明它需要放入配置文件中，那么没有什么能比一个体面的 IDE 更好了，它具有稳定的“在项目中查找和替换”实现以更改引用。
3 - 当开发涉及测试服务器然后部署到生产时，配置文件消除了应用程序部署的噩梦 - 没有真正实用的替代方案。在我理解的世界中，不同机器上的不同数据库实例具有不同的 IP。
许多示例之一是手动编写网站的 HTML 代码与让程序自动生成它
这是真的。虽然我们作为开发人员喜欢构建机器，但我们往往会浪费大量时间来构建机器来构建我们最初打算构建的机器。虽然这可能非常令人满意，但根据经验，我可以大胆地说，在大多数情况下，您拥有的机器越多，您必须支持的系统就越多，故障点就越多，您从企业主那里得到的打击就越多——而且这不好玩。此外，您往往会遇到中间 HTML 生成器无法生成所需输出的情况。那么你会怎么做，浪费时间修复生成器中的错误，浪费时间设计一个巫毒的解决方法，或者只是手写 HTML？这确实取决于特定情况，但我更喜欢后者。
有点咆哮，但希望它至少有助于回答你的问题。
在过去的四年里，这只老狗学会了 TDD 的新把戏。即使我没有时间做“真正的”TDD，我也会假装我做。
所以我总是写重复的代码。没关系，因为我总是在之后重构它。这是编写代码过程的一部分，而不是稍后再做的事情。由于我遵循了 TDD 并且只编写了必要的最少代码，并且由于我有自动化测试证明该代码有效，因此如果我发现重复，我可以放心地重构它，因为我知道我会再次运行我的测试在重构期间和之后。这将再次证明我没有破坏任何东西。
这样，我不会推测代码是否会被重用——在重用之前我从不重构。由于它是根据实例的需要在每个实例中创建的，因此我知道代码的调用者并没有因为使代码通用的愿望而扭曲。调用者，包括单元测试，都是为了满足他们的直接需求而编写的。单独的重构过程可以处理更广泛的不重复代码的需求。
两点：
您的问题是针对实际代码设计的，而不是将变量放在配置文件中还是常量中。我同意关于这些方面的其他答案。
但是关于是否写通用代码...
以我的经验，如果您专门编写代码来处理手头的任务，您只会发现自己在将来的某个时候编写类似的代码。好吧，如果你真的只做一次任务，没关系。但我发现大多数时候情况并非如此。
如果您发现自己重复一项任务，那么您应该退后一步，考虑以一般方式自动化它需要什么。
还要检查是否有人还没有这样做。如果他们没有，请考虑发布您的代码，无论它多么小或多么粗糙。有人可能会免费为您改进它。
80% ? 硬编码还不够好，将其放入配置文件中。
100% ? 一个常数可能会。