编程十诫

原文： http://cocre.com/?p=1007 （酷壳）

 

1.- DRY: Don’t repeat yourself.
DRY 是一个最简单的法则，也是最容易被理解的。但它也多是最难被应用的（由于要作到这样，咱们须要在泛型设计上作至关的努力，这并非一件容易的事）。它意味着，当咱们在两个或多个地方的时候发现一些类似的代码的时候，咱们须要把他们的共性抽象出来形一个惟一的新方法，而且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。

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

 

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

代码会变得更容易阅读。
代码会变得更容易重用（短方法能够减小代码间的耦合程度）
代码会变得更容易测试。
3.- 良好的命名规范
使用不错的统一的命名规范可让你的程序变得更容易阅读和维护，当一个类，一个函数，一个变量的名字达到了那种能够“望文生义”的境界话，咱们就能够少一些文档，少一些沟通。文章《 编程中的命名设计那点事 》能够给你一些提示。

4.- 赋予每一个类正确的职责
一个类，一个职责，这类规则能够参考一下类的 SOLID 法则。但咱们这里强调的不是一种单一的职责，而是一个正确的职责。若是你有一个类叫Customer，咱们就不该该让这个类有sales 的方法，咱们只能让这个类有和Customer有最直接关系的方法。

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

物理层组织：不管你使用什么样的目录，包(package)或名字空间(namespace)等的结构，你须要把你的类用一种标准的方法组织起来，这样能够方便查找。这是一种物理性质的代码组织。
逻辑层组织： 所谓逻辑层，主要是说，咱们若是把两个不一样功能的类或方法经过某种规范联系和组织起来。这里主要关注的是程序模块间的接口。这就是咱们常常见到的程序模块的架构。
6.- 建立大量的单元测试
单元测试是最接近BUG的地方，也是修改BUG成本最低的地方，一样也是决定整个软件质量好坏的成败的地方。因此，只要有可能，你就应该写更多的，更好的单元测试案例，这样当你将来有相应代码改变的时候，你能够很简单知道你代码的改变是否影响了其它单元。

7.- 常常重构你的代码
软件开发是一种持续的发现的过程，从而让你的代码能够跟上最新的实际需求的变化。因此，咱们要常常重构本身的代码来跟上这样的变化。固然，重构是有风险的，并非全部的重构都是成功的，也不是咱们随时均可以重构代码。下面是两个重构代码的先要条件，以免让你引入更多的BUG，或是把原本就烂的代码变得更烂。

有大量的单元测试来测试。正如前面所说，重构须要用大量的单元测试来作保障和测试。
每次重构都不要大，用点点滴滴的小的重构来代替那种大型的重构。有太多的时候，当咱们一开始计划重构2000行代码，而在3个小时后，咱们就放弃这个计划并把代码恢复到原始的版本。因此，咱们推荐的是，重构最好是从点点滴滴积累起来的。
8.- 程序注释是邪恶的
这一条必定是充满争议的，大多数程序员都认为程序注释是很是好的，是的，没错，程序注释在理论上是很是不错的。可是，在实际过程序当中，程序员们写出来的注释倒是很糟糕的（程序员的表达能力颇有问题），从而致使了程序注释成为了一切邪恶的化身，也致使了咱们在阅读程序的时，大多数时候，咱们都不读注释而直接读代码。因此，在这里，咱们并非鼓励不写注释，而是——若是你的注释写得不够好的话，那么，你还不如把更重要的时间花在重构一下你的代码，让你的代码更加易读，更加清楚，这比会比注释更好。

9.- 注重接口，而不是实现
这是一个最经典的规则了。接口注重的是——“What”是抽象，实现注重的是——“How”是细节。接口至关于一种合同契约，而实际的细节至关于对这种合同契约的一种运做和实现。运做是能够很灵活的，而合同契约则须要是相对须要稳定和不变的。若是，一个接口没有设计好而须要常常性的变化的话，那咱们能够试想一下，这代来的后果，这绝对会是一件成本很大的事情。因此，在软件开发和调设中，接口是重中之重，而不是实现。然而咱们的程序员老是注重于实现细节，因此他们局部的代码写的很是不错，但软件总体却设计得相对较差。这点须要咱们多多注意。

10.- 代码审查机制
全部人都会出错，一我的出错的几率是很大的，两我的出错的几率就会小一些，人多一些，出错的几率就会愈来愈小。由于，人多了，就可以从不一样的角度看待一个事情，虽然这样可能致使无效率的争论，但比起软件产品release后出现问题的维护成本，这点成本算是至关值得的。因此，这就是咱们须要让不一样的人来reivew代码，代码审查机制不可是一种发现问题的最有效的机制，同时也是一种能够知识共享的机制。固然，对于Code Review来讲，下面有几个基本原则：

审查者的能力必定要大于或等于代码做者的能力，否则，代码审查就成了一种对新手的training。 并且，为了让审查者真正负责起来，而不是在敷衍审查工做，咱们须要让审查者对审查过的代码负主要责任，而不是代码的做者。  另外，好的代码审查应该不是当代码完成的时候，而是在代码编写的过程当中，不断地迭代代码审查。好的实践的，不管代码是否完成，代码审核须要几天一次地不断地进行。 （我以我我的的语言叙述本文，并加入了我我的的经历，因此，请你在转载时请注意做者和出处，而且，请勿用于商业用途）