代码有多长时间了？

Question

我正在回过头代码中的一些较小的TODO。其中一个是处理部分日期的类，例如2001年1月。它适用于我们系统中可见的日期（1990年至2099年），并且在其他日期优雅地失败。

我为自己留下的TODO是我在2100年及以后的世纪都没有处理日期。我真的不认为修复这个特定问题的努力是值得的，但我认识到Y2k的错误。如果我们已经在2080年，我认为我会以不同的方式思考并修复错误。

那么代码需要多长时间？我们应该在多大程度上规划我们的系统继续运行？

更新

好的，谢谢你的所有意见。我想我可以选择将TODO留在代码中，什么都不做。我发现最有趣的想法是：

• @Adrian - 永恒，我认为这是最正确的假设，你对VM的看法是好的。
• @ jan-hancic - 这取决于，是的。
• @ chris-ballance - 我猜这个限制被击中的时候我会死的，所以如果他们愿意，他们可以玷污我的坟墓，但我会死的，所以我只会困扰他的屁股。

我决定什么都不做的原因很简单。它增加了可忽略的商业价值，其他需要看的东西确实增加了价值所以我会先做它们而如果我得到时间我会修复它，但实际上它不会再这样了而非学术活动。

Answer 1

比你预期的要长。

Answer 2

永恒。

鉴于旧系统在虚拟机中继续运行的趋势，我们必须假设所有有用的代码将永远运行。自60年代以来，有许多系统运行，例如金融领域的后端代码，似乎没有迹象表明这些系统将被取代。 （与此同时，前端每隔一年就会被最新的网络技术所取代。因此，您的代码越接近系统的核心，它就越有可能永远运行。）

Answer 3

你不能在这里得到一般答案。取决于您正在建设什么样的项目。 如果您正在为太空探测器编写软件，那么您可能需要对其进行编码，以便它可以在未来100年内使用。 但是，如果您正在为公司的网页编写特殊的Xmas优惠，那么几周就足够了......

Answer 4

假设任何维护代码的人都是精神病患者并且拥有家庭住址。

Answer 5

没有人真的知道。专业编程已经存在了30到40年，所以没有人真正知道代码是否会持续100年。但是，如果Y2K错误是一个迹象，那么很多代码将会比程序员预期的更长时间。请记住，即使您考虑到这一点，它仍然可能比您预期的更长时间。无论你准备多少，它仍然可能比预期的预期寿命更长。

我的建议是不要计划代码可以使用100年。相反，尝试确保所有代码在相同的时间内工作，也就是说，它的一部分不应该在2年内失败，而另一部分应该在100年内失败。记住，你应该首先确定最薄弱的环节，所以没有必要使最强的环节变得更强。

Answer 6

有时，代码的持续时间比您想象的要长。但更重要的是滑坡论证。一旦你原谅了自己的一些非防弹性，你可能会进一步优化并吝改逻辑正确性，直到它最终咬你。

顺便说一句，我建议在每个TODO评论中都有一个问题ID（例如FogBugz案例编号），这样人们就可以实际订阅并跟踪这个TODO。

Answer 7

丹·伯恩斯坦的不朽话语：Don't contribute to the Y10K problem!

Answer 8

我不认为代码会持续这么久。 想想过去90年来所有的发明和进步。

在2100年，我们不必写下代码。 会有某种脑机界面。

Answer 9

好吧，我们最近制作了一个时间戳格式，其中时间以无符号的64位整数存储，从1970年开始以微秒为单位。它将持续到586912年，这应该足够了。

“永远”的编码是不必要的 - 当然你可以使用BigIntegers等等，但为什么呢？准备超过5年或10年。二十年前的生产代码现在并不常见，我怀疑平均生命周期在不久的将来会更长。

Answer 10

我总是尝试编写代码，因为我的应用程序必须“永远”工作。我很确定我不会再在2100了，但我知道我的软件有一个有效期限，但这并不能让我感觉良好。如果你知道这些事情，试着避免它们！你永远不会知道，但未来一些未知的程序员可能会感激不尽。

Answer 11

这取决于代码具有多少业务价值以及从头开始编写代码需要多少资源。价值和资源越多，持续时间越长。十年或更长时间是典型的商业“工作，不要碰它”代码。

Answer 12

一直到它破裂的时间，或以其他方式停止有用，然后再延长一段时间

Answer 13

基本的事情是：

1. 您的内部日期类有多好（获得非常强大的库版本并坚持下去！）

2. 这不仅仅是时间的流逝，也是用户想要的投入范围的增长。例如，您现在可能有30年的抵押贷款投入，但下个月有人决定输入期限为2110年或者100年迪士尼债券的99年租约！

如果您接受带有日期窗口的2位数年份输入，请仔细考虑如何将其应用于开始日期和结束日期，并提供大量即时反馈。

