只根据我目前的需求开发？

Question

我有一个名为Claims的服务，它有以下签名：

IClaimsService { EnsureClaim(claimType, userId) }

它查询数据库，以查看声明是否存在于我的任何角色中。

根据我目前的需求，我没有一个场景要求用户拥有一个以上的声明来做某件事情，但我认为我将在不久的将来需要它。(我刚开始做这个项目)

在我的服务中添加以下方法可以吗？

EnsureClaims( claimTypes, userId )

所以我可以将一系列的索赔类型传递给它。

如果我在我的服务中开发第二种方法，你认为有什么利弊？

请注意，EnsureClaim和EnsureClaims需要自己的查询，不会有任何类型的代码重复使用。所以我说的是开发新代码，自动化测试和代码评审。我说的不是大量的新代码。

Answer 1

在作出这样的决定时，有很多事情要考虑。一些你需要得到答案的问题包括：

• 您能花时间开发和测试当前未使用的代码吗？
• 它会增加额外的需求(比如额外的内存)吗？
• 在不久的将来，您真正需要这个特性的可能性有多大？
• 这段额外的代码是否需要为它所使用的任何版本重新编写，因为其他版本发生了变化？
• 测试是否需要随着产品在添加功能时和实际需要之间的演变而更新？
• 新代码是否会引入其他可被利用的点(安全漏洞)？
• 现在是否有可用的开发资产可用于添加将来无法使用的特性？

如果您最终添加了这个特性，您仍然需要进入测试阶段。

这通常会自己解析为“不，现在不要添加第二个服务”。

Answer 2

这似乎是在任何时候都可以很容易地添加的东西(特别是如果这个服务是新的，就其作为产品的生命周期而言，因为在这种情况下，重写整个代码块的成本可能很低)。

虽然添加对预期特性的支持是可以的，特别是当它们具有一定程度的确定性并得到很好的理解时(假设您在适当的情况下使用了类似于YAGNI的约束)，因为您说没有代码重用，我将留待以后使用。即使它不是大量的新代码，您可能最终会不必要地使事情复杂化，或者您可能会做出一些错误的假设，这可能会妨碍您以后的工作。

相反，更好的做法是确保使用claims服务(以及其他与索赔相关的内容)的代码不依赖于以下事实:它后面的代码检查单个索赔(即，它不是以依赖于此的方式编写的)，这样您以后就可以轻松地引入更改，而不会带来最小的后果。所以，检查一下，如果必要的话重构。