代码是债务，越少越好

在精益制造中，对库存的定义非常清晰。它包括额外的原料，生产过程中的原料，以及接下来生产队列中的原料。精益强调减少库存，因为持有库存就意味着产生费用。在软件开发中，需求经常被视为库存，那么，代码呢？

Michael Feathers建议，

如果你花费大量时间说明暂时不会实现的特性需求，那么就说明你的流程并不顺畅。那很清楚，但是我认为，我们需要面对残酷的现实，应该把更多实际的东西视为库存： 那就是我们的代码。

Michael认为，在精益生产中，组件是一个接一个生产出来的。我们应该尽量让各个部件顺畅地经过流程，从而获得效率。但在软件领域与此有所不同。在这里，团队会一次又一次地针对同一个部件工作。直到系统被实际应用，该项工作才真正完成。这样，代码也是我们持有的库存，并且需要最小化。

在软件开发过程中，我们实际上经常会持续多年处理同一部件。我们在相同的基础代码中举步维艰。当我们持续处理单独的事物（代码库）时，它会随着时间的改变而变的越来越陈旧，并需要经常的关注，我们无法期望它和生产业的零件一样具有独立性。所以，对我来说，代码也是库存。它们到处散落，保存这些代码需要付出实际的成本。考虑一下我们怎么做才能让它最小化，这是很有好处的。

同样，Ori Pekelman也认为代码是债务而不是资产。最开始，团队会编写代码，做出产品，并用它来赚钱，但是，之后团队应该尽可能地寻找减少代码的方法，从而降低成本。Ori认为，

你拥有的代码越多，添加新内容所要付出的成本就越高。更坏的情况是，你所添加的所有内容都会堆在代码的顶端，接下来要添加内容的时候会成本会更高。现在，对现存代码的负面边缘应用量（negative marginal utility）并不是固定的： 你的代码结构越好，你做了越多的单元测试，你使用的数据库模式越好、越小、耦合越松，那么添加新代码所需要付出的成本就越少。

在Boswell和Foucher著的《阅读代码的艺术》一书中，作者强调了轻量级代码库的重要性。他们认为，应付正式系统最好的方式就是要让代码库尽可能小。他们建议采用如下方法：

• 尽可能创建通用的工具。
• 删除不用的代码或者特性。
• 确保项目模块化，并分割成相互没有关联的子项目。
• 熟悉你经常使用的代码库。
• 对代码库的规模时刻保持警惕，保持它是小而敏捷的。

Kevlin Henney在编写更少代码实践指南中提到，我们有必要删除代码并让代码库的规模更小。

这样看来，有足够的理由让我们保持代码库轻而敏捷。就像Michael最后恰如其分地总结：

我认为未来属于知道如何有策略地删除代码的公司。持有代码的成本要比我们想象的大。意识到这一点的公司更具有竞争优势。

 原文链接：http://www.infoq.com/cn/news/2011/06/less-code-is-better

 英文链接：Code is Liability, the Less the Better