代码审查宜忌

原文地址：%20Documents/Code%20Review%20Guidelines.htm
                            代码审查宜忌
宜：
1) 使用UML图表来理解代码相互间的依赖关系，并找出他们如何有机的组成一个整体。

2) 重点关注重要的结构问题

3) 找出那些对于不经常使用代码的人不能理解代码作用的地方(找出好的归档习惯)

4) 找出那些使代码难于维护的地方

5) 找出那些使代码失去灵活性的地方

6) 找出那些降低了代码的可扩容性(scalability)的地方

7) 找出那些乱用的封装(例如不必要的get()方法和set()方法或者依赖关系等)

8) 描述你认为有问题的地方时，越详细越好。

9) 描述问题时，也是越详细越好(例如，使用“没有文档来说明某些功能的作用或者
   文件x、y和z的之间的关系”要比使用“文档不全，我不能明白代码是干什么的”好的多)

10)对于做的特别好的地方也要提出来(换成是你，听了一大堆你写的代码的问题之后，
   也想听一些对你代码的赞美之词吧)

11)对你发现的问题提供一些建设性的解决方法

12)考虑一下如果你的代码遭遇到同样的问题会怎么样，你将会怎么做去纠正这个问题

13)代码审查后对你的代码进行相应的修正

忌：
1)对代码作者进行评论或者使用不负责任的语言描述你发现的问题

2)把评审搞成个人攻击--代码审查的目的是让你改善编码习惯，同时提高被审查代码的质量

3)对是否进行某些修正陷入长时间的争论中

4)不在乎别人对你的代码的评价

5)过分关注琐碎的问题(如，出现在两个位置上的同一个问题)