IDO老徐,坐标深圳,测试经理,干了十年测试,公号"简尚" ,博客isTester.com ,关注「软件测试从业者综合能力提升 & 职场人每日进阶」,个人微信957863300

代码审查(Code Review)最佳实践

上一篇 / 下一篇  2016-07-25 09:40:33 / 个人分类:软件工程


Mj6W9hi3h6T6o0

如今敏捷开发盛行,代码审查非常重要;如下是转发文~

1QegwF;\P7}0

代码审查可以帮助提高代码质量,避免由于代码习惯而造成的 bug51Testing软件测试网6ef:rY*xLv-j e

下面列出的这些要点因该可以作为大部分代码审查的指导,如果是 Java 应用的话,这些建议应该被视作最佳实践。51Testing软件测试网V m+h G%G8K


I%U8cJ,W1z0

:l[H6{z6rRd0

文档

V.T wY-T&G B3Y*b5j0

%RrM+ZT0

1. Javadoc 应该在每一个类和方法中添加。

Ai"n?H-Za gh0

2. 如果是修复某个 bug,应该添加 bug ID。

E)a:o9Vy]0

3. 走捷径的方法或者复杂的逻辑要有解释。

$X.Yop B7Q0

4. 如果代码会被公开,每个文件头都要标注版权信息。

S`+I+O9~4p&q0

5. 复杂的 HTML,JavaScript,CSS 应该包含文档。

X\#ajb?1LE(c0

51Testing软件测试网Ed8QCDO;a
51Testing软件测试网-?#\(^HoLx&zDs

功能

#abq!k.VSH)co0

1. 如果类似的逻辑被使用了多次,应该把它写成一个帮助类,然后在多出调用。51Testing软件测试网OO#a2XJ(yv

2. 鼓励使用 API 而不是重复编写代码解决相同的问题。51Testing软件测试网 T+@qCmE m.Qt3m`!}

3. 要强调代码的单元测试51Testing软件测试网3bv:{!p7|-@-m E

4. 任何新加的代码不应该破坏已有的代码。51Testing软件测试网yb_? nJ"vCHg

5. 假如是 Web 应用,JSP 不应该包含 Java 代码。

F"d%}3Mf2vg0


7RM%~n^q&m'KR0
51Testing软件测试网 } k.V)P*V F@gZa

安全

