代码实际上应该具有多大的可扩展性？

Question

我刚刚开始一份新工作，我的新老板跟我谈过的一件事就是代码长寿。

我总是编码使我的代码具有无限的可扩展性和适应性。我想如果有人将来要改变我的代码，那么应该很容易做到。

但我从来没有真正了解未来应该走多远。

所以我的新老板告诉我，在未来3年内不要为编码而烦恼，他的理由是技术改变，程序到期等等。

起初我有些吃惊，认为他是一个打击工作，但我想的越久，我就越热衷于这个概念。

是否有其他人对您应该编写代码的未来有何意见？

Answer 1

要实现的难点之一就是可扩展性。作为老板，当我分配一个2小时的任务时，我真的很恼火，三天后他们还在继续工作，因为他们认为它应该更具可扩展性，所以他们在配置文件和列到表格中添加了条目更改4或5个其他对象以适应它，现在安装文档已过期，部署脚本必须更改，测试人员必须在一两天内尝试所有组合和排列，以便我们知道代码是工作。但是，当其他人通过对所有内容进行硬编码，即使是发送给它的电子邮件地址，将其分为两个小时的任务时，我也非常恼火，并且当团队的其他成员抱怨时，我不明白。

如果有一个简单的硬性规则，那么在他们第一次编译代码的那天，每个人都可以成为高级程序员。它需要经验和判断，这可能是你将获得的最重要的判断。你知道如何获得良好的判断力吗？经验。你知道如何获得经验吗？判断力不好。

Answer 2

您应该按照规范进行编码，仅此而已。如果规格规定了30年，则代码为30年。如果规范规定3个月，则同样适用。

请记住，你也应该为自己的理智编码。您创建的所有代码应该实现3件事：

• 可替换的代码 - 在我看来，这只是一个好习惯。您编码的可替换性越强，您生成的代码就越好。这提供了一种相反的情况 - 你制作代码的可替换性越多，你自己创造的价值就越高。

• 生效的代码 - 重用，重用，重用。

• 代码应该写得很好 - 我不需要解释这个问题。

Answer 3

如果您真的想要一个持久的计划，请拍摄以确保您的日期可以处理过去2038（这是下一个“Y2K”）。

除了日期之外，从现在开始一年的编码是如何准确的，而不是从现在开始的十年？您可以编写可维护的代码，也可以不编写代码。您无法确切地指定更改“到期”之前的时间。

我想有人可能会争辩说他们语言的下一个标准会弃用方法Foo，但是如果一个方法将被弃用，那么代码质量和可维护性实际上比编码未来更重要日期

Answer 4

编码很好，只查看下一个可交付成果。编写良好的代码是无限可重构/可扩展的，无论是否记住这一点。编写得很糟糕的代码很少是可扩展的，实际上就是这样。

Answer 5

如果您遵循敏捷方法论，那么您应该只是编码当前的问题。这也被称为YAGNI（你不需要它）原则。

这个想法是你不知道即将发生什么，所以没有必要为它编码。

但是，我不认为这是特别明智的做法。

即使您处于敏捷环境中，您也可以了解您希望代码能够在线下进行多次迭代，因此应该编写代码。

虽然如果您正在编写“杀手”应用程序，程序会过期并且技术会发生变化，但它会持续超过3年。

Answer 6

每当我编码时，我都会问自己......

需要它吗？如果你不需要它，那你为什么编码呢？

我发现它有助于防止我添加不必要的代码。不必要的代码是一种消耗。它需要一些时间远离其他活动。它增加了代码大小和复杂性。它将$$$添加到项目中 - 特别是如果代码库必须通过认证过程。

Answer 7

在设计代码时，您应该记住可能的扩展方式或可能需要新功能的方法，并且您应该努力使其足够模块化以便可以添加新功能。如果有一个决定会使一个决策变得更加灵活或可扩展，而另一个决策会使其变得更加严格，如果在更灵活的情况下几乎没有成本，那么继续这样做是有道理的。但是，如果更灵活的路线的成本很高，那么就不要这样做。除非您确定您需要该功能并且成本合理，否则您不应该疯狂地尝试添加此类功能;如果你这样做，你很可能会花很多钱。