language-agnostic - 创建在历史日期不起作用的软件是一种不好的做法吗？

Question

这是让我思考这个问题的确切情况。

I have function that automatically generates the next logical item number. Part of that item number includes the year that the item number was created. We are now in the year 2010 so the most significant portion of the date (for the purposes of my item number) is "10" and is two characters long. If my program would happen to be executed in 2009, the way that it is current coded, I would get a bad item number because my system is expecting a two digit date (10) not a single digit (9).

我的问题根本不是关于我的具体情况，也不是进行这种字符串操作是否是个好主意:)，而是更多关于我的标题中所述的原则。编写如果在历史上运行将无法正常运行的软件是一个坏主意吗？你有没有遇到过类似的情况，你走的是什么路线，为什么？

Answer 1

说“我的程序不适用于历史数据”是完全正确的。在您的特定情况下，“历史数据”是 2010 年 1 月 1 日之前的内容。我强烈反对那些说对您的代码施加此类限制通常是个坏主意的人。

我们每天都生活在这些限制之中。标准 UNIX time_t例如，具有正负范围约 68 年。使用 time_t 存储日期和时间的应用程序不能表示 1901-12-13 之前或 2030-01-19 之后的日期。然而，数以百万计的应用程序都是使用这种时间格式编写的。但是我们没有听到有人争论这些程序在某种程度上很糟糕。

构建应用程序完全是为了权衡。如果根据您的最佳判断，没有必要涵盖过去或什至 future 某个任意点之外的日期，那么这很好。这与设计一个只能保存 X 条记录的系统或使用 1 TB 驱动器进行部署并知道最终您将不得不在数据增长时进行升级没有什么不同。事实是，我们无法为每一种可能性进行设计。

那些争辩说“Y2K 错误”说明为什么不应该对代码进行任意限制的人没有仔细考虑问题。毕竟，4 位数的年份也是一种任意限制。如果我想表示过去或 future 10,000 年的日期怎么办？那个该死的 Y10K 错误!在某些时候，我们会限制我们支持的范围。

每个软件都有局限性。您选择适合您的应用程序的限制以及您如何看待它在 future 的使用方式。