0. DRY: 不要重复你自己（Don’t repeat yourself）
DRY是一条最容易理解但又是相对比较难以应用的原则。它是指当你在两处或者更多的地方发现相似代码时，我们应当把它们抽象成一个新的函数，在之前重复的地方调用新的函数并带上适当的参数。
DRY也许是最普遍的一条编程原则，我从未发现一个开发人员认为编写重复的代码是件好事。但是我发现一些开发人员在编写单元测试时忘记了这条原则， 例如：设想一下你改变了一个类的接口，之前已经为这个类编写了很多的单元测试，如果你没有应用DRY原则，这时你需要手动去修改所有使用这个类接口的调 用，来与每一个测试实例的新签名匹配。
1. 编写短小的函数/方法
有三个非常好的理由，选择编写短小的函数。
- 1. 代码会更容易阅读。
- 2. 代码会更容易重用（短小的函数更容易产生松耦合）。
- 3. 代码会更易于测试。
编者注：松耦合：在软件领域中，“耦合”一般指软件组件之间的依赖程度。耦合度松的软件会有较好的扩展性。
2. 给类、函数和变量使用好的命名
直接使用其他开发者的代码而不需要阅读说明文档，没有什么比这更好的事情了，因为代码中的类名、函数名已经能够告诉我们所有需要的信息。所以，采用这种方法，每次在为你的代码中任何元素进行命名的之前请花上几秒钟（思考），这会让大家的生活变得更轻松。
3. 为每个类分配正确的职责
一个类只承担一个职责（单一权责），听起来和有些人知道的SOLID原则很相似，但是这里不是指任意的职责，而是正确的职责。所以，如果我们要设计一个顾客类，我们不会给它创建一个销售的行为，我们只会让它处理所有与一个客户相关的数据。
编者注：SOLID：面向对象设计的五项原则 （是SRP单一职责原则、OCP开闭原则、LSP李式代换原则、ISP依赖反转原则和 DIP接口分离原则，首字符的缩写)。
4. 保持代码的条理性
代码条理性分两个层次
- 物理上的条理性：无论你采用了哪种结构，包、命名空间、文件夹等等，用一种更容易并且凭直觉就能找到代码存放在哪里的方式来组织你编写的类。
- 逻辑上的条理性：不论逻辑上从属关系如何，（只要有逻辑从属关系）类都应该能够互相访问彼此的成员变量，但是如果从属于不同的逻辑结构就应当只能通过接口来访问。这种逻辑分组通常会被实现成（逻辑）层、服务等。
5. 编写很多的单元测试
测试越多越好，它们是所有代码变动的安全保证，我们会在将来的某一天需要运行这些测试代码。
6. 尽早且经常地重构代码（Refactor often and sooner）
软件开发是一个持续发现的过程，为了编写保持与新增/改变的需求匹配的高质量代码，随着开发的进行，重构代码是必不可少的。由于重构是一项带有风险的任务，需要有两个主要的前提条件，来避免由于重构给系统引入新的错误。
- 1. 编写很多的单元测试
- 2. 每一次重构的幅度要比较小。在开发软件过程中，开始重构2000行代码，3个小时以后发现所有的代码都不能工作，并且导致问题的原因无从查找，因此需要恢复到最初版本，几乎没什么事能比这更让人抓狂了。
7. 注释是恶魔
这条特殊戒律有一点争议，我们大多数人学到的是“注释是一个好的习惯”，并且在一段晦涩的代码中有一段注释会比仅仅只有代码好的多，这里我的观点 是：给晦涩的代码加注释还不如仅仅留下代码，只需要重构这段代码直到它变得可读为止。（编注：当然了，除了作者说的这种类型的代码，在其他情况下，还是得 添加必要的注释，这不仅方便自己日后查看，更有利于后来者维护，请参阅《提高代码可读性的10个注释技巧 》一文。
8. 要面向接口编程，不要面向实现编程（Code to an interface, not to an implementation）
这是一条经典的原则，面向接口编程会让我们从实现的细节中解放出来，我们只要定义一个协议，并且依据协议调用定义的操作，期望（对方，即被调用的代码）能把实际的实现或者运行时态的实现传递给我们的代码。
9. 对代码进行复查
我们都会犯错误，没有什么能比请别人对我们代码做一个非正式快速复查更好的办法来查找错误了。最好不要等到代码都完成以后再复查，当某些重要部分的代码完成后，或者离上一次复查相隔几天之后，就进行复查。