前端进阶（十九）如何写出优质代码

1.DRY-不要使用两行相同的代码

不要在你的代码中有相同的两行代码， 这是几乎所有程序员都同意的一条准则。

假如你没有遵守这条规则，即你的代码中有相同的两行代码，那么在需要修改这两行代码时，你需要修改两遍，这种是理想情况，实际上可能会有更多的，所以请不要书写两行相同代码。

2.方法尽可能短，职责要单一

代码中请不要特别长的函数，除非他们仅仅实现同样一个功能，否则很长的函数必须要拆分成较小的函数。

如果你是使用了短小的函数，至少有以下几点优点：

• 代码会变得更容易阅读。

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

• 代码会变得更容易测试。

3.良好的命名规范

在命名函数时，必须以动词开头，命名变量时要使用名词，不用担心变量名称过长，压缩时会帮你处理。

4.赋予每个类正确的职责

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

5.把代码组织起来

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

对于单个文件而言：需要实现某个具体的业务功能或者模块，对于文件夹而言，需要实现某个组件、单个的路由或者是单独的UI展示。

6.创建大量的单元测试

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

单元测试可以减少很多后期的维护工作，尽量遵循测试驱动开发。

7.经常重构你的代码

软件开发是一种持续的发现的过程，从而让你的代码可以跟上最新的实际需求的变化。 所以，我们要经常重构自己的代码来跟上这样的变化。 当然，重构是有风险的，并不是所有的重构都是成功的，也不是我们随时都可以重构代码。

下面是两个重构代码的先要条件，以避免让你引入更多的BUG，或是把本来就烂的代码变得更烂。

有大量的单元测试来测试。正如前面所说，重构需要用大量的单元测试来做保障和测试。

每次重构都不要大，用点点滴滴的小的重构来代替那种大型的重构。 有太多的时候，当我们一开始计划重构2000行代码，而在3个小时后， 我们就放弃这个计划并把代码恢复到原始的版本。 所以，我们推荐的是，重构最好是从点点滴滴积累起来的。

8.程序注释是邪恶的

这一条一定是充满争议的，大多数程序员都认为程序注释是非常好的， 是的，没错，程序注释在理论上是非常不错的。

但是，在实际过程中，程序员们写出来的注释却是很糟糕的， 从而导致了程序注释成为了一切邪恶的化身，也导致了我们在阅读程序时， 大多数时候，我们都不读注释而直接读代码。

所以，在这里，我们并不是鼓励不写注释，而是——如果你的注释写得不够好的话， 那么，你还不如把更重要的时间花在重构一下你的代码，让你的代码更加易读， 更加清楚，这会比注释更好。

9.注重接口，而不是实现

这是一个最经典的规则了。

接口注重的是——“What”，是抽象，实现注重的是——“How”，是细节。 接口相当于一种合同契约，而实际的细节相当于对这种合同契约的一种运作和实现。 运作是可以很灵活的，而合同契约则需要是相对需要稳定和不变的。

如果，一个接口没有设计好，而需要经常性的变化的话，那我们可以试想一下，这带来的后果， 这绝对会是一件成本很大的事情。

所以，在软件开发和调试中，接口是重中之重，而不是实现。 然而我们的程序员总是注重于实现细节，所以他们局部的代码写的非常不错， 但软件整体却设计得相对较差。 这点需要我们多多注意。

10.代码审查机制

所有人都会出错，一个人出错的概率是很大的，两个人出错的概率就会小一些， 人多一些，出错的概率就会越来越小。

因为，人多了，就能够从不同的角度看待一个事情，虽然这样可能导致无效率的争论， 但比起软件产品release后出现问题的维护成本，这点成本算是相当值得的。

所以，这就是我们需要让不同的人来review代码，代码审查机制不但是一种发现问题的最有效的机制， 同时也是一种可以知识共享的机制。

当然，对于Code Review来说，下面有几个基本原则：

审查者的能力一定要大于或等于代码作者的能力， 不然，代码审查就成了一种对新手的training。

而且，为了让审查者真正负责起来，而不是在敷衍审查工作， 我们需要让审查者对审查过的代码负主要责任，而不是代码的作者。

另外，好的代码审查应该不是当代码完成的时候， 而是在代码编写的过程中，不断地迭代代码审查。 好的实践，无论代码是否完成，代码审核需要几天一次地不断地进行。