1、- DRY： Don’t repeat yourself

　　DRY 是一个简单的法则，也是容易被理解的。但它也可能是难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，这并不是一件容易的事）。它意味着，当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个的新方法，并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。

　　DRY 这一法则可能是编程届中通用的法则了，目前为止，应该没有哪个程序员对这一法则存有异议。但是，我们却能发现，一些程序在编写单元测试（unit testing）时忘记了这一法则：让我们相像一下，当你改变一个类的若干接口，如果你没有使用DRY，那么，那些通过调用一系例类的接口的unit test的程序，都需要被手动的更改。比如：如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法，而是每个test case自己去构造类的实例，那么，当类的构造函数被改变时，你需要修改多少个test cases啊。这是不使用DRY法则所带来的恶果。

　　2、- 短小的方法

　　至少，我们有下面三个不错的理由要求程序员们写下短小的方法。

　　代码会变得更容易阅读。

　　代码会变得更容易重用（短方法可以减少代码间的耦合程度）

　　代码会变得更容易测试。

　　批注：我们一般要求每个函数不超过一屏幕，for循环不超过三层，主要是为了阅读方便，但是刻意去为了短小而简化函数后代码的可维护性也不是很强，所以根据具体业务去处理，函数的职责是做什么，这个函数里面哪些可以公用出来独立为方法的，哪些写法可以简化，这些方面需要去思考。

　　3、- 良好的命名规范

　　使用不错的统一的命名规范可以让你的程序变得更容易阅读和维护，当一个类，一个函数，一个变量的名字达到了那种可以“望文生义”的境界话，我们可以少一些文档，少一些沟通。文章《编程中的命名设计那点事 》可以给你一些提示。

　　批注：命名不规范 相当于整个项目会看起来很乱，命名要求通俗易懂，不要太长。

　　4、- 赋予每个类正确的职责

　　一个类，一个职责，这类规则可以参考一下类的SOLID 法则。但我们这里强调的不是一种单一的职责，而是一个正确的职责。如果你有一个类叫Customer，我们不应该让这个类有sales 的方法，我们只能让这个类有和Customer有直接关系的方法。

　　5、- 把代码组织起来

　　把代码组织起来有两具层次。

　　物理层组织：无论你使用什么样的目录，包（package）或名字空间（namespace）等的结构，你需要把你的类用一种标准的方法组织起来，这样可以方便查找。这是一种物理性质的代码组织。

　　逻辑层组织： 所谓逻辑层，主要是说，我们如果把两个不同功能的类或方法通过某种规范联系和组织起来。这里主要关注的是程序模块间的接口。这是我们经常见到的程序模块的架构。

　　6、- 创建大量的单元测试

　　单元测试是接近BUG的地方，也是修改BUG成本低的地方，同样也是决定整个软件质量好坏的成败的地方。所以，只要有可能，你应该写更多的，更好的单元测试案例，这样当你未来有相应代码改变的时候，你可以很简单知道你代码的改变是否影响了其它单元。