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