Code Review最佳实践

Code Review最佳实践

• 原文连接 : 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 maintainable 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，相信咱们会在各方面有很大的提高。