---
layout: post
title: 如何构建优质代码
description: DRY 是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力
keywords: 优质代码,代码质量
author: admin
date: 2013-01-25 08:23
category: 网络技术
tags: code
---




## 1.DRY

DRY 是一个最简单的法则，也是最容易被理解的。
但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，
这并不是一件容易的事）。

它意味着，当我们在两个或多个地方发现一些相似的代码的时候，
我们需要把他们的共性抽象出来，形成一个唯一的新方法，并且改变现有的代码，
让他们以一些合适的参数调用这个新的方法。

DRY 这一法则可能是编程界中最通用的法则了。
目前为止，应该没有哪个程序员对这一法则存有异议。
但是，我们却能发现，一些程序在编写单元测试时忘记了这一法则：
让我们想象一下，当你改变一个类的若干接口，如果你没有使用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后出现问题的维护成本，这点成本算是相当值得的。

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

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

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

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

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