Answer 14

只要人们可以继续向愿意支付费用的人支付费用。

Answer 15

请记住，现代编程的主要奖励之一就是重用。

这意味着您最初编写的用于解决一个问题的代码可能会在几年后重新用于完全不同的场景（甚至可能在您不知情的情况下，由队友）。

作为旁注： 自动化单元测试的主要优点之一是测试您甚至不记得的代码是否存在于系统中！ ：）

Answer 16

1995年，我开始在一个8岁的代码基础上从事新工作。 所以它的传播日期是1987年左右。

代码可能仍然在服务中。那是什么？ 23年。
公司有一些举动，但他们可能保留了软件（因为它有效） 如果它现在仍然在使用，它将在十年左右的时间内投入使用。

在C（主要是）

中，这并不奇怪，特别是高科技代码

1999年，我开始从事新工作，代码库的前身已经回到了1984年。 我在2000年设计的新版本仍在使用中，其设计元素如前一个数据文件格式（依此类​​推），这将是一个超过26年的开发计划。

因此，当20位签名的time_t翻身时，2086年的问题开始变得更加突出。

Answer 17

事实上我已经有机会签订合同十多年了，以便将代码移植到一个新的平台（OS / 2这些日子并不那么受欢迎！）。如有疑问，请假设您的代码比您的代码寿命更长。至少，记录这样的限制;修复它们，除非这比记录它们需要更多的工作。

Answer 18

我目前的商店有一个庞大的代码库，可运行具有复杂业务规则的财务应用程序。其中一些规则在存储过程中编码，一些在触发器中编码，一些在3gl和4gl应用程序代码中编码。有90年代后期的运行代码，而且你的“传统”Legacy语言中没有一个像COBOL或FORTRAN。可以想象，它是一堆热气腾腾的意大利面条代码，大部分是在TDD意味着什么之前创建的，所以人们不愿意接触任何东西。

Answer 19

请记住你最后的意思。

例如，最初的UNIX操作是在30年前开发的。但在这30年中，该产品随着时间的推移不断发展。

尽管如此，如果今天仍然存在一些原始代码，我也不会感到惊讶。

所以想想它的两种方式...... 1）你有没有对未来触及的代码进行反对，2）如果你有支持和参与，产品/代码就会发展。

Answer 20

问题不在于“代码持续多长时间？”而是“我的代码中的内容会影响应用程序多长时间？”

即使你的代码被替换了，它也可能被替换为完全相同的代码。在某种程度上，这是Y2K问题的直接原因。更重要的是， 是Y2038 problem的直接原因。

Answer 21

在旧机器上运行的代码有40或50年的代码。

（此主题中的有趣位：http://developers.slashdot.org/developers/08/05/11/1759213.shtml）。

你必须问自己你正在解决的问题的性质，但一般来说，即使是“快速修复”也会存在多年，所以你可以真实地看到十年或更长时间的代码体面的保质期。

您需要考虑的其他事项是：

1）应用程序的“活跃生命”是什么 - 它将被用于和处理。

2）应用程序的“非活动生命”是什么 - 它不会每天使用，但可能用于检索和查看旧记录。例如，英国审计法意味着记录需要提供7年，因此可能需要7年才能使用。

3）它需要处理的未来数据范围是多少？例如，假设您正在取消信用卡到期日 - 您可以拥有一张不会过期十年的卡。你能处理那个日期吗？

这些问题的答案通常会让您假设您永远不会故意编写具有超出您使用的操作系统/语言的日期限制的代码。

Answer 22

恕我直言，归结为手工艺：我们在工作中采取的自豪感，编码为标准，我们不会羞于看到另一个真正的编码器。

在这样的日期的情况下，你已经说过它在2100之后gracefully fails。这听起来你可以毫不犹豫地删除TODO，因为你已经内置了一个允许原因的响应未能在发生故障的情况下（无论多么可能或不太可能）容易诊断和修复。

Answer 23

这是我的两分钱：

当我们设计一个项目时，我们通常会声明它至少持续5年。通常不超过10年，我们重新设计并全面构建它。 （我们在这里讨论的是大中型项目）。

通常情况下，您构建的新项目应该替换旧项目，无论是技术方面（即从MF移动到Windows，VB移动到.net等），但这个项目永远不会结束。因此，您的客户最终会同时使用2个系统，剩下的系统将被称为“遗留”。

如果等待的时间足够长，第三个项目将会上升，导致客户端同时使用3个系统，等等......

但是要回答你的问题，我会在重新设计前5到10年打赌，除非你的日期应该在未来很长时间 - 不必担心2100的限制。

Answer 24

最多3 - 5年之后你又转到了另一份工作，留下了蹩脚的代码。