我应该为将来的更改准备我的代码吗？

Question

我是否应该为可能的/预测的未来更改准备我的代码，以便即使我不知道这些更改是否随时都需要更容易进行这些更改？

Answer 1

我很可能因为这个而对我的看法感到害怕，但我来了。

虽然我多年来一直在阅读这些理想主义文章，并且参加过多的研讨会和讲座，并且直言不讳地说明了这一点的好处，但我在脑海里也有类似的问题。这种思路会导致代码的大量过度设计，在设计，开发和测试估算中增加许多工时或更多，增加成本和开销，而实际情况并非如此。你有多少次重复使用你的代码或库。如果要通过众多项目在很多地方使用，那么你应该这样做。

然而，大部分时间情况并非如此。您经常会发现，只有当您确实知道要再次使用它时，才能更经济地（时间和金钱）重构您的代码以便重用和配置。其余的时间都会失去真正的好处。

这不是，我再说一遍，不是写一个草率，设计不佳，记录不完整的代码的借口。这应该是一个完全根深蒂固的基础，你无法打破它，但写一个类重用是一种浪费，因为它永远不会被重用。

这有明显的例外。如果您正在编写第三方库，那么显然情况并非如此，重用和扩展应该是您设计的关键。某些其他类型的代码应该是显而易见的重用（日志记录，配置等）

我在这里问了一个类似的问题Code Reusability: Is it worth it这可能有所帮助。

Answer 2

在合理范围内，当然如果没有太大的努力。

我认为你不能总是应用这个，因为它可以让你过度设计所有东西，然后它需要太长时间而你赚不到多少钱。考虑客户端实现某些东西的可能性，现在准备它需要多少额外费用以及以后节省多少时间。

如果需要大量工作，但省钱有意义，可以向客户提出。

我似乎与这里的很多人意见不一，他们总是说 - 但我已经看到很多事情都付出了努力，使未来的功能很容易实现......但他们从未见过实现。如果客户没有支付使该功能易于实施所花费的时间，那么就可以直接从您的底线获得资金。

编辑：我认为相关的是指出我来自代理商环境。如果您正在为自己编写代码，那么您可以更加确定地预测未来的开发，因此在更多情况下执行此操作可能是可行的。

Answer 3

YAGNI。

http://en.wikipedia.org/wiki/YAGNI（*由友好编辑插入:-) *）

修复你今天写的那些可怕的代码中的错误。

到时候重构。

Answer 4

如果你在重构友好的语言中工作，我会说不。 （在其他语言中，我不确定）

你应该尽可能地使你的代码成为loosley耦合，并保持尽可能简单。保持特定，不要推广到未知的用例。

这将使您的代码库为未来的事情做好准备。

（坦率地说，对未来的大多数期待都倾向于完全偏离标记，不保证今天编码）

编辑：这还取决于你在做什么。为外部用户设计apis与为公司开发Web应用程序不同

Answer 5

是的 - 做得少。

您不会知道代码的未来要求。对未来的最好准备是不来实现任何不需要的东西，并且具有良好的单元测试覆盖率，无论你做什么实现。

Answer 6

代码中的

可伸缩性是您应该始终考虑的一件事。

您今天花在维护可扩展解决方案上的时间越多，实际扩展后您将来花费的时间就越少

Answer 7

预测或非常可能的变化 - 是的，通常记住它们是好的。

“考虑宇宙中可能发生的任何事情” - 没有。你不知道会发生什么，试图掩盖未知的一切只是过度工程。

Answer 8

请记住大多数代码将被更改/重构。如果您知道必须在下周内更改您的代码，请做好准备。但是默认情况下不要开始使所有东西都可以交换和模块化。仅仅因为“可能在未来”你不应该创建一个框架，如果现在有三行代码完成这项工作。

但请三思，如果系统背后的重构很困难（数据库）。

Answer 9

我在为我工作的公司编写的一年中学到的一件事，无论你认为它有多完美，都会回来困扰你的更新，或者需要改变因为客户X突然决定不喜欢它。

现在我正在使我的代码具有高度可定制性，所以当那一天进行一些调整时，它会立即准备就绪，我可以继续我的工作。

