我的code review规则

标签: tech | 发表时间:2011-09-21 11:43 | 作者:admin vento
分享到:
出处:http://sunxiunan.com
1) 是否有语法错误,编译错误,编译警告。
做法:下载最新代码,将编译警告级别提升到最高,检查output信息。

2)是否符合需求,完成requirement文档要求的内容,不能多,也不能少。
注意:即使发现有问题代码,如果与需求关联不大,不要涉及。
应该让每次enhancement和bug fix最简洁,牵涉范围最小,影响到组件最少。

3)是否符合编码规范:
	a) 注意等号前后,操作符前后的空格和tab,行尾不要有多余空白字符
	b) 注意命名规范,少用缩写形式,少用2/3/ex这种增强版
	c) 对于循环局部变量,注意少用I,j在较长代码中(三四行OK)
	d) ..

4)代码美感
	a) 不能有嵌套的if-for-switch-while出现
	b) 不能有非常复杂的条件判断表达式(用于if-while之类)
	c) 足够的注释,对于复杂操作,对于条件判断,可以注释。尽量让代码自己说明自己。
 	d) 如果代码不能在短时间内理解,或者稍作解释就可以理解,应该看看能否有更简洁的方式
	e) 函数不要过长,不能超过一屏显示,最多不应该超过2-3屏。
	f)经常问自己是否有更好的办法,更简洁明了的代码形势
	g) 一个函数只做一件事,如果需要多个功能,再写一个
	h) 少用boolean 作为参数切换功能,用withXXXcase, usingXXXcondition函数名字来自说明。道理同g)
	i) 少用重载功能,没必要类似函数用一个名字,既然有不同函数实现,那么应该有不同条件描述,可参考h)的命名
	j) 抽象层次不要过多,不要过早和过多考虑设计模式/抽象/抽取通用功能这些事情,这些在代码重构阶段可以修改调整。

5)逻辑
	a) 参考上一条4),基本上有足够美感的代码,逻辑上问题都不大

6)杂项
	a) 性能的关注应该基于profiling data,而不是猜测
	b) 代码的正确与否,不是基于猜测而是基于test case
	c) 扩展性不需要考虑过多,有一点点就好
	d) 时时问自己,这个函数/变量/逻辑判断/.. 有没有必要,是不是可以删掉的
	e) 时时问自己,如果不用手动测试,自动化测试自己这段代码,可以不可以?如何实现?(MEF or 数据界面分离… )可否通过脚本、工具自动化某些流程?

相关 [code review] 推荐:

聊聊Code Review

- - 梦想风暴
hopesfish评论《 那一点的调用》时,问了一个关于Code Review的问题:. 想请教一下,TW的筒子是如何做code reivew或者鼓励客户做code review的. 我在翻阅博主的帖子的时候,似乎对这块没有特别强调,而是更多偏重于TDD,我觉得TDD的问题是一碰到没有责任心的程序猿,就很容易流于形式了.

Java Code Review清单

- - ImportNew
使用可以表达实际意图(Intention-Revealing)的名称. DRY(Don’t Repeat Yourself)原则,(拒绝重复). 用代码来解释自己的做法(译者注:即代码注释). *参考自: http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238.

我的code review规则

- vento - 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员
1) 是否有语法错误,编译错误,编译警告. 做法:下载最新代码,将编译警告级别提升到最高,检查output信息. 2)是否符合需求,完成requirement文档要求的内容,不能多,也不能少. 注意:即使发现有问题代码,如果与需求关联不大,不要涉及. 应该让每次enhancement和bug fix最简洁,牵涉范围最小,影响到组件最少.

Code Review那些事儿

- - 非技术 - ITeye博客
       曾经有一段 垃圾代码放在我的面前,我没有拒绝,等我真正开始接手的时候我才后悔莫及,程序员最痛苦的事莫过于此. ---------改编于周星星的经典台词.       虽然有点夸张,但编码界确实大大存在这种情况,每当接手别人的代码,都有一种想重新写一遍的感觉,等到别人再来接手你的代码时,同样的感觉.

[原]强制 code review:reviewboard+svn 的方案

- - 赖勇浩的编程私伙局
赖勇浩( http://laiyonghao.com). 我们团队在开发《天下盛境》项目的时候,制定和执行了比较好的 code review 策略,总结下来有几个优点:一是代码风格可控,代码质量有一定提升;二是新员工入职后能够得到更多人的指导,成长非常快;三是小 bug 频出的情况比我做《天》之前的项目少了至少一个数量组.

代码审查(Code Review)清单

- - 博客 - 伯乐在线
代码审查可以帮助提高代码质量,避免由于代码习惯而造成的 bug. 下面列出的这些要点因该可以作为大部分代码审查的指导,如果是 Java 应用的话,这些建议应该被视作最佳实践. Javadoc 应该在每一个类和方法中添加. 如果是修复某个 bug,应该添加 bug ID. 走捷径的方法或者复杂的逻辑要有解释.

从Code Review 谈如何做技术

- - 酷 壳 - CoolShell.cn
(这篇文章缘由我的微博,我想多说一些,有些杂乱,想到哪写到哪). 这两天,在微博上表达了一下Code Review的重要性. 因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录.

我们该如何做好Code Review?

- - SegmentFault 最新的文章
我们该如何做好Code Review?. 午后的阳光,静静地照在你的脸上. 这时候配上一杯82年的java,脑子一片灵光闪过,呃......上午刚写完需求,下午好像没什么事了,不如看看自己写的代码. 至此,一场Code Review也就拉开序幕了. Code Review,即代码审查,是指对计算机源代码系统化地审查,常用软件同行评审的方式进行,其目的是在找出及修正在软件开发初期未发现的错误,提升软件质量及开发者的技术.

测试技术中CODE REVIEW的重要性

- - CSDN博客推荐文章
        [近期关注App自动化测试,欢迎交流,本博客文章版权归作者所有,转载请联系]     .         最近有网上的朋友向我咨询作为测试员是否应该跳槽,   首先我觉得应该向大家介绍一下什么是测试工程师,  什么是测试员,   在国内的一些中型企业并没有特别的指明.   这里测试工程师主要指测试开发工程师, 主要包括两类,  其一是测试软件开发的工程师,  其二是自动化测试脚本开发和维护的工程师,   而测试员主要指单纯编写/管理测试用例,  或是手工测试人员, 一些国内的大中型网络视频公司仍然在用纯手工测试,我感觉到很汗颜.