关于在线代码评审的几点考量
来源:互联网 发布:中国经济数据统计 编辑:程序博客网 时间:2024/06/05 06:15
记得上次折腾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发给相关干系人,以获得全面的评审,避免死角。
以上是目前关于在线代码评审的一些考量,这里记之以备忘。
- 关于在线代码评审的几点考量
- 关于代码审查的几点建议
- 关于代码测试的几点思考
- 关于代码审查的几点建议
- 关于代码评审
- 关于代码评审
- 关于代码性能优化的几点建议
- 代码评审的真相
- 关于代码评审的微博讨论汇集
- 性能考量的代码编写约束
- 针对应用开发者的几点建议:注意特征蔓延、加大用户评审……
- 关于grub的几点
- 关于优化的几点
- 关于接口的几点
- 关于css的几点
- 关于提高效率的几点
- 关于HTTP的几点
- 关于getline的几点
- Java正则表达式的语法与示例
- Android 图片先gzip压缩然后在Base64转成字符串
- Python中替换元素
- Javaweb学习总结15:JSP基础语法
- ORACLE集群概念和原理
- 关于在线代码评审的几点考量
- Python之创建tuple
- CentOS7安装,dracut-initqueue timeout 等各种问题
- javascript权威指南(6)随笔
- mybatis编写POJO包装类型扩展parameterType字段
- html中alt和title属性的用法和区别
- Mybatis配置文件之plugins使用
- Android 微信支付,支付成功后不回调WXEntryActivity方法问题
- Spark与Hadoop