本文翻译自"Improve Code by Removing It"，来自于《程序员应该知道的97件事》一书中的某个章节。

少即是多。这是一句有些陈腐的短小格言，但有时它确实是正确的。

在过去的几周里我对代码库所作的改善工作之一就是删除了其中的几大块代码。

我们编写软件时一直遵循着XP的（译注：极限编程，eXtreme Programming）原则，包括YAGNI（即You Aren't Gonna Need It，你不再需要它了）。不过人类的天性就是这样，我们不可避免地在一些地方无法达到这些要求。 

我观察到，某些产品在执行一些任务时耗时太长，这些任务原本是可以立刻执行完毕的。这是因为它们被过分实现（overimplemented）了；附加了许多其实并不需要的特性，但在当时看来这似乎是一个不错的想法。

因此，我简化了代码，提高了产品的性能，删除了代码库中那些引发问题的特性，降低了全局代码熵（global code entropy，译注：一般指软件中代码的混乱程度）的级别。我的单元测试结果告诉我这些操作没有对产品造成任何破坏。

一个简单且非常令人满意的体验。

为什么起初这些不必要的代码留在了代码库中？为什么程序员感觉到需要编写这些额外的代码呢？还有这些代码是如何通过评审或结对过程的？几乎可以肯定是这样：

·额外的代码会带来一些乐趣，程序员渴望编写这些代码。（提示：写代码，是因为它增加了软件的价值，而不是因为它可以取悦你。）   

·有人认为：这些代码可能是将来需要的，所以觉得最好现在就编写这些代码。（提示：这不符合YAGNI原则。如果你现在不需要它，那么现在不要编写它。）

·这些"额外"的功能看起来似乎都不大，所以与将它们返回给客户确认是否真正需要相比，直接实现它们更为容易。（提示：通常实现和维护一些额外的功能耗费时间更长，而客户实际上则非常容易接近与沟通。一小片额外功能的代码就像一个小雪球，随着时间的推移将变成一大块需要维护的工作。）

·程序员发明的额外需求，既没有写入文档，也没有经过正式的讨论。这些需求实际上是伪造的。（提示：程序员不应设定系统需求；那是客户的职责。）

你现在在做哪些事？这些事是否都是客户需要的？

By Pete Goodliffe

周四下午，收到同事的一封mail，他告诉我他的业务代码中使用的一个库接口的行为与预期不同，并在mail中给出了测试代码和测试结果。而这个接口是之前由我封装实现的。 

这个库仅仅是对libevent做了一层薄薄的封装，目的是使其接口的使用方式符合部门的一贯风格。虽说封装简单，但单元测试也是一应俱全，不敢马虎，必要的地方mock也一并上阵，总体来说我个人还是比较满意的。

不过还是出现了问题，问题出在libevent提供的timer的行为上。这是我们第一次使用libevent，我基于以前对timer的事件处理机制的理解作出了错误的假定：libevent提供的timer是PERSIST的。同事的测试结果却表明这个timer设定是一次性的：只运行一次便失效了，除非在timer的callback handler中重新添加timer事件。

《程序员修炼之道》中在介绍如何深思熟虑而不是靠巧合编程时说过：要测试你的假定。我恰恰是在这块儿犯了错误。尚没有明确libevent的行为就做出了假定而且没有对这个假定做细致测试，最终导致了这个问题的发生。

这个问题最终是这么解决的：了解了一下，libevent 1.x.x版本确实不支持persist timer事件处理，但是在libevent 2.x.x版本中，作者增加了对persist timer的支持。我们原本使用的是1.4.10的libevent，为了支持persist timer，我将库升级到2.0.10(已经是stable版了)。不过仅仅是升级库版本还是不行的。我们不能直接使用libevent提供的evtimer_set接口，因为使用该接口后，我们得到的依旧是一次性的timer。这里需要用event_set(e, -1, EV_PERSIST, eh, arg)替代evtimer_set(e, eh, arg)，这样设置后得到的timer才是persist的。