- 原文链接 : Code Review Best Practices
- 原文作者 : Kevin London
- 译文出自 : 开发技术前线 www.devtf.cn
- 译者 : ayyb1988
- 校对者: chaossss
- 状态 : 完成
在Wiredrive上，我们做了很多的Code Review。在此之前我从来没有做过，这对于我来说是一个全新的体验，下面来总结一下在Code Review中做的事情以及说说谈论Code Review的最好方式。
简单的说，Code Review是开发者之间讨论修改代码来解决问题的过程。很多文章谈论了Code Review的诸多好处，包括知识共享，代码的质量，开发者的成长，却很少讨论审查什么、如何审查。
###审查的内容
####体系结构和代码设计
-
单一职责原则：一个类有且只能一个职责。我通常使用这个原则去衡量，如果我们必须使用“和”来描述一个方法做的事情，这可能在抽象层上出了问题。
-
开闭原则如果是面向对象的语言，对象对可扩展开放、对修改关闭。如果我们需要添加另外的内容会怎样？
-
代码复用：根据"三振法",如果代码被复制一次，虽然如喜欢这种方式，但通常没什么问题。但如果再一次被复制，就应该通过提取公共的部分来重构它。
-
换位考虑，如果换位考虑，这行代码是否有问题？用这种模式是否可以发现代码中的问题。
-
用更好的代码： 如果在一块混乱的代码做修改，添加几行代码也许更容易，但我建议更进一步，用比原来更好的代码。
-
潜在的bugs：是否会引起的其他错误？循环是否以我们期望的方式终止？
-
错误处理：错误确定被优雅的修改？会导致其他错误？如果这样，修改是否有用？
-
效率： 如果代码中包含算法，这种算法是否是高效？ 例如，在字典中使用迭代，遍历一个期望的值，这是一种低效的方式。
####代码风格
-
方法名： 在计算机科学中，命名是一个难题。一个函数被命名为==get_message_queue_name==，但做的却是完全不同的事情，比如从输入内容中清除html，那么这是一个不准确的命名，并且可能会误导。
-
值名：对于数据结构，==foo== or ==bar== 可能是无用的名字。相比==exception==， ==e==同样是无用的。如果需要(根据语言)尽可能详细，在重新查看代码时，那些见名知意的命名是更容易理解的。
-
函数长度： 对于一个函数的长度，我的经验值是小于20行，如果一个函数在50行以上，最好把它分成更小的函数块。
-
类的长度：我认为类的长度应该小于300行，最好在100内。把较长的类分离成独立的类，这样更容易理解类的功能。
-
文件的长度： 对于Python，一个文件最多1000行代码。任何高于此的文件应该把它分离成更小更内聚,看一下是否违背的“单一职责” 原则。
-
文档：对于复杂的函数来说，参数个数可能较多，在文档中需要指出每个参数的用处，除了那些显而易见的。
-
注释代码： 移除任何注释代码行。
-
函数参数个数：不要太多， 一般不要超过3个。。
-
可读性： 代码是否容易理解？在查看代码时要不断的停下来分析它？
####测试
- 测试的范围：我喜欢测试新功能。测试是否全面？是否涵盖了故障的情况【比如：网络，信号等，译者注】？是否容易使用？是否稳定？大多的测试？性能的快慢？
- 合乎规范的测试：当复查测试时，确保我们用适当的方式。换句话说，当我们在一个较低水平测试却要求期望的功能？Gary Bernhardt建议95％的单元测试，5％的集成测试。特别是在Django项目中，在较高的测试水平上，很容易发现意外bug，创建一个详细的测试用例，认真仔细也是很重要的。
####审查代码 在提交代码之前，我经常用git添加改变的文件/文件夹,然后通过git diff 来查看做了哪些修改。通常，我会关注如下几点：
- 是否有注释？
- 变量名是否见名知意？
- ...等上面提到的
和著名的橡皮鸭调试法（Rubber Duck Debugging）一样，每次提交前整体把自己的代码过一遍非常有帮助，尤其是看看有没有犯低级错误。
####如何进行Code Review 当Code Review时，会遇到不少问题，我也学会了如何处理，下面是一些方法：
- 提问： 这个函数是如何生效的？如果需求变更，应该做什么改变？怎么更容易维护？
- 表扬/奖励良好的做法：Code Review重要的一点是奖励开发者的成长和努力。得到别人的肯定是一件很不错的事情，我尽可能多的给人积极的评论。
- 当面讨论代替评论。 大部分情况下小组内的同事是坐在一起的，当面的 code review是非常有效的。
- 说明理由 ：是否还有跟好的方式，证明为什么这样做是好的。
####心态上
- 作为一个Developer , 不仅要Deliver working code, 还要Deliver maintable code.
- 必要时进行重构，随着项目的迭代，在计划新增功能的同时，开发要主动计划重构的工作项。
- 开放的心态，虚心接受大家的Review Comments。
####参考 一些关于clean code的书籍，如下：
- Clean Code
- Refactoring
- All the Small Things by Sandi Metz
- How to Design a Good API and Why it Matters
- Discussion on Hacker News
##译者注 #####一. 参考了 http://jimhuang.cn/?p=59
#####二. 国内阿里的陈皓写的关于codereview的文章，也很有见底，推荐大家看看 ######1.Code Review中的几个提示
- 先Review设计实现思路，然后Review设计模式，接着Review成形的骨干代码，最后Review完成的代码，如果程序复杂的话，需要拆成几个单元或模块分别Review
- Code Review不要太正式，而且要短
- 学会享受Code Reivew
######2.从Code Review 谈如何做技术
#####三. Code Review 工具 Review Board
#####四. 在Code Review时，要在 意识 方法 心态 习惯 这几个方面上下功夫，坚持code review，相信我们会在各方面有很大的提升。