怎样通过 Twitter 的开源库来随处使用 Emoji 表情符号

通过 GitHub 将它们嵌入到网页和其他项目中。

Emoji, 来自日本的小巧符号，通过图像表达感情，已经征服了移动互联网的信息世界。

现在，你可以在虚拟世界中随处使用它们了。 Twitter 最近开源了他们的 emoji 符号库，使得你可以在你自己的网站，应用，和项目中使用它们。

但这需要一点体力活。 Unicode 已经识别甚至标准化了 emoji 字母表， 然而 emoji 仍然不能完全与所有的网络浏览器相兼容，这意味着大多数情况下，它们将呈现为 “豆腐块”或“空白盒子”。当 Twitter 想使得 emoji 到处可用时，这家社交网络联合了一家名为Icon Factory的公司来渲染浏览器以模仿文本信息符号的效果。Twiter 认为人们对他们的 emoji 库有很大的需求。

现在， 你可以从 GitHub 上克隆 Twitter 的整个库，从而在你的开发项目中使用它们。 下面将为你介绍如何达到上面的目的以及如何使得 emoji 更容易被使用。

为 Emoji 得到 Unicode 支持

Unicode 是国际编码标准，它为任意的符号、字母或人们想在网络上使用的数字配置了一串编码。换句话说，它是你如何在计算机上阅读文本与计算机如何读取文本之间的缺失环节。例如，对于你正看到的位于这些句子中的空格（LCTT 译注：英文分词中间的空格），计算机读取为 “ ”。

Unicode 甚至拥有其自己的原始 emoji，它们可以在没有你的任何努力的情况下在浏览器中被阅读。例如，当你看到了 一个 ❤ 符号，你的计算机正在解码字符串 “2665” 。

要在大多数情况下使用 Twitter 的 emoji 库，你只需在你的 HTML 网页中的 块中添加如下脚本：

<script src="//twemoji.maxcdn.com/twemoji.min.js"></script>

这样就使得你的项目可以访问包含有已经在 Twitter 中可使用的数以百计的 Emoji 符号的 JavaScript 库。然而，创建一个仅仅包含这个脚本的文档并不能使得在你的网站中呈现出 emoji 符号，实际上，你仍需要嵌入这些 emoji 符号！

在 块中，粘贴一些可以在 Twitter 的preview.html 文件源代码 中找到的 emoji 字符串。我使用了 和 🏁，当然我并不知道在浏览器窗口中它们的样子。是的，你必须粘贴并猜测它们。你已经看出了问题，我们将在第二小节中予以解决。

无论如何，通过一些尝试，你可以将一个如下图的原始 HTML 文件---

---显示为如下图的网页：

将 Emoji 转换为可阅读的语言

对于一个网站或应用，Twitter 的解决方案是非常适用的。但如果你想通过 HTML 轻易地插入你喜爱的 emoji 符号，你需要一个更易实现的解决方案，而不是记住所有代表 emoji 的 Unicode 字符串。

那正是程序员 Elle Kasai 的 Twemoji Awesome 样式大展身手的地方。

通过向任意网页中添加 Elle 的开源样式表，你可以适用 英语单词来理解你正插入的 emoji 符号的意义。所以如若你想展示一个 心形 emoji 符号，你可以简单地输入：

<i class="twa twa-heart"></i>

为了实现上面的目的，让我们下载 Elle 的项目，通过点击在 GitHub 上 “Download ZIP” 按钮。

接着，我们在桌面上新建一个文件夹，然后进入该文件夹，并将 emoji.html---我先前向你展示的 HTML 源文件--- 和 Elle 的 twemoji-awesome.css 一同放进去。

我们还需要 HTML 文件识别这个 CSS 文件，所以在 html 网页中的 块中，为 CSS 文件添加一个链接：

<link rel="stylesheet" href="twemoji-awesome.css">

一旦你将上面的代码添加了进去，你便可以删除先前添加的 Twitter 的脚本链接。

