标签 Solaris 下的文章

Review Board的几点使用体会

近期产品线研发体系正式将Review Board这款优秀的基于Web的代码评审开源工具引入到开发过程中,作为产品线内各项目组进行代码评审的辅助工具。我对Review Board近两年多的关注总算没有白费,算是有了一个还算不错的结果。不过Review Board的正式使用并不代表一种结束,反而恰恰是一个新的开始。我们下一步要关注的是如何用好Review Board,让它真真正正地为改善产品质量和开发效率出力。

在“关于在线代码评审的几点考量”这篇博文中我提到了在线代码评审工具在开发过程中所处的角色、使用时机以及使用时的注意事项,不过当时也多是凭直觉有感而发。真正用了Review Board这样的评审工具后,有些想法还要进一步细化。

的确,我们在近一个多月的使用过程中发现了许多问题,在公司内部我把这些问题以及解决方法整理成了一页Wiki Page放到了产品线的知识库中,这里我也和大家分享一下。

下面是我整理的关于如何用好Review Board的一个Tips列表:

* 务必保持每个Review Request内容的内聚性
如果你提交一个Review Request,其中包含了对A库的bugfix,给B库增加一个新feature,以及对C库重构的一段代码,那你的这个Review Request就是不合格的。该Request内容上包含了三个不相干的内容,严重缺乏内聚,这会给后续评审带来不良影响,诸如评审者关注点分散,效率下降;评审者不愿理睬这种Request等等。对于上述的问题Request,建议拆分为三个Request,让每个Request内容单一内聚。

* 请为你的Review Request设定评审结束时间
切记为每个Review Request设定一个有效评审时间范围,否则你的评审将被视为永远有效,这样的Request久而久之就会变成"塑料制品垃圾"塞满你的Dashboard。由于Review Board上似乎没有设定评审截止时间的位置,所以一般可在Description中增加该Request对应的评审结束时间,例如加上:
"评审截止时间:2011-03-07 12:00"

* 保持你的Dashboard Clean,别忘了关闭你的Review Request
使用Review Board一段时间后,你就会发现你的Dashboard中有很多Incoming和Outgoing的 Requests,让人心生不悦。建议大家在Request评审完毕或过期后关闭你发起的Request,保持Dashboard的clean。

在每个Request里有一个close标签,下面有三个选项:
 - summited 表示评审结束,代码已经提交,不须继续评审
 - discarded 丢弃的评审请求
 - delete permanently 应该删除的请求
一般我们会用到summited。

* 请为评审请求选择适当的干系人列表
每个评审请求都应该有特定的干系人列表,不要泛泛的发给Review Board系统中设定的所有Group。否则你既不会收到那些不相干人的有效的评审,还干扰了对方的工作。

一般来说发起代码评审请求前先要明确此次评审的目的,无非以下几种或它们的组合:
 - 希望相关干系人找出代码中的代码逻辑缺陷;
 - 希望相关干系人找出代码中的业务逻辑缺陷;
 - 分享你的代码,将你的代码中的美展现给大家。
明确了目的之后,想必你就应该清楚干系人列表中究竟该有谁了。

* 请评审者聚焦本次Request中的变动
在Review Board实际使用过程中,常常发现这样的情况:某位同事发起一段针对遗留代码修改的评审请求。很多评审者给出的一些评审意见针对的却并非是本次修改的代码,而是此次变更源码文件中的其他代码。这样可能会导致下面两个问题:
 - 提交Request的评审人很可能无法修正非本Request之外的代码问题;
 - 评审过程可能因此被拉长,很可能无法在截止时间内完成此次评审,甚至可能反复多次,造成效率上的浪费。
针对这种情况,我们建议评审者聚焦本次改动。如果评审过程中发现其他非本次改动相关的问题,可通过向代码所在的项目的Todolist或某种问题跟踪系统提交一个issue/ticket,后续由该项目的主维护者统一安排处理。

最后说说post-review这个工具的使用。Review Board的原理其实就是评审diff文件。一般情况下大家通过Review Board提供的web页面提交自己手动生成的diff文件,这种方法无可厚非。不过Review Board官方还推荐使用另外一种更有效率的方法,那就是使用post-review脚本发起Review Request。以下内容描述了工作中常见的三种使用post-review工具的情形,前提是你已经将post-review安装到你的主机上了。

