每当从各种公司听到他们正在尝试自动化部署/测试的事情,我都非常关注,但通常会很吃惊,他们很少会考虑去实行代码审查制度。
看到这种情况,我通常想问:如果代码没有经过其它人的审查,你如何知道你要测试的是什么?这答案(如果有的话)通常是捏着手指头说有几个人在做代码审查或“正在考虑中”。
没有代码审查?真的吗?不可思议?!?
代码审查不是可有可无的。
不论你采用什么形式的测试过程,什么形式的部署过程,没有代码审查——game over。为什么?因为代码的质量是一种人能看懂的质量。不管你如何测试,有如何严谨的部署流程,只有当另外一个人看了这些代码,并且表明能看懂时,这些代码才有意义。如果看不懂,你认为这样的代码——虽然测试通过、部署符合流程——可以上线吗?
没有经过代码审查,测试说明不了任何问题。测试通过但没有经过代码审查的代码仍然是有bug的。
什么是代码审查?
请参考谷歌是如何做代码审查的。
设计中使用的“走廊UX测试”是说:在开始实现你的设计前,至少需要有一个人看过你的设计。代码审查是相同的道理。
代码审查是说:在把你的代码合并到代码库里之前,请至少找一个人看看你的代码。
如何进行代码审查?
下面是代码审查基本的步骤:
- 把身体向左转。
- 看到另外一个程序员?拍拍他的肩膀。
- 让他看你的显示器。
- 说:这代码你能看懂吗?我打算把它提交到代码库里。
- 听他的建议。
- 自己做决定:是应该修改一下,还是继续提交到代码库里。
就这样。
现在,我想告诉你,有大量的代码审查工具可以使用。它们都能高度的自定义配置。它们的作用都是让你代码审查过程更方面、灵活。
简单的几款代码审查工具
下面是我推荐的几款简单的代码审查工具(如果你的公司的程序员少于5千人)。
- less
- diff, 或 wdiff
- GitHub pull requests
就是这些。虽然还有很多很多的代码审查工具,我很少听说哪个程序员说喜欢它们的。而我的观点,less, diff, github pull requests能解决我们正常开发中的大部分代码审查问题。
如果你的代码审查过程过于复杂,需要使用大量的工具,这说明你过分的依赖于一些不必要的形式,你应该简化它们。你可以说成你的反对的观点,或在微博上和我们讨论。
[英文原文:Do you do code review? ]
via : http://www.vaikan.com/do-code-review/
原创文章,作者:kepupublish,如若转载,请注明出处:https://blog.ytso.com/tech/linux/44737.html