今天一位网上的朋友在使用reviewboard时遇到了问题，我们在评论中探讨了一下。他的问题目前已经定位，大致是这样的：他在Windows上用svn diff生成的patch文件在提交给reviewboard时出错，但在linux上生成的patch文件是没有问题的。后来他发现这两个patch文件内容稍有区别：Windows上的patch文件中的diff结果包含中文，比如“版本 10”；而在linux下生成的那份patch文件中，"版本 10"变成了"revision 10"。reviewboard拒绝了带中文的那份patch，估计是reviewboard的字符编码设置让其无法识别windows下的那个字符集。

多数情况下，我们根本无需关心svn命令输出中到底是英文还是中文。subversion对国际化支持到很好，它会根据自己所在环境下的区域和语言设置来选择到底输出哪种文字，对不同地区说不同语言的程序员来说，这绝对是一个好事。

但问题毕竟是出现了。我们该如何解决呢？我们该如何选择svn输出的语言呢？我不用Windows，所以这里我说说Linux下的设置方法，这也是今天在思考那位朋友的问题时才找到的方法。

方法的关键就在于前面说过的Subversion会自动检测你的区域和语言环境设置。以我的Ubuntu 12.04LTS为例，执行locale命令，可以看到以下输出：

LANG=zh_CN.UTF-8
LANGUAGE=zh_CN:zh
LC_CTYPE="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"
LC_TIME="zh_CN.UTF-8"
LC_COLLATE="zh_CN.UTF-8"
LC_MONETARY="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"
LC_PAPER="zh_CN.UTF-8"
LC_NAME="zh_CN.UTF-8"
LC_ADDRESS="zh_CN.UTF-8"
LC_TELEPHONE="zh_CN.UTF-8"
LC_MEASUREMENT="zh_CN.UTF-8"
LC_IDENTIFICATION="zh_CN.UTF-8"
LC_ALL=

也就是说默认情况下，我的区域是CN，语言是zh。在这种环境下svn命令的输出都是包含中文的，比如下面这段输出：

路径: .
URL: https://lcut.googlecode.com/svn/trunk
版本库根: https://lcut.googlecode.com/svn
版本库 UUID: 22405a7c-d843-be82-cc3b-46f1d7cb9705
版本: 57
节点种类: 目录
调度: 正常
最后修改的作者: bigwhite.cn@gmail.com
最后修改的版本: 57

我尝试修改locale。先将LC_ALL修改为en_US.UTF-8（通过locale -a你可以查看系统支持的locale列表，从中能看到en_US.utf8）。修改后(export LC_ALL=en_US.utf8)，执行locale，发现除了LANGUAGE和LANG还是原值外，其余变量都已经改为en_US.utf8了。不过svn info的输出结果依旧包含中文。

看来LANGUAGE或LANG两个变量中的一个会影响到svn的输出结果。先修改LANG为en_US.utf8，执行svn info，发现结果依旧包含中文。再试试修改LANGUAGE，export LANGUAGE=en_US.en（注意不是en_US.utf8，LANGUAGE变量的值与其他的变量稍有不同）。再执行svn info，这回终于等到英文结果输出了：

Path: .
URL: https://lcut.googlecode.com/svn/trunk
Repository Root: https://lcut.googlecode.com/svn
Repository UUID: 22405a7c-d843-be82-cc3b-46f1d7cb9705
Revision: 57
Node Kind: directory
Schedule: normal
Last Changed Author: bigwhite.cn@gmail.com
Last Changed Rev: 57

目前还不清楚这招在Windows下是否也生效，记得Windows上也有设置环境变量的地方。

记得上次折腾Review Board这个在线代码评审工具还是在一年前，那时的Review Board版本是1.0.3；这周部门的一位同事也在折腾Review Board，不过现在的版本已经升级到了1.5.1了。新版Review Board显然修正了许多旧版本中存在的问题，另外无法支持ssl邮件端口的问题也被我这位同事通过更换django源文件的方式搞定了。Review Board好用了，下一步需要关注的就是怎样才能用好Review Board的问题了。

一般认为代码评审是一项优秀的软件开发实践，它可以将很多隐患和bug消灭在萌芽阶段。其实践形式大致有代码走查、代码审查和结对编程（每时每刻都在做代码评审）这三种。一般来说读懂别人的代码可能比自己亲自编写代码花费的时间还要长，而且更为困难，所以除了结对编程之外，代码走查和审查都是低效的，多数情况下都是高投入低产出的，引入在线评审恰恰是对这些低效代码评审形式的一个有效补充，另外在线评审更适合异地团队和开源项目。

那么什么情况下适合发起在线Code Review Request呢？可考虑下面几种情况：
- 新增的关键功能代码的评审
- 系统改善或优化代码的评审
- bugfix代码的评审
- 一些试验性代码的可行性评审

创建一个新的Review request时应考虑注意以下几点：
- 精确描述review request，提供此次评审的重要关注点；
- 每个review request要有针对性，选择合适的评审人，不要泛泛的发给所有人；
- 明确此次评审的截止时间点；
- 每个review request所包含的待评审代码的行数最好不要超过50行，以30行以内为佳。如果你的request中包含了上千行的代码，我想是没人会去真正评审你的代码的。

在项目编码高峰期，切忌发起大量在线Review request，那样的话，大家都会"淹没"在诸多Requests中，评审质量会严重下降，评审人的热情也会受到打击^_^。这个时候我们可以考虑结合其他评审方式，如采用结对和走查。另外对于一些遗留的维护项目，由于代码历史较为"悠久"，相关干系人较多，无法确认的因素也较多，可通过在线评审方式将review request发给相关干系人，以获得全面的评审，避免死角。

以上是目前关于在线代码评审的一些考量，这里记之以备忘。