* 在代码Commit前发起评审请求
有些时候,项目要求代码未经评审不允许commit到Code Repository中,这种情况我们称之为pre-commit review。这种情况下可以这样来发起一个Review Request,先在你的本地代码库拷贝中完成对代码的修改,然后进入到你的本地代码目录,执行:
post-review –server=http://xxx.xxx.xxx.xxx/reviews

post-review就会将当前目录以及其子目录下所有变更作为一个diff提交到Review Board形成一个Request Draft等待你的发布。当然你也可以通过post-review直接设定Request的Descripton等字段,并可通过增加–publish参数立刻发布该Request。

* 代码commit后发起评审请求
有些时候,某些代码是在提交到Code Repository后才评审的,这种情况我们称之为post-commit review。我们可通过版本库的revision number间的差异来构造Review Request,具体方法如下:
post-review –server=http://xxx.xxx.xxx.xxx/reviews –revision-range=n:m –branch=YOUR_REPOSITORY_PATH
当然你也可以不指定–branch,不过需要在你本地代码库拷贝目录下执行post-review。

* 更新已存在的评审请求
已经提交到Review Board的请求经过评审后,可能需要你再次修改代码并更新diff文件以继续评审。这时你可以通过指定已存在的Review Request id的方式更新已存在Request的diff,方法如下:
post-review –server=http://xxx.xxx.xxx.xxx/reviews ….. –review-request-id=58

注意,如果你的unix/linux账户下设置了http_proxy环境变量,那么在执行post-review之前需要将http_proxy设置为空,否则post-review的请求将被代理拦截而失败。

部门里越来越多的人开始关注和使用Review Board了,好趋势,可喜可贺!

又遇字节序问题

今天上午处理了一个线上产品的故障。分析来分析去,最后定位问题还是出在字节序转换的环节上。

其实测试组早在产品上线前就曾报告了这个问题,但是对应的开发人员并未对该问题进行深入地分析,而是有些草率地将该问题归结为客户端模拟器的实现不符合标准。因为这位同事比较资深,所以当时我也没有给予足够关注。

产品今天凌晨上线,9点左右业务量开始增大,这个问题立即就被我们在现场的运维人员发现,还好我们的系统是集群式的,运维同事及时的将线上有问题的版本停掉,用其他服务器支撑起了全部业务,躲过一劫。

我们还是回到这个问题上来。经验告诉我们:严重的问题往往都是由极其简单的错误导致的。这次也不例外!问题的直接原因就是:多调用了一次htonl。的确就是这么简单,但如果继续深入下去,我们还能得到一些收获。

当产品运行在x86服务器上,这个问题就会暴露出来,但是在Sun Sparc服务器上,该产品运行良好。我们分析后的结论是:这是由于在两种体系结构上htonl的实现不同而导致的。

我们先来做个试验,看下面的代码和执行结果:

/* testhtonl.c */
#include "stdio.h"
#include "arpa/inet.h"

int main() {
    unsigned int a = 0×12345678;
    unsigned int b = htonl(a);

    printf("0x%x\n", b);
    printf("0x%x\n", htonl(b));
   
    return 0;
}

将上面代码分别在x86和Sparc上编译运行。在x86上(ubuntu 10.04 Gcc 4.4.3 x86)运行的结果如下:
0×78563412
0×12345678

而在Sparc上(Solaris 10 for Sparc, Gcc 3.4.6)运行的结果如下:
0×12345678
0×12345678

由此我们可以看出,htonl这个接口并不总等价于字节序转换。在Sparc这种Big-endian体系结构的平台上,htonl相当于直接将参数值返回;而在x86这样的little-endian体系结构平台上,htonl则是等价于一个reverse_byte_order接口,每次调用都会把输入参数的byte order倒转后的结果返回。

还回到我们的那个问题中:多调了一次htonl在Sparc平台上没有什么影响;但是在x86平台上,我们得到了相反字节序的结果,导致故障的出现。

这不是我们第一次遇到字节序问题了,不过却是第一次在线上产品中遇到,上一次是在开发过程中遇到的。这次发生的问题并不仅仅是技术上的问题,更多的是在工作的严谨性和工作态度上出现问题了。对我来说,这是一个很值得吸取的教训。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 图片广告位1 图片广告位2 图片广告位3 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats