与YAGNI相比，删除硬编码的值和防御性设计

首先介绍一下背景。我正在从“年龄->费率”中查找代码。有7个年龄段，因此查找表是3列（From | To | Rate）和7行。这些值很少更改-它们是已保持3年不变的立法费率（第一列和第三列）。我认为存储该表而不对其进行硬编码的最简单方法是在数据库中的全局配置表中，因为包含CSV的单个文本值（因此“ 65,69,0.05,70,74,0.06” 65-69和70-74层）。比较容易解析然后使用。

然后，我意识到要实现这一点，我将必须创建一个新表，一个要包装它的存储库，用于仓库的数据层测试，围绕将CSV展开到表中的代码的单元测试以及围绕查找本身的测试。所有这些工作的唯一好处是避免对查找表进行硬编码。

与用户交谈时（当前他们直接使用查找表-通过查看纸质副本）时，人们几乎认为“费率永远不会改变”。显然，这实际上是不正确的-费率是三年前才创建的，过去，“永不改变”的习惯已经改变了-因此，对于我来说，应该进行防御性编程，我绝对不应该在其中存储查找表应用程序。

除了我想YAGNI的时候。我要实现的功能未指定费率会改变。如果费率确实发生变化，它们仍将变化得很少，以至于甚至不需要考虑维护，并且该功能实际上并不十分重要，以至于如果在费率变化和更新的应用程序之间存在延迟，任何事情都将受到影响。

我几乎已经决定，如果我对查询进行硬编码，就不会失去任何价值，而且我不太担心我对这一特定功能的处理方式。我的问题是，作为专业人士，我是否可以合理地证明这一决定？硬编码值是不好的设计，但是麻烦从应用程序中删除值似乎违反了YAGNI原则。

编辑为了澄清这个问题，我不关心实际的实现。我担心自己可能会做出快速，糟糕的事情并通过说出YAGNI来证明其合理性，或者我会采取一种防御性更高的努力方法，即使在最好的情况下，最终收益也很小。作为一名专业程序员，我实施我知道有缺陷的设计的决定是否仅仅取决于成本/收益分析？

编辑虽然所有的答案都非常有趣，因为我认为这归结为个人的设计选择，我认为最好的答案是@科尔宾的和@EZ哈特为他们带来了的事情，我没有在这个问题考虑：

• 错误的二分法是通过将其移动到数据库来“正确删除硬编码的值”，而不是使用硬编码来“有效地应用YAGNI”。第三种选择是将查找表放入应用程序配置中，这不会产生正确方法的开销，而且没有YAGNI的效率。我们通常不限于任何一个或一个决定，然后可以归结为成本/收益决定。
• 代码生成可以减少将硬编码值移动到数据库的开销，并且还可以消除我过度设计的决定，即将CSV处理到表中的决定。如果查询方法的基本要求发生变化，则可能还会对生成的代码造成长期维护问题。这一切都只会影响成本/收益分析，而且如果我拥有自动化功能，那么我什至都不会考虑对这种东西进行硬编码。

我将@Corbin的答案标记为正确，因为它改变了我对开发成本的假设，并且我可能会在不久的将来向我的军械库中添加一些代码生成工具。

您发现开发过程中存在缺陷。当做一件正确的事（创建表，回购，回购测试，扁平化测试...）很痛苦时，开发人员将找到解决之道。这通常涉及做错事。在这种情况下，您很容易将应用程序数据视为应用程序逻辑。不要这样 而是在您的开发过程中添加有用的自动化。我们使用CodeSmith生成没人想编写的无聊的样板代码。创建表后，运行CodeSmith，它会生成DAO，DTO，并为每个测试存根单元测试。

根据您使用的技术，您应该有类似的选择。许多ORM工具将根据现有架构生成模型。Rails迁移的方向相反-模型表。动态语言的元编程在消除样板代码方面特别强大。如果您具有复杂的多层应用程序，则必须付出更多的努力才能生成所需的一切，但这是值得的。不要让这种感觉“哇，这是脖子上的疼痛”阻止您做正确的事。

哦，不要以需要额外处理（CSV）的格式存储数据。这只会增加需要您注意和测试的额外步骤。

要取消和扩展@ThorbjørnRavn Andersen的答案：将计算/查找放在一个位置是一个好的开始。

您对防守与YAGNI的思考过程是一个常见问题。在这种情况下，我建议您再注意两件事。

首先-如何提出用户要求？他们是否指定了费率的可编辑性？如果不是，增加的复杂性是否属于您可以负担的费用？（或者，如果您在工作人员上，您可以将时间花在其他工作上？）如果是这样，那么一定要继续进行并交付合理的要求。

