代码持续多久？
我正在回顾一些我的代码中较小的TODO。 其中一个是处理部分date的类，例如2001年1月。对于在我们的系统（1990 – 2099）中可以看到的date，它的工作正常，并且在其他date中优雅地失败。
我为自己留下的TODO是我不处理2100年以后的date。 我并不认为值得为解决这个问题付出努力，但我认识到这个Y2k的缺陷。 如果我们已经在2080年了，我想我会以不同的方式思考并修复这个错误。
那么代码持续多久？ 我们应该提前多久计划我们的系统继续运行？
更新
好的，谢谢你的所有input。 我想我会select离开TODO的代码，什么也不做。 我觉得最有意思的是：
- @阿德里安 – 永恒，我认为这是最正确的假设，你关于虚拟机的观点是一个很好的观点。
- @ jan-hancic – 这取决于，是的。
- @ chris-ballance – 我估计在这个限制被打的时候我会死的，所以如果他们愿意的话，他们可能会玷污我的坟墓，但是我会死的，所以我只是在困扰他的屁股。
我决定什么都不做的原因很简单。 它增加了可忽略的商业价值，其他需要考虑的事情确实增加了价值，所以我会先做它们， 如果我有时间我会解决它，但实际上它只不过是一次学术演习。
比你想象的要长。
永恒。
鉴于旧系统在虚拟机上运行的趋势，我们必须假定所有有用的代码将永远运行。 自上世纪60年代以来，有很多系统运行起来，例如金融领域的后端代码，似乎没有迹象表明这些系统将被取代。 （与此同时，前端每隔一年就会被networking技术的最新潮stream所取代，所以，越接近你的系统核心，越有可能永远运行）。
这里你不能有一般的答案。 取决于你正在build造什么样的项目。 如果你正在为太空探测器编写软件，那么你可能需要编写代码，以便在未来100年甚至更长时间内运行。 但是，如果你正在为公司的网页编写一个特殊的圣诞节优惠，那么几个星期就足够了。
假设谁将维护代码是一个精神病患者，并有你的家庭住址 。
没有人知道 专业编程已经有30 – 40年了，所以没人知道代码是否会持续100年。 但是，如果说千年虫问题是一个迹象，那就是很多代码将会比程序员所期望的要长得多。 请记住，即使您考虑到这一点，它仍然可能会比预期的更长。 无论你准备多less，它可能仍然超过它的预期寿命。
我的build议是不计划代码持续100年。 而是尽量确保你所有的代码都能在相同的时间内工作，也就是说，其中的一部分不会在两年内失败，而另一部分则会在100年内失败。 记住，你应该总是先修补最薄弱的环节，所以没有必要把最强大的环节加强。
有时候，代码会持续比您想象的更长的时间。 但更重要的是滑坡的说法 。 一旦你原谅了自己的一点防弹，你可能会想要进一步优化和撇号的逻辑正确性，直到它最终咬你。
顺便说一下，我build议在每个TODO评论中都有一个问题ID（例如FogBugz案例编号），以便人们实际上可以订阅和跟踪这个TODO。
在丹·伯恩斯坦的不朽的话语中： 不要为Y10K问题做出贡献！
我不认为代码会持续这么久。 想想过去90年来所有的发明和进步。
在2100年，我们不必写下代码。 会有某种脑机接口。
那么最近我们做了一个时间戳格式，其中时间存储在一个无符号的64位整数从1970年微秒，它将持续到586912年，这应该是足够的。
编码为“永远”是不必要的 – 当然，你可以使用BigIntegers等等，但是为什么？ 只要准备超过5年或10年。 二十年的生产代码现在并不是很罕见，我怀疑在不久的将来，平均生命周期会变得更长。
这取决于代码具有多less商业价值以及从头开始编写它需要多less资源。 持续的时间越长，价值和资源就越多。 十年以上是典型的商业“作品，不要碰它”的代码。
我一直试图编写像我的应用程序必须“永远”工作。 我很肯定，我不会在2100年左右，但知道我的软件有一个到期date生成不会让我感觉良好。 如果你知道这样的事情，尽量避免它们！ 你永远不会知道，但未来一些未知的程序员可能会感激。
直到它破裂或者不再有用，然后在那之后再长一点
基本的东西是：
-
你的内部date类有多好（得到一个非常强大的库版本，坚持下去！）
-
这不仅仅是时间的stream逝，也是用户需要的input范围的增长。 例如，也许你现在有30年的抵押贷款投入，但下个月有人决定input一个到期日为2110年的99年租约，或是100年的迪斯尼债券！
如果您接受带有date窗口的2位数年份input，请仔细考虑如何将其应用于开始date和结束date，并提供大量即时反馈。
这是我的两分钱：
当我们devise一个项目时，我们通常会宣称它至less要持续5年。 通常不超过10年，我们重新devise和全面build设。 （我们在这里谈论中型大型项目）。
通常发生的事情是，你所build立的新项目应该取代旧项目，无论是技术上的明智的（即从MF到Windows，VB到.net等），但这个项目永远不会结束。 所以你的客户最终会同时和2个系统一起工作，剩下的系统就是后来被称为“遗留”的东西。
如果等待时间足够长，第三个项目就会上升，从而导致客户一次使用3个系统，等等。
但是要回答你的问题，我会在重新devise之前的5 – 10年下赌注，除非你的date应该是长期的 – 没有必要担心2100的限制。
恕我直言，它归结为craftmanship：我们在工作中采取的骄傲，编码到一个标准，我们不会为另一个真正的编码器看到羞愧。
在这样的date的情况下，你已经说过它在2100年后会gracefully fails 。这听起来像你可以没有良心地去除TODO，因为你已经build立了一个响应，可以让故障的原因很容易被诊断并在发生故障的情况下（不pipe可能的或不可能的情况）。
在40或50年前的旧机器上运行代码的例子。
（有趣的位在这个线程： http : //developers.slashdot.org/developers/08/05/11/1759213.shtml ）。
你必须问自己，你正在解决的问题的性质，但一般来说，甚至“快速修复”将会是多年，所以你可以实际上看十年或更长的代码，意图有一个不错的货架期。
其他的事情你需要考虑的是：
1）什么是应用程序的“积极生活” – 这是它将被使用和处理的地方。
2）什么是应用程序的“不活跃的生活” – 这是不会被日常使用的，但可以用于检索和查看旧的logging。 例如，英国的审计法意味着logging需要有7年的时间，所以从上次的系统使用可能需要7年。
3）它需要处理的未来数据的范围是什么？ 例如，假设你正在取消信用卡失效date – 你可以拥有一张不会过期十年的信用卡。 你能处理那个date吗？
这些问题的答案通常会引导你假定你永远不应该有意识地写出超出你使用的操作系统/语言的date限制的代码。
问题不是“代码持续多久？” 而是“我的代码中的事情会影响应用程序多久？”
即使你的代码被replace了，也有可能被replace成完全相同的代码。 这在一定程度上是千年虫问题的直接原因。 更重要的是 ，这是 Y2038问题的直接原因。
还要记住你最后的意思。
例如，最初的UNIX操作是在30年前开发的。 但在这30年里，产品随着时间的推移而发展。
但是，如果今天仍然存在一点点但是原始的代码，这并不会让我感到惊讶。
所以想想这2种方法…… 1）你是否曾经反对将来被触及的代码，2）如果你有支持和参与，产品/代码将会发展。
我目前的商店有一个庞大的代码库，运行复杂的业务规则的财务应用程序。 其中一些规则在存储过程中编码，一些在触发器中，一些在3gl和4gl应用程序代码中编码。 运行代码从90年代后期开始，并没有像“COBOL”或“FORTRAN”这样的“传统”传统语言。 正如人们可以想象的那样，这是一堆意大利面代码，大部分是在TDD之前创build的，所以人们不愿意碰任何东西。
我已经有十几年的时间来签订契约了，现在就把代码移植到一个新的平台上来讨论（OS / 2这些日子还不是很stream行！）。 如果有疑问，假设您的代码将比您的寿命更长。 至less要logging下这样的限制。 修复它们，除非需要比logging更多的工作。
1995年，我开始在一个新的工作，在一个8岁的代码基础上工作。 所以它的使用date是1987年左右。
代码可能仍在服务中 。 那是什么？ 23年。
公司已经有了一些动作，但他们可能保留了软件（因为它有效）如果它现在还在使用中，它仍然会在十年左右的时间内投入使用。
在C（大部分）中，这并不奇怪，特别是高科技代码，
在1999年，我开始了一个新的工作，代码库的前身已经可以追溯到1984年。我在2000年devise的新版本仍在使用中，其devise元素（比如前一个的数据文件格式等等）和将是一个超过26年的发展计划。
因此，2086年的问题开始稍微有些落后，因为这些32位有符号时间的数据将会翻滚。
请记住，现代编程的主要奖金之一是重用。
这意味着您最初编写的用于解决某个问题的代码可能在几年之后被重新使用并用于一个完全不同的场景（甚至可能在您不知情的情况下由一名队友）。
作为一个方面说明：自动化unit testing的主要优势之一，是testing代码，你甚至不记得是在系统中！ 🙂
只要人们可以继续向愿意支付的人提出支持。
最多3-5年 之后，你已经转移到另一个工作，并留下你糟糕的代码。
