记得上次折腾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发给相关干系人，以获得全面的评审，避免死角。

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

下班前，一位同事发来的mail中提到这样一个问题：在Solaris上，新添加到Project中的一段代码编译有Warning，由于我们在Makefile的GCC命令行中设置了"视警告如错误"的-Werror编译选项，导致了项目无法成功Build。

这个Warning内容如下：
warning: `0' flag used with `%s' printf format

产生这个Warning的那行代码大致是类似这样的：printf("%05s%06s\n", "11", "222"); 其实这段代码是从老项目中Copy出来的，在老项目中，这段代码运行的很是正常，也许它在老项目Build时也会产生Warning，不过之前大家也都没有关注。

这个Warning我以前还真未遇到过，代码看起来写的也没有问题，我在Ubuntu 10.04(GCC 4.4.3)上测试了一下这段代码，同样产生了Warning。不过执行一下编译后的程序，我发现了问题。显然这段代码的意图是想通过"%05s"这样的格式控制串来达到自动补0的目的，但是Ubuntu下输出的结果却与此预期相悖–没有补0，补的是空格。我又拿同样的代码在Solaris(Solaris 10 for x86, gcc 3.4.6)上试了一下，虽然也有Warning，但结果和预期是相符的。

这个问题显然比我预期的严重：一段代码在两个平台上产生了不同的行为，问题显然出在"%05s"的使用上。翻开《C语言参考手册》找到输入/输出函数一章，在"输出转换说明"一表中可与s转换搭配的只有'-标志'，没有'0标志'，但手册里并未明确说明如果将0标志与s转换结合会有什么后果。又Google了一下，发现一些资料里提到在printf系列接口中使用类似"%5s"这样的格式控制串的行为是未定义的，和我试验的结果一致。

考虑到可移植性，"%05s"这样的格式控制串不能再继续使用了，替代方法有多种，这里就不赘述了。如果你的代码里也有使用类似"%05s"这种格式控制串，那赶紧想办法替换掉吧，除非你的代码一直跑在Solaris上。