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

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

暑去清凉来，一场大雨让燥热一去不复返了，这让身体舒服了许多。本周四晚有一次产品升级操作，按惯例每次升级前的都会对产品做一次针对性的回归测试，这次也不例外，不过临近下班时测试组爆出一个莫名奇妙的问题。

测试人员在BUG说明中写到：产品在只运行某个流程A的情况是正常的，但是当流程A和流程B一起运行时，就会出XX异常情况。作为开发人员遇到类似的问题第一反映多为：这怎么可能呢？这个产品已经经过N轮测试并且早前已在某个省份上线运行了近两个月，如果有此潜在的BUG应该早就暴露出来了才对。及时找到测试人员沟通，测试人员很轻松的就复现出了该BUG，眼见为实！离升级时间点已经不多了，赶紧解决吧。

使用GDB在我认定的关键代码路径上设置了断点，对测试环境下的某进程进行调试，不过无论如何发消息，代码始终没有走到该断点，这让我疑惑不已。负责维护这段代码的开发人员恰参加培训回来，用她擅长的通过调试方法-“加打印语句”又进行了一次调试，发现一些端倪，消息并未按照我们预期的流程走，问题被缩小到消息包中的一个关键字段上，通过打印发现这一字段的值与预期的值不同。我的第一反映：是否有内存污染问题，如果真有这样的问题那就严重了，一直到此时我的怀疑点也一直在产品本身上。

这时测试人员在屏幕上的抓包结果引起了我们的注意：消息包中这个字段的值与设置的不符。通过进一步在产品中的打印结果也印证了这一点。难道是模拟器的问题？记忆中模拟器已经用了一年多了，这个问题之前怎么没有暴露出来呢。我们立即换了一个其他的模拟器进行了测试，结果：流程正常。看来就是模拟器的问题了。

据测试人员说以前未暴露出该问题很可能是因为之前的测试要么只测试A流程，或要么只测试B流程，很少A和B流程一起并行测试，所以这个模拟器陷阱就没有被发现。模拟器在A和B两个流程的共同作用下出现了内存污染的bug，，将A流程中的协议包中的一个重要字段设置错了，导致产品在处理该流程消息时未得出预期结果。

这次的“模拟器陷阱”问题起码暴露出两个问题：
1、缺少对新实现的模拟器正确性的完备测试；
2、测试人员在用例设计上还有提高的余地，应避免只有单一场景的用例了。