编写好代码的10条戒律

1. DRY: 不要重复你本身（Don’t repeat yourself）

　　DRY是一条最容易理解但又是相对比较难以应用的原则。它是指当你在两处或者更多的地方发现类似代码时，咱们应当把它们抽象成一个新的函数，在以前重复的地方调用新的函数并带上适当的参数。

　　DRY也许是最广泛的一条编程原则，我从未发现一个开发人员认为编写重复的代码是件好事。可是我发现一些开发人员在编写单元测试时忘记了这条原则，例如：设想一下你改变了一个类的接口，以前已经为这个类编写了不少的单元测试，若是你没有应用DRY原则，这时你须要手动去修改全部使用这个类接口的调用，来与每个测试实例的新签名匹配。


　　2. 编写短小的函数/方法

　　有三个很是好的理由，选择编写短小的函数。

• 1. 代码会更容易阅读。

• 2. 代码会更容易重用（短小的函数更容易产生松耦合）。

• 3. 代码会更易于测试。

　　编者注：松耦合：在软件领域中，“耦合”通常指软件组件之间的依赖程度。耦合度松的软件会有较好的扩展性。


　　3. 给类、函数和变量使用好的命名

　　直接使用其余开发者的代码而不须要阅读说明文档，没有什么比这更好的事情了，由于代码中的类名、函数名已经可以告诉咱们全部须要的信息。因此，采用这种方法，每次在为你的代码中任何元素进行命名的以前请花上几秒钟（思考），这会让你们的生活变得更轻松。


　　4. 为每一个类分配正确的职责

　　一个类只承担一个职责（单一权责），听起来和有些人知道的SOLID原则很类似，可是这里不是指任意的职责，而是正确的职责。因此，若是咱们要设计一个顾客类，咱们不会给它建立一个销售的行为，咱们只会让它处理全部与一个客户相关的数据。

　　编者注：SOLID：面向对象设计的五项原则 （是SRP单一职责原则、OCP开闭原则、LSP李式代换原则、ISP依赖反转原则和 DIP接口分离原则，首字符的缩写)。


　　5. 保持代码的条理性

　　代码条理性分两个层次

• 物理上的条理性：不管你采用了哪一种结构，包、命名空间、文件夹等等，用一种更容易而且凭直觉就能找到代码存放在哪里的方式来组织你编写的类。

• 逻辑上的条理性：不论逻辑上从属关系如何，（只要有逻辑从属关系）类都应该可以互相访问彼此的成员变量，可是若是从属于不一样的逻辑结构就应当只能经过接口来访问。这种逻辑分组一般会被实现成（逻辑）层、服务等。

　　6. 编写不少的单元测试

　　测试越多越好，它们是全部代码变更的安全保证，咱们会在未来的某一天须要运行这些测试代码。


　　7. 尽早且常常地重构代码（Refactor often and sooner）

　　软件开发是一个持续发现的过程，为了编写保持与新增/改变的需求匹配的高质量代码，随着开发的进行，重构代码是必不可少的。因为重构是一项带有风险的任务，须要有两个主要的前提条件，来避免因为重构给系统引入新的错误。

• 1. 编写不少的单元测试

• 2. 每一次重构的幅度要比较小。在开发软件过程当中，开始重构2000行代码，3个小时之后发现全部的代码都不能工做，而且致使问题的缘由无从查找，所以须要恢复到最第一版本，几乎没什么事能比这更让人抓狂了。

　　8. 注释是恶魔

　　这条特殊戒律有一点争议，咱们大多数人学到的是“注释是一个好的习惯”，而且在一段晦涩的代码中有一段注释会比仅仅只有代码好的多，这里个人观点是：给晦涩的代码加注释还不如仅仅留下代码，只须要重构这段代码直到它变得可读为止。（编注：固然了，除了做者说的这种类型的代码，在其余状况下，仍是得添加必要的注释，这不只方便本身往后查看，更有利于后来者维护，请参阅《提升代码可读性的10个注释技巧 》一文。


　　9. 要面向接口编程，不要面向实现编程（Code to an interface, not to an implementation）

　　这是一条经典的原则，面向接口编程会让咱们从实现的细节中解放出来，咱们只要定义一个协议，而且依据协议调用定义的操做，指望（对方，即被调用的代码）能把实际的实现或者运行时态的实现传递给咱们的代码。


　　10. 对代码进行复查　　咱们都会犯错误，没有什么能比请别人对咱们代码作一个非正式快速复查更好的办法来查找错误了。最好不要等到代码都完成之后再复查，当某些重要部分的代码完成后，或者离上一次复查相隔几天以后，就进行复查。