代码的可扩展性应该有多高？

Question

代码的可扩展性应该有多高？

extensibility

18

我刚开始一份新工作，我的新老板和我谈起了代码的长久性。

我一直编写代码是为了让它无限可扩展和适应性强。我认为，如果将来有人要更改我的代码，那么这应该很容易实现。

但我从来没有一个明确的想法，应该把未来延伸多远。

所以我的新老板告诉我不要费心编写超过3年的未来，他的理由是技术变化，程序到期等原因。

起初我有些吃惊，觉得他是个怪人，但我越想越觉得这个概念不错。

有其他人对你应该编写多远的未来代码有什么看法吗？

- griegs

7个回答

10

你应该按照规格编码，不多不少。如果规格要求30年，那么你就编写30年的代码。如果规格要求3个月，同样适用。

但请记住，你还应该为了自己的理智编写代码。你创建的所有代码应该实现三个目标：

编写可替换的代码-这只是我的好习惯。在编码时，越容易被替换，你就能够产生更好的代码。这种情况提供了一种反向的方式—你使你的代码更容易被替换，你就能让自己变得更有价值。
编写高效的代码-重复使用、重复使用、重复使用。
代码应该写得好-这不需要解释。

- Kyle Rosendo

4

如果你真的想要一个持久的程序，那么请确保你的日期可以处理2038之后的时间（那是下一个“Y2K”）。

放开日期不谈，如何编写一年后而不是十年后的代码呢？你要么编写可维护的代码，要么不编写；你无法准确指定更改“过期”的时间。

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

- Mark Rushakoff

1

写好代码，只关注下一个可交付成果。良好编写的代码是无限可重构/扩展的，无论是否考虑到这一点。而那些本来就意图可扩展但编写质量较差的代码，在实践中很少能够实现。

- David M

1

如果你严格遵循敏捷方法论，那么你应该只为当前的问题编写代码。这也被称为YAGNI（You Ain't Gonna Need It）原则。

这个想法是，你不知道未来会发生什么，所以试图为它编写代码是没有意义的。

然而，我认为这并不是特别明智的做法。

即使你处于敏捷环境中，你也有一个想法，希望代码能够在几次迭代后做到什么，因此应该按照那个方向编码。

虽然程序会过期，技术也会变化，但如果你正在编写那个“杀手级”应用程序，它将存在比3年更长的时间。

- ChrisF

1

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

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

我发现这有助于防止我添加不必要的代码。不必要的代码是一种负担。它会占用其他活动的时间。它增加了代码的大小和复杂性。尤其是如果代码库必须经过认证流程，它会增加项目的成本。

- Sparky

0

在设计代码时，您应该考虑可能的扩展方式或对其提出新功能的需求，并努力使其足够模块化，以便添加新功能成为可能。如果有一个决策点可以使其更灵活或可扩展，而另一个决策则会使其更僵硬，如果更灵活的代价很小或几乎没有，那么选择更灵活的方案是有意义的。然而，如果更灵活的代价很大，则不要这样做。除非您确定需要该功能并且成本合理，否则不要试图疯狂地添加此类功能；如果这样做，您很可能会白白浪费很多时间和精力。

- Michael Aaron Safyan

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Kate Gregory · Accepted Answer

在IT技术领域里，难以做出的决策之一就是如何平衡可扩展性。作为老板，如果我指派一个2小时的任务，三天后他们仍然在工作，因为他们觉得它应该更具可扩展性，于是添加了配置文件中的条目和表格中的列，并必须更改其他4或5个对象来适应这些变化，现在安装文档已经过时，部署脚本也需要更改，测试人员需要花费一两天时间尝试所有组合和排列方式，以便我们知道代码是否有效。但是，当另一个人将这个两小时的任务变成半小时的任务，甚至将发送邮件所需的电子邮件地址硬编码，而团队的其他成员抱怨时，我同样感到很恼火。

如果有一个简单明确的规则，那么每个人在首次编写代码时都可以成为高级程序员。而在实践中，这需要经验和判断力，并且这可能是您所获得的最重要的判断力。您知道如何获得良好的判断力吗？通过经历不良判断而获得经验。