Question

不是所有的程序都需要运行得快，100%准确，并且能处理所有的输入。如果你真的仔细检查你的需求，有时你可以把它削减成一个简单的问题，只需要较少的代码。让我们来看一些例子。

例子：商店定位器

假设你要给某个生意写个“商店定位器”。你以为你的需求是：

对于任何给定用户的经度/纬度，找到距离该经度/纬度最近的商店。

为了100%正确地实现，你要处理：

·当位置处于国际日期分界线两侧的情况。

·接近北极或南极的位置。

·按“每英里所跨经度”不同，处理地球表面的曲度。

处理所有这些情况需要相当多的代码。

然而，对于你的应用程序来讲，只有在德州的30家店。在这么小的范围里，上面列出的三个问题并不重要。结果是，你可以把需求缩减为：

对于德州附近的用户，在德州找到（近似）最近的商店。

解决这个问题很简单，因为你只要遍历每个商店并计算它们与这个经纬度之间的欧几里得距离就可以了。

例子：增加缓存

我们曾有一个Java程序，它经常要从磁盘读取对象。这个程序的速度受到了这些读取操作的限制，因此我们希望能实现缓存之类的功能。一个典型的读取序列像是这样：

读对像A

读对像A

读对像A

读对像B

读对像B

读对像C

读对像D

读对像D

如你所见，有很多对同一对象的重复访问，因此缓存绝对会有帮助。

当面对这样的问题时，我们首先的直觉是使用那种丢掉最近没有使用的条目的缓存。在我们的库中没有这样的缓存，因此我们必须实现一个自己的。这不是问题，因为我们以前实现过这种数据结构（它包含一个哈希表和一个单向链表——一共有大约100行代码）。

然而，我们注意到这种重复访问总是处于一行的。因此不要实现LRU（最近最少使用）缓存，我们只要实现有一个条目的缓存：

这样我们就用很少的代码得到了90%的好处，这段程序所占的内存也很小。

怎么说“减少需求”和“解决更简单的问题”的好处都不为过。需求常常以微妙的方式互相影响。这意味着解决一半的问题可能只需要花四分之一的工夫。