移除硬编码值和防御设计与YAGNI

Question

首先介绍一下背景。我正在编写年龄->比率的查询。有7个年龄括号，所以查找表是3列(从“从”到“值”)，有7行。这些值很少改变--它们是法定税率 (第一列和第三列)，保持了3年不变。我认为，在没有硬编码的情况下存储此表的最简单方法是将其存储在全局配置表中的数据库中，作为包含CSV的单个文本值(所以"65,69,0.05,70,74,0.06“是如何存储65-69和70-74层)。比较容易解析，然后使用。

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

当与用户交谈时(他们现在直接使用查找表--通过查看硬拷贝)，他们的观点几乎是“费率永远不会改变”。显然，这实际上是不正确的--利率是三年前才创建的，在过去，“永不改变”的东西有改变的习惯--所以对于我来说，为了防御性地编写这个程序，我绝对不应该将查找表存储在应用程序中。

除了我觉得雅格尼。我正在实现的功能并没有指定汇率会发生变化。如果费率确实发生了变化，它们仍然会改变得太少，以至于维护甚至都不是考虑因素，而且功能实际上还不够关键，如果在速率更改和更新的应用程序之间出现延迟，那么任何事情都会受到影响。

我几乎已经决定，如果我对查找进行硬编码，就不会失去任何有价值的东西，而且我也不太关心我对这一特殊特性的处理方法。我的问题是，作为一名专业人士，我是否有正当理由作出这个决定？硬编码值的设计很糟糕，但是将这些值从应用程序中移除似乎违反了YAGNI原则。

编辑来澄清这个问题，我并不关心实际的实现。我担心我要么做一件快速的坏事，然后通过说YAGNI来证明它是正当的，要么我可以采取一种更防御性的、高度努力的方法，即使是在最好的情况下，最终也会带来很低的好处。作为一名专业程序员，我是否决定实施一个我知道有缺陷的设计，只是简单地进行成本/效益分析？

尽管所有答案都很有趣，因为我认为这取决于个人的设计选择，但我认为最好的答案是@Corbin's和@E.Z.哈特，因为它们提出了一些我在问题中没有考虑过的问题：

• “正确删除硬编码值”的错误二分法是将其移动到数据库，而不是通过使用硬编码“有效地应用YAGNI”。还有第三种选择，即将查找表放入应用程序配置中，这不会引起正确方式的开销，而且也没有YAGNI的效率。我们通常不局限于任何一个/或决定，然后它归结为一个成本/收益的决定。
• 代码生成可以减少将硬编码值移动到数据库的开销，并以某种方式删除我将CSV处理到表中的过度设计的决定。如果查找方法的基本需求发生变化，这可能还会增加生成代码的长期维护问题。所有这些都只会影响成本/效益分析，而且很可能，如果我有这种自动化，我甚至不会考虑像这样的硬编码。

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

Answer 1

您在开发过程中发现了一个缺陷。当做正确的事情(创建表、回购、回购测试、扁平化测试.)时，开发人员会找到绕过它的方法。这通常涉及做错误的事情。在这种情况下，很容易将应用程序数据作为应用程序逻辑来处理。不要这样做。相反，向您的开发过程添加有用的自动化。我们使用CodeSmith生成没有人想写的枯燥的样板代码。创建表之后，我们运行CodeSmith，它为每个表生成DAO、DTO和存根单元测试。

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

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

Answer 2

对于@Thorbj rn Ravn Andersen的回答来说，关键和扩展:将计算/查找保持在一个地方是一个好的开始。

你对YAGNI的防御性思维过程是一个常见的问题。在这种情况下，我建议再用两件事来通知它。

第一，用户需求是如何呈现的？他们是否规定了比率的可编辑性？如果不是，增加的复杂性是否是你可以为之付费的部分？(或者如果你在工作，你可以花时间去做其他工作吗?)如果是这样的话，那就一定去做，并提供合理的要求。

其次，也许更重要的是，面对立法上的变化，仅仅是可编辑性不太可能满足实际的要求。如果利率确实发生了变化，很可能会有一个削减日期，而一些在处理之前和之后必须发生。此外，如果同一界面必须进行任何形式的追溯索赔处理，则可能必须根据输入的生效日期而不是实际日期来查找正确的费率。

简而言之，我注意到一个实际的可编辑需求很可能相当复杂，所以除非或直到它被充实，否则简单可能更好。

祝好运

Answer 3

使实际查找成为库函数。然后，您可以在源代码存储库中看到使用该查找的所有代码，这样您就可以知道在费率变化时需要升级哪些程序。