现在，找到 body 块部分的代码，然后添加一些 emoji 符号。我使用了 , , 和 。

最终，你将得到如下的代码：

保存并在浏览器中查看上面的文件：

Duang！这样你不仅得到了一个可以在浏览器中支持 emoji 符号的基本网页，而且还知道了如何简单地实现它。你可以随意的在我的 GitHub 中查看这个教程，并且可以克隆这些实际的文件而不只是看看这些截图。

题图来自于得到 Emoji； Lauren Orsini 截图。

via: http://readwrite.com/2014/11/12/how-to-use-emoji-in-the-browser-window

作者：Lauren Orsini 译者：FSSlc 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

问题：

假如说，使用32位的整型会溢出，在不考虑使用长整型的情况下，如果我们只需要表示2的40次方范围内的数，是否可以利用某些40位长的数据类型来表示呢？这样的话，每个整型数就可以节省24位的空间。

如果可以，该怎么做？

需求是：我现在必须处理数以亿计的数字，所以在存储空间上受到了很大的限制。

回答：

可以是可以，但是……

这种方法的确可行，但这么做通常没什么意义（因为几乎没有程序需要处理多达十亿的数字）：

#include <stdint.h> // 不要考虑使用long long类型
struct bad_idea
{
    uint64_t var : 40;
};

在这里，变量var占据40位大小，但是这是以生成代码时拥有非常低的运行效率来换取的（事实证明“非常”二字言过其实了——测试中程序开销仅仅增加了1%到2%，正如下面的测试时间所示），而且这么做通常没什么用。除非你还需要保存一个24位的值（或者是8位、16位的值），这样你皆可以它们放到同一个结构中。不然的话，因为对齐内存地址产生的开销会抵消这么做带来的好处。

在任何情况下，除非你是真的需要保存数以亿计的数字，否则这样做给内存消耗带来的好处是可以忽略不计的（但是为了处理这些位字段的额外代码量是不可忽略的！）。

说明：

在此期间，这个问题已经被更新了，是为了说明实际上确实有需要处理数以亿计数字的情况。假设，采取某些措施来防止因为结构体对齐和填充抵消好处（比如在后24位中存储其它的内容，或者使用多个8位来存储40位），那么这么做就变得有意义了。

如果有十亿个数，每个数都节省三个字节的空间，那么这么做就非常有用了。因为使用更小的空间存储要求更少的内存页，也就会产生更少的cache和TLB不命中和内存缺页（单个缺页会产生数以千万计的指令 [译者注：直译是这样，但语义说不通！]）。

尽管上面提到的情况不足以充分利用到剩余的24位（它仅仅使用了40位部分），如果确实在剩余位中放入了有用的数据，那么使用类似下面的方法会使得这种思路就管理内存而言显得非常有用。

struct using_gaps
{
    uint64_t var           : 40;
    uint64_t useful_uint16 : 16;
    uint64_t char_or_bool  : 8;  
};

结构体大小和对齐长度等于64位整型的大小，所以只要使用得当就不会浪费空间，比如对一个保存10亿个数的数组使用这个结构（不考虑使用指定编译器的扩展）。如果你不会用到一个8位的值，那么你可以使用一个48位和16位的值（giving a bigger overflow margin）。

或者以牺牲可用性为代价，把8个64位的值放入这样的结构体中（或者使用40和64的组合使得其和满足320）。当然，在这种情况下，通过代码去访问数组结构体中的元素会变得非常麻烦（尽管一种方法是实现一个operator[]在功能上还原线性数组，隐藏结构体的复杂性）。

更新：

我写了一个快速测试工具，只是为了获得位字段的开销（以及伴随位字段引用的重载操作）。由于长度限制将代码发布在gcc.godbolt.org上，在本人64位Win7上的测试结果如下：

运行测试的数组大小为1048576
what       alloc   seq(w)  seq(r)  rand(w)  rand(r)  free
-----------------------------------------------------------
uint32_t    0      2       1       35       35       1
uint64_t    0      3       3       35       35       1
bad40_t     0      5       3       35       35       1
packed40_t  0      7       4       48       49       1