Answer 10

总之，是的。

再说一遍，你应该总是让你的代码尽可能可读，包括注释，并且总是假设在将来的某个时候，你会被要求或其他人修改代码

如果将来有人遇到一段代码，没有注释，没有格式化，没有表明它做了什么或应该做什么，那么他们会永远诅咒你：）

Answer 11

不，永远不会。编写易于重用/重构的优秀代码，但准备好一半考虑的增强功能，是imo，过早优化的兄弟;你可能最终会做一些你不需要的事情，或者在未来的某个日期将你推向某个（可能是非最佳的）设计路径。正如mfx所说，现在做最低要求并对所有内容进行单元测试;它使扩展代码变得轻而易举。

Answer 12

你不能设计一个未知的（未来），正如其他人所说，试图建立一个灵活的设计很容易导致过度工程，所以我认为最好的务实方法是考虑避免那些事情您知道将来会更难以维护您的代码。每次做出设计决定时，只要问问自己将来是否更难改变事物，如果是这样，你将采取什么措施来限制问题。

明显会导致问题的事情：

• 分散的配置信息 - 您需要能够轻松地检查和更改此内容
• 未经测试的代码 - 您需要测试才能自信地进行更改
• 存储和输出关注核心逻辑 - 如果仅用于测试，您将切换数据库实例和输出格式
• 复杂的架构 - 您需要有一个清晰的系统心理模型
• 需要手动干预或更新以使其保持运行的安排

Answer 13

我不会改变我的准备，为未来未知的功能做准备。

但我会重构以获得当前问题的最佳解决方案。

Answer 14

是的，始终考虑您的代码将来可能需要发展的位置。在我正在进行的当前项目中，有数千个文件，每个文件中只有一个文件至少有一个版本。即使不考虑错误修复，大量修订也是为了让其他软件功能让路。

Answer 15

  

平衡努力与   好处是设计的技巧。

并非所有代码都需要灵活。有些事情不会改变。

没有浪费精力。找到合适的部分来专注于。

棘手。

Answer 16

这非常重要。它需要做得很好，但需要经验。

如果我在实施典型的需求变更后计算编辑次数（通过“diff”），则10-50这样的数字很常见。

如果我对其中任何一个犯了错误，我插入了一个错误。

所以个人而言，我总是试图设计保持这个数字。

我还尝试在代码中留下如何进行预期更改的说明。如果我维护代码，如果前作者也这样做，我真的很感激。

Answer 17

是的，但只能编写可维护的，易于重构的代码。

你绝对不应该猜测未来可能需要什么。这些努力不仅对你目前的目标毫无意义和浪费时间，而且在未来的任何变化显而易见时往往会适得其反。

Answer 18

要遵循的两个简单原则：

1. KISS
2. 始终避免依赖

这是一个好的开始

Answer 19

我发现最近我在测试驱动开发中听到了一些内容。谈论它的人已经观察到，虽然最初总是编写单元测试并考虑如何编写代码以使其可测试可能有点烦人，但事实证明，在某些时候它开始自然而然地开始写测试友好代码。

关键在于，如果你总是考虑到可修改性，那么你最终可能会通过反射来做或多或少，从而使编写额外代码的开销非常小。如果你能够达到一个高质量，可扩展的代码是你自然而然的状态，我认为这肯定是值得的初始成本。不过，我仍然相信你必须适度，有时候这对某个特定的顾客来说是不对的。

Answer 20

显而易见的答案是肯定的。但更重要的问题是如何！

正交性，可逆性，灵活架构，解耦和元编程是解决此问题的一些关键字。查看“The Pragmatic Programmer”

的第2章和第5章

我发现设计“改变容纳”架构通常比尝试指定可能（或可能不会）发生的特定更改更好。不过，问一下“将来会发生什么变化？”，然后抵制过早实施可能不必要的功能的诱惑，而不是在创建应用程序架构时考虑到这些可能性，这是一个很好的练习。

Answer 21

您所描述的是成为优秀开发人员的重要组成部分。

参见 On Writing Maintainable Code

Answer 22

用两个词说：是的，永远。