其次，也许更重要的是，面对法律的变更，仅凭可编辑性就不可能满足实际要求。如果费率确实发生变化，当费率发生变化时，很可能会有过渡日期，并且必须进行一些前后处理。此外，如果该接口必须随后进行任何类型的回溯索赔处理，则可能必须根据条目的生效日期而不是实际日期来查找正确的汇率。

简而言之，我要指出的是，实际的可编辑需求可能非常复杂，因此，除非或直到充实它，否则简单性可能会更好。

祝好运

使实际的查询成为库函数。然后，您可以使用源存储库中的该查找来查看所有代码，因此，您可以知道在更改费率时需要升级哪些程序。

让我看看我是否正确回答了您的问题。您有2种选择来实现功能：要么对值进行硬编码并且功能易于实现（但是您不喜欢硬编码部分），要么就付出很大的努力来“重做”许多已完成的事情这样您就可以以干净的方式开发功能。那是对的吗？

我想到的第一件事是“了解良好做法的最重要的事情就是知道什么时候没有这些就会变得更好”。

在这种情况下，付出的努力非常高，因此您可以以一种干净的方式进行操作，这种变化产生附带影响的机会很大，而您获得的回报却很小（正如您所解释的那样，似乎不会更改）。

我将使用硬编码方法（但要使其在将来变得灵活），并在将来更改此速率的情况下，利用此机会来重构代码的所有不良设计部分。因此，可以正确估算时间和成本，并且更改硬编码值的成本将降至最低。

这就是我的方法:)

这是一个直到改变都不会改变的项目。不可避免的是它将改变，但是时间可能还差得远。

您的辩解是正确的。目前，客户并未要求能够轻松更改这些费率。因此，YAGNI。

但是，您不需要的是访问您的费率并解释分散在整个代码库中的结果的代码。好的OO设计将使您将费率的内部表示封装在一个类中，并且仅公开使用数据所必需的一种或两种方法。

您将需要使用这种封装来防止复制和粘贴错误，或者当您需要更改内部表示形式时，必须对使用费率的所有代码执行重构。当您采取最初的预防措施时，更复杂的方法可以是简单的交换并替换为功能更强大的版本。

此外，向客户指出当前设计的局限性。告诉他们，为了维护计划，您对值进行了硬编码-这需要更改编码才能更新它们。这样，当他们意识到由于新法规而导致的未决费率变化时，他们可以选择简单地更新查找表或在那时执行更复杂的更改。但是把这个决定放在他们的腿上。

分割差异并将速率数据放入配置设置中。您可以使用已经拥有的CSV格式，避免了不必要的数据库开销，并且如果有必要进行更改，那么客户应该能够进行更改而无需重新编译/重新安装并且不会弄乱在数据库中-他们只能编辑配置文件。

通常，当您在两个极端之间做出选择（违反YAGNI与动态数据进行硬编码）时，最佳答案是在中间。当心错误的二分法。

假设所有配置都在文件中；如果它像注册表一样困难，您可能应该忽略此建议:)

我认为存储该表而不对其进行硬编码的最简单方法是在数据库中的全局配置表中，因为单个文本值包含CSV（所以“ 65,69,0.05,70,74,0.06” 65-69和70-74层将被存储。

刚刚创建了一个数据库表。（您想将整个表存储在一个表中，您疯了吗？）

该表需要2个字段，而不是3。年龄和比率。下一行包含较高的值！您正在不规范化甚至不知道！

这是Sql，用于获取67岁年龄段的人的价格。

Select * from RateTable where Age in (Select max(age) from RateTable where age <=67) 

不要打扰维护屏幕，因为它不在范围内。如果他们稍后要求，则发出更改请求并执行。

编辑：正如其他人所说，保持代码集中在整个Rate结构变化的情况下，将速率集中。

我同意给出的大多数答案。我还要补充一点，与应用程序其余部分的一致性很重要。如果这是唯一的代码的地方已经硬编码值恐怕也会惊讶的维护者。如果它是一个大型，稳定的代码库，则尤其如此。如果这是您维护的小程序，那么决定就不那么重要了。

我读过一个著名的敏捷/ OOP专家（例如Dave Thomas或Kent Beck或其他人），他们记忆犹新，他们说他们的代码重复经验法则是两次，而且只有两次：第一次重构时，请勿重构您一生只能写两次。但是第三次

因为您在质疑YAGNI，但这并不能完全解决问题，但我认为这表明了敏捷规则的一般灵活性。敏捷的目的是适应形势并向前发展。

函数中的硬代码。

• 当价值改变时，您可以再次向客户收费
• 值更改时，表格格式必须更改，做CSV会浪费时间
• 易于实施，在当前合同中被预算的机会更高
• 可以轻松找到何时需要更新