要写易删除，而不是易扩展的代码

观点:我们所做的一切 —— 重构、模块化、分层，等等，都是为了让我们的代码易于被删改，都是为了让遗留代码不成为我们的负担，而不是为了代码复用。

每写一行代码，都会有一个代价：维护。为了不在代码上花费太多，我们有了可复用的软件。但是代码复用有一个问题：当你以后想要修改的时候它就会成为一个障碍。

一个 API 的用户越多，为了引入修改而需要重写的代码就越多。相似的，你依赖第三方 API 越多，当其有任何改变时你的麻烦就越多。管理代码之间的兼容性，或者模块之间的依赖关系在大型系统中是一个很重要的问题。而且随着项目越来越久，这个问题就会变得越复杂。

为了写易于删除的代码：重复你自己以避免产生模块依赖性，但是不要重复管理这些代码。同时将你的代码分层：在易于实现但不易于使用的模块的基础上构建易于使用的API。拆分你的代码：将很难于实现且很可能会改变的模块互相隔离，并同时和其他的模块隔离。不要将每一个选项都写死，容许在运行时做改变。不要试图同时去做上述所有的事情，或许你在一开始就不要写这么多代码。

Step 0: Don’t write code

虽然代码越多，摒弃起来就越困难，但是少写一行代码本身并不能省掉任何事情。即使如此，最容易删除的代码是你一开始就避免写出来的代码。

Step 1: Copy-paste code

一点点冗余是健康的。

Step 2: Don’t copy pastecode

我们要努力将代码中难以删除的部分与易于删除的部分分隔得尽可能开，而不是使所有代码都变得易于删除。

Step 3: Write moreboilerplate

就像复制粘贴一样，我们会重复部分代码以避免引入依赖性，以获得灵活度，代价则是冗余。

写模版不是在练习代码复用：我们尽可能将变化频繁的部分和相对更稳定的部分分隔开。应最小化库的依赖性或责任，即使我们必须通过模版来使用它们。

 

你会写更多的代码，但是这些多出来的代码都是在易于删除的部分。

Step 4: Don’t writeboilerplate

分层更多的是为了使那些很难删除的代码易于使用（在不让业务逻辑污染它们的情况下），而不仅仅是关于写以后可以删除的代码。

Step 5: Write a big lumpof code

一次性删掉所有的代码比一段一段的去删更容易。

Step 6: Break your codeinto pieces

一个健康的代码库不一定要完美的呈现出模块化。模块化的部分使写代码变得很有趣，就像乐高玩具的趣味来自于它所有的零件都可以被拼在一起一样。一个健康的代码库会有一些赘言和冗余，但它们使得可移植的组件间的距离恰到好处，因此你不会把自己套在里面。

松耦合的代码不一定就是易于删除的代码，但是它们替代和修改起来都会容易得多。

Step 7: Keep writing code

好的代码并不是要第一次就做对一件事。好的代码是那些不会造成障碍的遗留代码（legacycode）。