ili*_*ian 40 language-agnostic
我正在回过头代码中的一些较小的TODO.其中一个是处理部分日期的类,例如2001年1月.它可以在我们的系统(1990 - 2099)中看到的日期工作正常,并且在其他日期优雅地失败.
我为自己留下的TODO是我在2100年及以后的世纪都没有处理日期.我真的不认为修复这个特定问题的努力是值得的,但我认识到Y2k的错误.如果我们已经在2080年了,我想我会以不同的方式思考并修复错误.
那么代码需要多长时间？我们应该在多大程度上规划我们的系统继续运行？
更新
好的,谢谢你的所有投入.我想我可以选择将TODO留在代码中,什么都不做.我发现最有趣的想法是:
我决定什么都不做的原因很简单.它增加了可忽略的商业价值,其他需要看的东西确实增加了价值所以我会先做它们,如果我有时间我会修复它,但实际上它只不过是一个学术练习.
aku*_*uhn 35
永恒.
鉴于旧系统在虚拟机中继续运行的趋势,我们必须假设所有有用的代码将永远运行.自60年代以来,有许多系统运行,例如金融领域的后端代码,似乎没有迹象表明这些系统将被取代.(与此同时,前端每隔一年就会被最新的网络技术所取代.因此,您的代码越接近系统的核心,它就越有可能永远运行.)
Jan*_*čič 21
你不能在这里得到一般答案.取决于您正在建设什么样的项目.如果您正在为太空探测器编写软件,那么您可能需要对其进行编码,以便它可以在未来100年内使用.但是,如果您正在为公司的网页编写特殊的Xmas优惠,那么几周应该就够了......
Mar*_*ius 11
没有人真的知道.专业编程已经存在了30到40年,所以没有人真正知道代码是否会持续100年.但是,如果Y2K错误是一个迹象,那么很多代码将会比程序员预期的更长时间.请记住,即使您考虑到这一点,它仍然可能比您预期的更长时间.无论你准备多少,它的寿命都可能超过预期寿命.
我的建议是不要计划代码可以使用100年.相反,尝试确保所有代码在相同的时间内工作,也就是说,它的一部分不应该在2年内失败,而另一部分应该在100年内失败.请记住,您应该始终首先修复最薄弱的环节,因此没有必要强化最强的链接.
Pav*_*sky 10
有时,代码的持续时间比您想象的要长.但更重要的是滑坡论证.一旦你原谅了自己的一些非防弹性,你可能会进一步优化并吝改逻辑正确性,直到它最终咬你.
顺便说一下,我建议在每个TODO评论中都有一个问题ID(例如FogBugz案例编号),这样人们就可以实际订阅并跟踪这个TODO.