我刚刚开始了一份新工作，我的新老板跟我谈过的一件事就是代码的寿命。
我一直在编写代码以使我的代码具有无限的可扩展性和适应性。我想如果将来有人要更改我的代码，那应该很容易做到。
但我从来没有真正清楚地知道未来应该有多远。
所以我的新老板告诉我不要为未来 3 年多的时间写代码，他的理由是技术变化、程序过期等。
起初我有点吃惊，并认为他是一个糟糕的工作，但我考虑的时间越长，我就越喜欢这个概念。
有没有人对你应该编码到多远的未来有意见？
问问题
4351 次
7 回答
26
很难做出判断之一是可扩展性如何。作为老板，当我给某人分配一个 2 小时的任务时，我真的很生气，三天后他们仍在处理它，因为他们认为它应该更具可扩展性，所以他们在配置文件中添加条目并将列添加到表中，并且更改 4 或 5 个其他对象以适应它，现在安装文档已过时，部署脚本必须更改，测试人员必须在一两天内尝试所有组合和排列，这样我们才能知道代码是甚至工作。但是，当其他人通过硬编码所有内容（甚至是发送到的电子邮件地址）将两个小时的任务变成半小时的任务时，我也很恼火，并且不明白团队其他成员何时抱怨。
如果有一个简单的硬性规则，每个人在第一次编译代码的那一天都可以成为高级程序员。它需要经验和判断力，这可能是您将获得的最重要的判断力。你知道如何获得良好的判断力吗？经验。你知道如何获得经验吗？不好的判断。
于 2010-05-24T15:31:03.207 回答
9
您应该按照规范进行编码，仅此而已。如果规范规定了 30 年，那么您编码 30 年。如果规范规定了 3 个月，同样适用。
请记住，您还应该为自己的理智编写代码。您创建的所有代码都应该实现 3 件事：
可替换的代码 - 在我看来，这只是一个好习惯。您在编码中的可替换性越高，您生成的代码就越好。这提供了一种相反的情况 - 您编写的代码越可替换，您自己的价值就越高。
高效的代码 - 重用、重用、重用。
- 代码应该写得很好——这不需要解释。
于 2010-05-24T11:01:12.390 回答
4
如果您真的想要一个持久的计划，请确保您的日期可以处理2038年之后（即下一个“千年虫”）。
撇开日期不谈，一个从现在开始的一年而不是从现在开始的十年是如何编码的？您要么编写可维护的代码，要么不编写；您无法准确指定更改“到期”之前的时间。
我想有人可能会争辩说，他们的语言的下一个标准将弃用 method Foo，但如果要弃用一种方法，那实际上更多的是代码质量和可维护性，而不是为将来的日期编码。
于 2010-05-24T11:01:16.223 回答
1
编码好，只关注下一个可交付成果。无论是否考虑到这一点，编写良好的代码都是无限可重构/可扩展的。在实践中很少有编写不佳的可扩展代码。
于 2010-05-24T11:00:01.360 回答
1
如果您严格遵循敏捷方法，那么您应该只是针对当前问题进行编码。这也被称为 YAGNI（你不需要它）原则。
这个想法是您不知道拐角处会发生什么，因此尝试为其编写代码是没有意义的。
但是，我认为这不是特别明智的做法。
即使您处于敏捷环境中，您也知道您希望代码能够进行多次迭代，因此应该为此编写代码。
如果您正在编写“杀手级”应用程序，程序确实会过期并且技术会发生变化，但它的存在时间将超过 3 年。
于 2010-05-24T11:02:18.447 回答
1
每当我编写代码时，我都会问自己...
需要吗？如果你不需要它，那你为什么要编码呢？
我发现它有助于防止我添加不必要的代码。不必要的代码是一种消耗。它需要时间远离其他活动。它增加了代码的大小和复杂性。它为项目增加了 $$$——尤其是在代码库必须经过认证过程的情况下。
于 2010-05-24T15:24:48.230 回答
0
在设计你的代码时，你应该记住它可能被扩展或可能需要新功能的可能方式，你应该努力使其足够模块化，以便添加新功能成为可能。如果有一个决定会使它更灵活或可扩展，而另一个决定会使它变得更加僵化，如果变得更灵活几乎没有成本，那么这样做是有意义的。但是，如果更灵活的路线的成本很高，那就不要这样做。除非您确定您将需要该功能并且成本合理，否则您不应疯狂地尝试添加此类功能；如果你这样做，你很可能会白白花很多钱。
于 2010-05-24T11:09:15.643 回答