将来的验证码

在我工作的地方，开发人员总是告诉我“为了将来以防万一”或“我认为这样做是个好主意，因为他们可能有一天会想要它”。我认为很高兴他们能积极地预见未来的变化，但我不禁认为这是不必要的，并且冒着编写可能永远不需要的代码的风险，因此徒劳无功（我还认为有些开发人员只想尝试一些东西）全新的）。如果您只是编写良好，干净的组织代码，则用于将来证明的参数是否无效？

首先，有一些事情需要澄清：

• 将来的证明不会增加任何东西。
• 将来的证明是确保您可以轻松添加代码/功能而不会破坏现有功能。

这意味着编写“面向未来的”代码可确保以松散耦合的方式编写代码，既足够抽象，又可以确保代码不会完全隐藏抽象级别，因此总有一种方法可以进入较低的抽象级别如有必要。

编写面向未来的代码本身就是一门艺术，并且与SOLID规范紧密结合在一起，以进行组件版本控制，关注点分离，功能分层和抽象性。将来的证明与提前添加功能无关，而是通过对现有代码/库的良好设计，确保将来可以不间断地添加功能。

我的2c

不要编写长时间不会使用的代码。这将是无用的，因为它很可能无法满足当时的需求（根据定义，您还不知道）。

使代码更健壮，以应对意外的问题，从而实现正常恢复或快速失败，但不要编写代码以备将来使用。

确保测试的一种好方法是使用测试驱动的设计和开发。测试用例源自规范和用例。所有代码都必须通过测试。不应编写不需要的代码。通过这种方式，很容易确定是否需要它。

重要的是要意识到使代码成为未来的证明，以及在将来需要时编写代码是两件事。前者对于良好的应用至关重要，而后者通常不是良好的编码实践。

• 对我来说，将来对代码进行校对时，将以一种能够与不断发展的技术进行交互的方式编写代码。这涉及模块化代码，以便应用程序的每个部分都可以独立于整个应用程序的语言和技术进行交互。一个很好的例子是使用XML或JSON在应用程序的不同部分之间传递数据。无论技术如何发展，它很可能始终能够读取XML和JSON。

• 与上述类似，通过SOAP或REST API公开应用程序的一部分可以实现类似的目的。无论技术如何发展，您都不必重新编写应用程序的每个部分，因为新技术仍然可以与旧技术进行通信。

• 在需要编写代码的时候，我认为这非常危险，因为该代码可能很少或根本没有测试。

因此，无论如何，要使代码成为未来的证明（NASA仍使用Fortran发送太空飞船），但不要“以防万一”地编写代码。

考虑一下您在生产环境中启用了一段代码的时间有多长，然后想：“谢谢我两年前写的代码！”。

代码应易于修改/扩展。不要添加不需要立即使用的代码，因为这给人一种非常虚假的安全感，并且在不断变化的需求中浪费了开发/测试资源。

许多其他答案都解决了较大的设计问题，或者说是抽象的。如果您认为在未来会发生什么样的条件，你可以定义一些明确的技术来帮助面向未来的代码。

主要是认为将来有人会尝试向代码中添加功能，或者尝试在其他地方重用您的代码。他们还可能尝试修复代码中的功能。显然，拥有良好的原始代码是必需的起点，但是也可以执行一些特定的技术。

防御性编程：进行输入检查，超出当前应用程序的实际需求。每当您调用API时，请务必确保检查其输入是否符合您的期望。将来人们会将新版本的代码混合在一起，因此错误的范围和API返回的内容将与现在有所不同。

消除未定义的行为：许多代码都具有从无到有的进化行为。某些输入组合会导致某些输出，但实际上并没有人真正打算这样做。现在不可避免地会有人依靠这种行为，但是由于没有定义，因此没人会知道。任何试图将来改变行为的人都会无意间破坏事情。立即使用安全检查，并尝试删除/阻止所有未定义的代码使用。

自动化测试套件：我相信您可以找到有关单元测试需求的书面卷。但是，关于将来的证明，这是允许某人重构代码的关键点。重构对于保持干净的代码至关重要，但是如果缺少一套很好的测试，您将无法安全地重构。

隔离和隔离：封装和适当的模块化是一个很好的设计原则，但是您还需要超越这一点。您经常会发现需要使用可能会遇到问题的库，API或产品。可能是由于质量问题，许可问题或作者的不断发展。在这些情况下，需要花费更多时间在您和此代码之间放置一层。将API缩减为所需的尺寸，因此耦合度很低，将来可以轻松更换。

好的，干净的，组织良好的代码可以确保未来的更改，因为它使更改和添加更容易正确实施。

“面向未来”充其量是指“松耦合设计”。80％的人说“未来证明”时表示“灵活”。有时他们会说这听起来很酷。但是至少他们按时交付了一些有用的东西。

最糟糕的是，“未来证明”毫无意义。20％的时间是浪费时间研究替代技术而不是简单地提供某些东西的借口。他们没有交付任何东西（或者他们交付的东西对于眼前的问题来说太复杂了。）

有两种情况。

1. 坚定不移的远见。实际上可以准确地预测未来。在这种情况下，请运用这种强大的洞察力来将来验证代码。更好的是，运用坚定的远见来预测市场趋势并提前退休并停止编码。

2. 一种是“驱动”未来。就是说，有一种新技术准备在将来部署，这将需要重写现在交付的东西。奇怪的是没有先部署这种很酷的未来。

   我们必须交付项目“ A”，因为知道项目“ B”将导致立即重写“ A”。仅在这种情况下，我们才有可能将来证明“ A”。

亚格尼 = 你不需要它。

您的直觉是正确的：它们的代码是多余的，增加了维护和测试的负担，并且在没有具体业务价值的事情上浪费了时间。

另请参阅：镀金。

忽略问题的标题，而是坚持“把东西放进去，因为某天可能有人想要”的要点...

答案是不。决不。不要编写您今天不需要的代码。原因如下：

1. 该程序现在比需要的要复杂。
2. 您可能永远不需要此功能，因此浪费了时间。
3. 您不知道将来有人问该功能的要求是什么。因此，您必须找出答案并进行修改。

我认为第一点是最重要的。如果您曾经使用过为不同客户充斥通用代码的系统，或因不需要而充斥着大量功能，那么您将知道由于以下原因，维护或扩展功能需要花费额外的时间和精力：那。因此，不惜一切代价避免。