运行测试的数组大小为16777216
what        alloc  seq(w)  seq(r)  rand(w)  rand(r)  free
-----------------------------------------------------------
uint32_t    0      38      14      560      555      8
uint64_t    0      81      22      565      554      17
bad40_t     0      85      25      565      561      16
packed40_t  0      151     75      765      774      16

运行测试的数组大小为134177228
what        alloc  seq(w)  seq(r)  rand(w)  rand(r)  free
-----------------------------------------------------------
uint32_t    0      312     100     4480     4441     65
uint64_t    0      648     172     4482     4490     130
bad40_t     0      682     193     4573     4492     130
packed40_t  0      1164    552     6181     6176     130

我们看到，位字段的额外开销是微不足道的，但是当以友好的方式线性访问数据时伴随位字段引用的操作符重载产生的开销则相当显著（大概有3倍）。在另一方面，随机访问产生的开销则无足轻重。

这些时间表明简单的使用64位整型会更好，因为它们在整体性能上要比位字段好（尽管占用更多的内存），但是显然它们并没有考虑随着数据集增大带来的缺页开销。一旦程序内存超过RAM大小，结果可能就不一样了（未亲自考证）。

via:stackoverflow

作者：DamonMichael Kohne 译者：KayGuoWhu 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

如果你想要在Linxu中获得一个高效、自动化、高质量的科学画图的解决方案，应该考虑尝试下matplotlib库。Matplotlib是基于python的开源科学测绘包，基于python软件基金会许可证发布。大量的文档和例子、集成了Python和Numpy科学计算包、以及自动化能力，是作为Linux环境中进行科学画图的可靠选择的几个原因。这个教程将提供几个用matplotlib画图的例子。

特性

• 支持众多的图表类型，如：bar,box,contour,histogram,scatter,line plots....
• 基于python的语法
• 集成Numpy科学计算包
• 数据源可以是 python 的列表、键值对和数组
• 可定制的图表格式（坐标轴缩放、标签位置及标签内容等)
• 可定制文本（字体，大小，位置...)
• 支持TeX格式（等式，符号，希腊字体...)
• 与IPython相兼容（允许在 python shell 中与图表交互）
• 自动化（使用 Python 循环创建图表）
• 用Python 的循环迭代生成图片
• 保存所绘图片格式为图片文件，如：png,pdf,ps,eps,svg等

基于Python语法的matplotlib是其许多特性和高效工作流的基础。世面上有许多用于绘制高质量图的科学绘图包，但是这些包允许你直接在你的Python代码中去使用吗？除此以外，这些包允许你创建可以保存为图片文件的图片吗？Matplotlib允许你完成所有的这些任务。从而你可以节省时间，使用它你能够花更少的时间创建更多的图片。

安装

安装Python和Numpy包是使用Matplotlib的前提，安装Numpy的指引请见该链接。

可以通过如下命令在Debian或Ubuntu中安装Matplotlib：

$ sudo apt-get install python-matplotlib 

在Fedora或CentOS/RHEL环境则可用如下命令：

$ sudo yum install python-matplotlib 

Matplotlib 例子

本教程会提供几个绘图例子演示如何使用matplotlib:

• 离散图和线性图
• 柱状图
• 饼状图

在这些例子中我们将用Python脚本来执行Mapplotlib命令。注意numpy和matplotlib模块需要通过import命令在脚本中进行导入。

np为nuupy模块的命名空间引用，plt为matplotlib.pyplot的命名空间引用：

import numpy as np
import matplotlib.pyplot as plt

例1：离散和线性图

第一个脚本，script1.py 完成如下任务:

• 创建3个数据集（xData,yData1和yData2)
• 创建一个宽8英寸、高6英寸的图(赋值1）
• 设置图画的标题、x轴标签、y轴标签（字号均为14）
• 绘制第一个数据集：yData1为xData数据集的函数，用圆点标识的离散蓝线，标识为"y1 data"
• 绘制第二个数据集：yData2为xData数据集的函数，采用红实线，标识为"y2 data"
• 把图例放置在图的左上角
• 保存图片为PNG格式文件

script1.py的内容如下：

import numpy as np
import matplotlib.pyplot as plt

xData = np.arange(0, 10, 1)
yData1 = xData.__pow__(2.0)
yData2 = np.arange(15, 61, 5)
plt.figure(num=1, figsize=(8, 6))
plt.title('Plot 1', size=14)
plt.xlabel('x-axis', size=14)
plt.ylabel('y-axis', size=14)
plt.plot(xData, yData1, color='b', linestyle='--', marker='o', label='y1 data')
plt.plot(xData, yData2, color='r', linestyle='-', label='y2 data')
plt.legend(loc='upper left')
plt.savefig('images/plot1.png', format='png')

所画之图如下：

例2：柱状图

第二个脚本，script2.py 完成如下任务：

• 创建一个包含1000个随机样本的正态分布数据集。
• 创建一个宽8英寸、高6英寸的图(赋值1）
• 设置图的标题、x轴标签、y轴标签（字号均为14）
• 用samples这个数据集画一个40个柱状，边从-10到10的柱状图
• 添加文本,用TeX格式显示希腊字母mu和sigma(字号为16）
• 保存图片为PNG格式。

script2.py代码如下：

import numpy as np
import matplotlib.pyplot as plt

mu = 0.0
sigma = 2.0
samples = np.random.normal(loc=mu, scale=sigma, size=1000)
plt.figure(num=1, figsize=(8, 6))
plt.title('Plot 2', size=14)
plt.xlabel('value', size=14)
plt.ylabel('counts', size=14)
plt.hist(samples, bins=40, range=(-10, 10))
plt.text(-9, 100, r'$\mu$ = 0.0, $\sigma$ = 2.0', size=16)
plt.savefig('images/plot2.png', format='png')

结果见如下链接：

例3：饼状图

第三个脚本，script3.py 完成如下任务：

• 创建一个包含5个整数的列表
• 创建一个宽6英寸、高6英寸的图(赋值1）
• 添加一个长宽比为1的轴图
• 设置图的标题（字号为14）
• 用data列表画一个包含标签的饼状图
• 保存图为PNG格式

脚本script3.py的代码如下：

import numpy as np
import matplotlib.pyplot as plt

data = [33, 25, 20, 12, 10]
plt.figure(num=1, figsize=(6, 6))
plt.axes(aspect=1)
plt.title('Plot 3', size=14)
plt.pie(data, labels=('Group 1', 'Group 2', 'Group 3', 'Group 4', 'Group 5'))
plt.savefig('images/plot3.png', format='png')

结果如下链接所示：

总结

这个教程提供了几个用matplotlib科学画图包进行画图的例子，Matplotlib是在Linux环境中用于解决科学画图的绝佳方案，表现在其无缝地和Python、Numpy连接、自动化能力，和提供多种自定义的高质量的画图产品。matplotlib包的文档和例子详见这里。

via: http://xmodulo.com/matplotlib-scientific-plotting-linux.html

作者：Joshua Reed 译者：ideas4u 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

本文并没有什么新鲜的。我只是收集了一些不太重要的语句，但这些语句可能对初级程序员来说很重要。也就是些无聊的旧东西。

如果以下的这些你都知道的话，那么你比Java的了解已经超过了对一个平常的家庭主妇的了解。我不知道清楚所有的这些是否是有意义的。即使不知道其中的一些特性，你照样也可以成为一个相当不错的Java程序员。然而，本文中许多的新信息可能表明你还有很大的发展空间。

Java中有四种不同的访问类型(而不是三种)

这四种类型包括：private, package private (包访问权限，无修饰符，又叫default, 译者注)。如果你在类中定义一个元素时并不加任何访问类型修饰符，它将被默认设置为包访问权限(package private)，而不是public或者protected。

Java有四个级别的访问类型。

从另一方面来说，如果在接口中，你不指定方法的访问修饰符，那么它将是public类型的。你也可以显式地指定它为public类型， 但这并不符合SONAR（一个开源代码质量管理平台，译者注）的代码质量管理思想。

访问类型是传递的

我的“在Java中允许选择性的在接口的方法中写public”的观点是一个技术错误。

同样你也可在接口的字段前写final，甚至是static。这说明这些字段可以是非静态或非final吗？不是的，接口中的字段中总是final和static的。

Protected和package private是不一样的

Package private（或者default）访问类型可以使得相同包(package)下其他类能够访问这些字段或方法。保护类型(protected)的方法和字段可以被相同包下的类使用(这和package private是一样的)，同时它也可以被其他类使用，只要那个类继承了这个包含这些protected方法或字段的类。

Protected是可传递的

如果有三个包a、b、c，每个包都分别包含A、B、C类，而且B继承A，C继承B，那么C可以访问A中的protected字段和方法。

package a;

public class A {
    protected void a() {

    }
}
package b;

import a.A;

public class B extends A {
    protected void b() {
        a();
    }
}
package c;

import b.B;

public class C extends B {
    protected void c() {
        a();
    }
}

接口不能定义protected方法

很多人认为可以在接口中定义protected方法。如果你这么做的话，编译器很快就会毫不留情地给你报错。顺便说下，这也就是我为什么认为允许public关键字在接口中是一个技术错误，它会让人觉得还可以写其他访问类型似的。

private是一种新的public

如果你还想在一个接口的方法中声明protected方法,你可能还不理解封装的含义。

此private非彼private

私有变量和方法在编译单元内是可见的。如果这听起来太神秘的话，换种说法：几乎就是在同一个Java文件中。这比“在它们被定义的类中”听起来好理解些。它们在同一编译单元的类和接口中也是可见的。嵌套类可以看到类中封装的私有字段和方法。然而，当前封闭类也可以看到该类下任何深度下类中的私有方法和字段。

package a;

class Private {
    private class PrivateInPrivate {
        private Object object;
    }

    Object m() {
        return new PrivateInPrivate().object;
    }
}

后者并不广为人知，事实上也很少有用到。

Private是类的访问级别而不是对象

如果你可以访问一个变量或方法，那么不管它属于哪个对象你都可以访问它。如果this.a可以访问到，那another.a也可以访问到，只要它们是同一个类的实例。同一个类的实例对象可以随意调用其他实例的变量或方法。不过这样的代码一般都没有意义。现实生活中异常是equals()(由Eclipse生成， 15 - 18行)：

package a;

public class PrivateIsClass {
    private Object object;

    @Override
    public boolean equals(Object obj) {
        if (this == obj)
            return true;
        if (obj == null)
            return false;
        if (getClass() != obj.getClass())
            return false;
        PrivateIsClass other = (PrivateIsClass) obj;
        if (object == null) {
            if (other.object != null)
                return false;
        } else if (!object.equals(other.object))
            return false;
        return true;
    }
}

静态(static)类可能有很多实例

访问类型不是对象级别的而是类级别的。

那些不支持有任何实例的类，通常被称为实用工具类。它们只包含静态字段和静态方法以及唯一的不被该类的任何静态方法调用的私有构造函数。在Java 8中也可以有这样的一个野兽(这个词翻译不通，译者注)在接口中实现，因为Java 8的接口可以有静态方法。我不觉得我们应该使用这个特性而不是实用工具类。我也不完全确信我们应该使用实用工具类。

静态类总是在另一个类或接口中。它们是嵌套类。他们是静态的,就像静态方法不能访问类的实例方法和字段一样，静态内部类也不能访问嵌入类的实例方法和字段。这是因为内部类没有嵌入类实例的引用（或者说是指针，如果你喜欢这么叫的话）。内部类（内部类,也即非静态嵌套类, 译者注)，而非静态嵌套类, 没有嵌入类的一个实例，它是无法被创建的。每个内部类的实例都具有嵌入类实例的一个引用，因此一个内部类可以访问嵌入类的实例方法和字段。

因为这个原因，要是没有外部类的一个实例，你就不能创建一个内部类。当然，如果是当前对象，也就是this的话，你就可以不需要指定它。在这种情况下你可以使用new, 在这种情况下,也就是this.new的简式。在一个静态的环境中,例如从一个静态方法，你必须指定内部类应该创建哪个封闭类的实例。见第10行:

package a;

class Nesting {
    static class Nested {}
    class Inner {}
    void method(){
        Inner inner = new Inner();
    }
    static void staticMethod(){
        Inner inner = new Nesting().new Inner();
    }
}

匿名类只能访问final变量

变量必须是有效的final

当一个匿名类被定义在一个方法中，它可以访问局部变量如果该变量是final的。但这说的有点模糊。它们不得不声明成final,他们还必须是有效final。这也是Java 8中发布的一些特性。你不需要声明这些变量为final型，但它们仍然必须是有效的final。

Java 8并不要求final，只要求有效final。

为什么你需要对一些东西声明final,当它被检查必须是这样的。就像方法的参数。它们也必须是final的。你说这不是Java所必须的吗?嗯,你是对的。这只是一个良好的编程风格所必须的。

via: http://www.javacodegeeks.com/2014/11/some-sentences-about-java.html

作者：Peter Verhas 译者：a598799539 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

Bourne Shell 的 if 语句和大部分编程语言一样 - 检测条件是否真实，如果条件为真，shell 会执行这个 if 语句指定的代码块，如果条件为假，shell 就会跳过 if 代码块，继续执行之后的代码。

if 语句的语法：

if [ 判断条件 ]
then
        command1
        command2
        ……..
        last_command
fi

Example:

#!/bin/bash
number=150
if [ $number -eq 150 ]
then
    echo "Number is 150"
fi

if-else 语句:

除了标准的 if 语句之外，我们还可以加入 else 代码块来扩展 if 语句。这么做的主要目的是：如果 if 条件为真，执行 if 语句里的代码块，如果 if 条件为假，执行 else 语句里的代码块。

语法:

if [ 判断条件 ]
then
       command1
       command2
       ……..
       last_command
else
       command1
       command2
       ……..
       last_command
fi

Example:

#!/bin/bash
number=150
if [ $number -gt 250 ]
then
    echo "Number is greater"
else
    echo "Number is smaller"
fi

If..elif..else..fi 语句 (简写的 else if)

Bourne Shell 的 if 语句语法中，else 语句里的代码块会在 if 条件为假时执行。我们还可以将 if 语句嵌套到一起，来实现多重条件的检测。我们可以使用 elif 语句（else if 的缩写）来构建多重条件的检测。

语法 :

if [ 判断条件1 ]
then
       command1
       command2
       ……..
       last_command
elif [ 判断条件2 ]
then
        command1
        command2
        ……..
        last_command
else
command1
command2
……..
last_command
fi

Example :

#!/bin/bash
number=150
if [ $number -gt 300 ]
then
    echo "Number is greater"
elif [ $number -lt 300 ]
then
    echo "Number is Smaller"
else
    echo "Number is equal to actual value"
fi

多重 if 语句 :

If 和 else 语句可以在一个 bash 脚本里相互嵌套。关键词 “fi” 表示里层 if 语句的结束，所有 if 语句必须使用 关键词 “fi” 来结束。

基本 if 语句的嵌套语法：

if [ 判断条件1 ]
then
        command1
        command2
        ……..
        last_command
else
if [ 判断条件2 ]
then
        command1
        command2
        ……..
        last_command
else
        command1
        command2
         ……..
         last_command
      fi
fi

Example:

#!/bin/bash
number=150
if [ $number -eq 150 ]
then
   echo "Number is 150"
else
if [ $number -gt 150 ]
then
    echo "Number is greater"
else
    echo "'Number is smaller"
   fi
fi

via: http://www.linuxtechi.com/shell-scripting-checking-conditions-with-if/

作者：Pradeep Kumar 译者：ThomazL 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

我有时候会听到我们的团队成员这样议论：

"项目的Code review 只是浪费时间。"

"我没有时间做Code review。"

"我的发布时间延迟了，因为我的同事还没有完成我代码的Code review。"

"你相信我的同事居然要求我对我的代码做修改吗？请跟他们说代码中的一些联系会被打断——如果在我原来代码的基础之上做修改的话。"

(LCTT 译注：Code Review中文可以翻译成代码审查,一般由开发待review的代码的成员以外的团队成员来进行这样的工作。由于是专业术语，没有将Code review用中文代替。)

为什么要做Code review？

每个专业软件开发者都有一个重要的目标：持续的提高他们的工作质量。即使你团队中都是一些优秀的程序员，但是你依然不能将你自己与一个有能力的自由职业者区分开来，除非你从团队的角度来工作。Code review是团队工作的一个重要的方面。尤其是：

代码复查者(reviewer)能从他们的角度来发现问题并且提出更好的解决方案。

确保至少你团队的另一个其他成员熟悉你的代码，通过给新员工看有经验的开发者的代码能够某种程度上提高他们的水平。

公开reviewer和被复查者的想法和经验能够促进团队间的知识的分享。

能够鼓励开发者将他们的工作进行的更彻底，因为他们知道他们的代码将被其他的人阅读。

在review的过程中的注意点

但是，由于Code review的时间有限，上面所说的目标未必能全部达到。就算只是想要打一个补丁，都要确保意图是正确的。如果只是将变量名改成骆驼拼写法(camelCase)，那不算是code review。在开发过程中进行结对编程是有益处的，它能够使两个人得到公平的锻炼。你能够在code review上花许多时间，并且仍然能够比在结对编程中使用更少的时间。

我的感受是，在项目开发的过程中，25%的时间应该花费在code review上。也就是说，如果开发者用两天的时间来开发一个东西，那么复查者应该使用至少四个小时来审查。

当然，只要你的review结果准确的话，具体花了多少时间就显得不是那么的重要。重要的是，你能够理解你看的那些代码。这里的理解并不是指你看懂了这些代码书写的语法，而是你要知道这段代码在整个庞大的应用程序、组件或者库中起着什么样的作用。如果你不理解每一行代码的作用，那么换句话说，你的code review就是没有价值的。这就是为什么好的code review不能很快完成的原因。需要时间来探讨各种各样的代码路径，让它们触发一个特定的函数，来确保第三方的API得到了正确的使用(包括一些边缘测试)。

为了查阅你所审查的代码的缺陷或者是其他问题，你应该确保：

• 所有必要的测试都已经被包含进去。
• 合理的设计文档已经被编写。

再熟练的开发者也不是每次都会记得在他们对代码改动的时候把测试程序和文档更新上去。来自reviewer的一个提醒能够使得测试用例和开发文档不会一直忘了更新。

避免code review负担太大

如果你的团队没有强制性的code review，当你的code review记录停留在无法管理的节点上时会很危险。如果你已经两周没有进行code review了，你可以花几天的时间来跟上项目的进度。这意味着你自己的开发工作会被阻断，当你想要处理之前遗留下来的code review的时候。这也会使得你很难再确保code review的质量，因为合理的code review需要长期认真的努力，最终会很难持续几天都保持这样的状态。

由于这个原因，开发者应当每天都完成他们的review任务。一种好办法就是将code review作为你每天的第一件事。在你开始自己的开发工作之前完成所有的code review工作，能够使你从头到尾都集中注意力。有些人可能更喜欢在午休前或午休后或者在傍晚下班前做review。无论你在哪个时间做，都要将code review看作你的工作之一并且不能分心，你要避免：

• 没有足够的时间来处理你的review任务。
• 由于你的code review工作没有做完导致版本的推迟发布。
• 提交不再相关的review，由于代码在你review期间已经改动太大。
• 因为你要在最后一分钟完成他们，以至于review质量太差。

书写易于review的代码

有时候review没有按时完成并不都是因为reviewer。如果我的同事使用一周时间在一个大工程中添加了一些乱七八糟的代码，且他们提交的补丁实在是太难以阅读。在一段代码中有太多的东西要浏览。这样会让人难以理解它的作用，自然会拖慢review的进度。

为什么将你的工作划分成一些易于管理的片段很重要有很多原因。我们使用scrum方法论(一种软件开发过程方法)，因此对我们来说一个合理的单元就是一个story。通过努力将我们的工作使用story组织起来，并且只是将review提交到我们正在工作的story上，这样，我们写的代码就会更加易于review。你们也可以使用其他的软件开发方法，但是目的是一样的。

书写易于review的代码还有其他先决条件。如果要做一些复杂的架构决策，应该让reviewer事先知道并参与讨论。这会让他们之后review你们的代码更加容易，因为他们知道你们正在试图实现什么功能并且知道你们打算如何来实现。这也避免了开发者需要在reviewer提了一个不同的或者更好的解决方案后大片的重写代码。

项目需要应当在设计文档中详细的描述。这对于一个项目新成员想要快速上手并且理解现有的代码来说非常重要。这从长远角度对于一个reviewer来说也非常有好处。单元测试也有助于reviewer知道一些组件是怎么使用的。

如果你在你的补丁中包含的第三方的代码，记得单独的提交它。当jQuery的9000行代码被插入到了项目代码的中间，毫无疑问会造成难以阅读。

创建易读的review代码的另一个非常重要的措施是添加相应的注释代码。这就要求你事先自己做一下review并且在一些你认为会帮助reviewer进行review的地方加上相应的注释。我发现加上注释相对于你来说往往只需要很短的时间(通常是几分钟)，但是对于review来说会节约很多的时间。当然，代码注释还有其他相似的好处，应该在合理的地方使用，但往往对code review来说更重要。事实上，有研究表明，开发者在重读并注释他们代码的过程中，通常会发现很多问题。

代码大范围重构的情况

有时候，有必要重构一段代码使其能够作用于多个其他组件。若是一个大型的应用要这样做，会花费几天甚至是更多的时间，结果是生成一个诺大的补丁包。在这种情况下，进行一个标准的code review可能是不切实际的。

最好的方法是增量重构你的代码。找出合理范围内的一部分改变，以此为基础来重构。一旦修改和review完成，进入第二个增量。以此类推，直到整个重构完成。这种方法可能不是在所有的情况下都可行，但是尽管如此，也能避免在重构时出现大量的单片补丁。开发者使用这种方式重构可能会花去更多的时间，但这也使得代码质量更高并且之后的review会更简单。

如果实在是没有条件去通过增量方式重构代码(有人可能会说之前的代码书写并组织的是多么的好)，一种解决方案是在重构时进行结对编程来代替code review。

解决团队成员之间的纠纷

你的团队中都是一些有能力的专家，在一些案例中，完全有可能因为对一个具体编码问题的意见的不同而产生争论。作为一个开发者，应该保持一个开发的头脑并且时刻准备着妥协，当你的reviewer更想要另一种解决方法时。不要对你的代码持有专有的态度，也不要自己持有审查的意见。因为有人会觉得你应该将一些重复的代码写入一个能够复用的函数中去，这并不意味着这是你的问题。

作为一个reviewer，要灵活。在提出修改建议之前，考虑你的建议是否真的更好或者只是无关紧要。如果你把力气和注意力花在那些原来的代码会明确需要改进的地方会更加成功。你应该说"它或许值得考虑..."或者"一些人建议..."而不是”我的宠物都能写一个比这个更加有效的排序方法"。

如果你真的决定不了，那就询问另一个你及你所审查的人都尊敬的开发者来听一下你意见并给出建议。

via: http://blog.salsitasoft.com/practical-lessons-in-peer-code-review/

作者：Matt 译者：john 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出