(Yp8[5S7oJ^ ^-`0

1. 任何代码都不能执行用户的输入,除非转义过了。这个常常包含 JavaScript. 的 eval 函数和 SQL 语句。

/gF[ VS2X C0

2. 禁止那些在短时间内提交非常多请求的 IP。

)^*X1vJc-u J0

3. 任何类,变量,还有方法都应该有正确的访问域。

6oTr4FE,E!h#xL0

4. 尽量避免使用 iframe。

,z+s+[pJO0


!m T.X9G+r-Z1_0
51Testing软件测试网'N i ]s8XU)s6B.Om

性能51Testing软件测试网 S-mt3x ]8k)| f5{/}{&m

1. 所有数据库和文件操句柄在不需要的时候都应该被关闭。

1g$|:T.GOt]0

2. SQL 语句的写法会导致性能千差万别。

,J+FhK4d0

3. 鼓励创建不可变(immutable)的类。51Testing软件测试网9p$LJ0Er5}

4. 类似的逻辑代码,尽量通过 if else 语句来实现更多的重用。51Testing软件测试网(x+h&s5C8@B){

5. 尽量避免使用重对象(heavy objects)。51Testing软件测试网n!l@ ~(iu!O

6. 如果是 Web 项目,请检查是否使用了合适的图片尺寸,CSS sprites 和浏览器缓存等技术51Testing软件测试网+{*WlP&J_F

7. 全局都需要的信息保存在 application context 中。51Testing软件测试网 L4I#{ f4M7I


z/hA t9J#bd%{;h0
51Testing软件测试网6Pj L(jw4J

编码习惯

&F+Q.DE g8tRs$o0

1. 没有被使用的变量要删除。

Et%n,Oi g3I/x uf YA0

2. 针对不同的 Exception 要用不同的 catch 语句,而不是一个 Exception 解决所有问题。51Testing软件测试网DAV+|W,},DH

3. 针对变量,方法和类要用相同的命名方法。

6n+v Y~2pL Y0

4. 常量应该被写在独立的常量类中。

#_ p]gs0

5. 每行代码的尾部不要有多余的空格。

!ugl^8JwCH y0

6. 对于括号,循环,if语句等等要用统一的格式。51Testing软件测试网bP/Fr8\QR ~$@[

7. 每一个单独的方法不应该超过100行。51Testing软件测试网+V%w:eG7r!w-t

8. 一个单独的语句不应该超过编辑器的可视区域,它可以被拆分成几行。51Testing软件测试网~2iYq#uM

9. 检查 String 对象既不是null也不是空的最好方法是 if(“”.equals(str))51Testing软件测试网 JJd i:s h%f

10. 假如类有很多成员变量,并且实例化的时候只需要少数变量传入的话,最好使用静态工厂方法,而不是重载构造函数。51Testing软件测试网1x,h2\)|V

11. 给方法添加适当的访问控制,而不是所有都是 public。51Testing软件测试网2~1m o,X'{-@s;M

12. 遵守项目中使用的框架的最佳实践建议,例如 Spring,Struts,Hibernate,jQuery。

_Y$[Xp%c Y%jNq0


CWdraB\eC[!\0
51Testing软件测试网-Mw{anEx

以上的某些注意点可以通过静态代码检查工具完成,例如 CheckStyle,FindBugs 和 JTest。

f n^$y {0

51Testing软件测试网y9?.u9nHy(D
51Testing软件测试网;dA _S_~x4}%M$B



)d?EL4\J/T*H0

Code Review 主要Revivew什么

Architecture/Design

  • 单一职责原则.
    • 这是经常被违背的原则。一个类只能干一个事情, 一个方法最好也只干一件事情。 比较常见的违背是一个类既干UI的事情,又干逻辑的事情, 这个在低质量的客户端代码里很常见。
  • 行为是否统一
    • 比如缓存是否统一,错误处理是否统一, 错误提示是否统一, 弹出框是否统一 等等。
    • 同一逻辑/同一行为 有没有走同一Code Path?低质量程序的另一个特征是,同一行为/同一逻辑,因为出现在不同的地方或者被不同的方式触发,没有走同一Code Path 或者各处有一份copy的实现, 导致非常难以维护。
  • 代码污染
    • 代码有没有对其他模块强耦合 ?
  • 重复代码
    • 主要看有没有把公用组件,可复用的代码,函数抽取出来。
  • Open/Closed 原则
    • 就是好不好扩展。 Open for extension, closed for modification.
  • 面向接口编程 和 不是 面向实现编程
    • 主要就是看有没有进行合适的抽象, 把一些行为抽象为接口。
  • 健壮性
    • 有没有考虑线程安全性, 数据访问的一致性
    • 对Corner case有没有考虑完整,逻辑是否健壮?有没有潜在的bug?
    • 有没有内存泄漏?有没有循环依赖?(针对特定语言,比如Objective-C) ?有没有野指针?
  • 错误处理
    • 有没有很好的Error Handling?比如网络出错,IO出错。
  • 改动是不是对代码的提升
    • 新的改动是打补丁,让代码质量继续恶化,还是对代码质量做了修复?
  • 效率/性能
    • 关键算法的时间复杂度多少?有没有可能有潜在的性能瓶颈。
    • 客户端程序 对频繁消息 和较大数据等耗时操作是否处理得当。

其中有一部分问题,比如一些设计原则, 可预见的效率问题, 开发模式一致性的问题 应该尽早在Design Review阶段解决。如果Design阶段没有解决,那至少在Code Review阶段也要把它找出来。51Testing软件测试网,[4SP*a#G IoXu

Style

  • 可读性
    • 衡量可读性的可以有很好实践的标准,就是Reviewer能否非常容易的理解这个代码。 如果不是,那意味着代码的可读性要进行改进。
  • 命名
    • 命名对可读性非常重要,我倾向于函数名/方法名长一点都没关系,必须是能自我阐述的。
    • 英语用词尽量准确一点(哪怕有时候需要借助Google Translate,是值得的)
  • 函数长度/类长度
    • 函数太长的不好阅读。 类太长了,比如超过了1000行,那你要看一下是否违反的“单一职责” 原则。
  • 注释
    • 恰到好处的注释。 但更多我看到比较差质量的工程的一个特点是缺少注释。
  • 参数个数
    • 不要太多, 一般不要超过3个。

Review Your Own Code First

  • 跟著名的橡皮鸭调试法(Rubber Duck Debugging)一样,每次提交前整体把自己的代码过一遍非常有帮助,尤其是看看有没有犯低级错误。

如何进行Code Review

  • 多问问题。多问 “这块儿是怎么工作的?” “如果有XXX case,你这个怎么处理?”
  • 每次提交的代码不要太多,最好不要超过1000行,否则review起来效率会非常低。
  • 当面讨论代替Comments。 大部分情况下小组内的同事是坐在一起的,face to face的 code review是非常有效的。
  • 区分重点,不要舍本逐末。 优先抓住 设计,可读性,健壮性等重点问题。

Code Review的意识

  • 作为一个Developer , 不仅要Deliver working code, 还要Deliver maintainable code.
  • 必要时进行重构,随着项目的迭代,在计划新增功能的同时,开发要主动计划重构的工作项。
  • 开放的心态,虚心接受大家的Review Comments。

51Testing软件测试网k e+u#I7~4m_X
51Testing软件测试网j TB-Sj


TAG: 敏捷开发 代码审查

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

xuquan

xuquan

IDO老徐,坐标深圳,测试经理,干了十年测试,公号"简尚" ,博客isTester.com ,关注「软件测试从业者综合能力提升 & 职场人每日进阶」,个人微信957863300

日历

« 2020-07-11  
   1234
567891011
12131415161718
19202122232425
262728293031 

数据统计

  • 访问量: 587884
  • 日志数: 370
  • 建立时间: 2012-06-04
  • 更新时间: 2020-06-24

RSS订阅

Open Toolbar