您的位置： >>
　　对于很多公司来说，代码审查是开发人员日常工作中的重要环节。通过代码审查，可以及早发现项目中存在的问题、促进同事之间的沟通与交流，并且可以在讨论中迸发出智慧的火花。但要想成功实施代码审查却并不是一件轻松的事情，为什么要进行代码审查、何时做、如何做，这是摆在我们面前的3个重要问题。针对于这3个问题，开发者撰文谈到了自己的经验与教训。
在我最近的项目经历中，我们进行了广泛且正式的代码审查。这个过程极大地改进了项目的代码质量，降低了项目中新特性开发的等待时间，同时还促进了知识在整个团队间的传播与共享。我还发现代码审查并不会延误项目开发的时间，反而会提升开发人员的生产力。
　　代码审查的好处
　　我们发现代码审查对于项目的各个阶段都会带来很多好处：
在项目起始阶段进行代码审查会帮助我们更好地使用已经建立起来的代码基，因为如果我们没有使用过某些现有代码，那么可以从当前的开发者中获得反馈信息。
在项目进行过程中，我们会时不时地向团队增加新的开发人员，代码审查可以极大地降低这些新加入人员的熟悉时间。特别地，我们可以让新加入的开发人员很有信心地开发新特性，因为我们可以在合并前审查代码并且对于他们所编写的任何代码提供有价值的反馈信息。
对于我们这个分布式团队来说，代码审查更加具有实际意义。团队协同在构建协作环境上会带来很大的帮助作用，我们可以即时提出想法，然后讨论，再进行开发。虽然由于不在同一地点我们会失去一些东西，不过我们却可以在代码审查过程中通过深入的讨论来获得好处。
　　高效代码审查的技巧
　　代码审查的方式如果处理不当可能会导致项目延期。使用正确的工具与技术可以防止在审查上浪费大量的时间，提升代码的品质。
　　使用特性分支
　　这个实践的好处就不用多说了，不过它对代码审查提供了更加具体的好处。特性分支意味着你可以将需要审查的代码隔离到只与某个具体的特性相关。在代码已经准备好了审查时，特性分支还考虑到了快速的上下文切换。在当前的代码进行审查时，你可以切换到新的特性上来，如果需要对审查特性的反馈进行讨论时还可以快速切换回来。
　　将审查隔离为小的修改
　　相对于大的修改来说，小修改的审查时间会更少。在审查大的修改时，你不仅要看很多行代码，还要查看大量的依赖代码才能真正理解，结果就是花在审查代码上的时间与修改的代码量之间并不是呈线性关系。将待审查的代码隔离为小的修改可以降低审查者的精神负担并让审查过程更加顺畅。
　　使用专门为代码审查而设计的工具
　　这看起来似乎很简单，但却非常重要。一些重要的特性需要包含差异比较、能够逐行注释修改，并且在审查的代码发生改变时通知大家。我所在的团队使用GitHub来管理项目代码，并且使用GitHub的pull request特性来管理代码审查。
　　检查清单
　　可能没必要使用非常复杂或是过于结构化的东西，如果突然出现了某些问题，使用检查清单或许是个不错的主意。
　　有建设性的输入
　　类似于&多加点注释&这样的话显得太没意义了，帮助也不大。假如某个接口没有注释，但也许有专门的文档用来说明呢。如果发现了某些不合理的地方，那就要明确指出来，判断设计上是否能改进或是逻辑上是否存在着错误。
　　要把精力放在真正理解代码的行为上，确保当其他人需要维护它时也能够快速理解代码。
　　人人参与
　　即便是最有经验的架构师或是明星开发者也会犯错。因此，最好每个人都能参与到代码审查的过程中来。特别地，对于很多初级开发者或是新加入项目的开发者来说，这也是个很不错的学习机会。
　　要有审查流程
　　一开始，我们的项目并没有正规的审查流程。我们只是开启一个pull request，等待有人来审查，最后会有人合并修改。这种工作方式效率非常差，有时好几天都没人审查一个pull request，有时一个人给出反馈前其他人却合并了请求。此外，有些开发者审查的代码量要比其他人多不少。总而言之，没有流程导致我们的效率极低。
　　最后我们认识到了这一点，创建了一个正式的结构来指导该如何进行代码审查，这加速了审查的效率。一个审查过程至少应该涵盖如下几点：
如何将审查任务分派给不同的人
期待审查者给出反馈的最迟时间
如何标识某个审查已经完成
谁负责合并已经完成审查的代码
　　我在项目中是否应该进行代码审查？
　　我认为代码审查对于很多项目来说都是一件好事，不过它也并非通用的解决方案。代码审查适合于如下这些项目：
至少有5名开发人员
在向团队增加新的开发人员时
团队是分布式的
项目有各种不同的组件构成，这些组件是由不同团队开发的
当还处在为代码基设定约定以及最佳实践的阶段
团队中有些成员对于当前所使用的技术栈还不太熟悉时
　　相反，代码审查在如下的情形中并不会为项目带来更多的附加值：
处理的是维护代码而不是添加新的特性
团队很小且亲密无间
软件工程热门文章
软件工程最新文章中国领先的IT技术网站
51CTO旗下网站
代码审查：ThoughtBot官方给出的代码审查指导原则
这篇文章的内容由ThoughtBot在github上官方主页提供，指导你如何在github上进行代码审查和如果让别人审查自己的代码。
作者：佚名来源：外刊IT评论| 10:11
这篇文章的内容由ThoughtBot在github上官方主页提供，指导你如何在github上进行代码审查和如果让别人审查自己的代码。
针对所有人的审查
接受这样的事实：很多编程上的主张都是一种个人观点。应该讨论它们的利与弊，提出你的倾向观点，迅速的达成一种解决方案。
提问，而不是命令。(&把这个变量命名成:user_id你觉得怎样？&)
请求说明。(&我不明白。你能解释一下吗？&)
避免代码的归属之争。(&我的&，&不是我的&，&你的&)
避免使用一些会被认为是有关人身特征的词语。(&笨蛋&，&愚蠢&)要把所有人都看作是有魅力的、聪明的、善意的。
要明确。要记着并不是每个人都能理解你的意图。
要谦虚。(&我不能确定&&我们来分析一下。&)
不要用夸张修辞语。(&总是&，&从不&，&永远&，&毫无&&)
不要讽刺。
展现真实的你。如果你不是幽默型的人，不喜欢使用一些表情符号或动画gif图，不要勉强。如果你是这种人，请自信的发挥。
如果有太多的&我不理解&或&另一种方案：&的评论，请专门针对这个人进行交流。可以把你们线下的交流总结成一个帖子附在后面。
让别人审查你的代码
对审查者的建议表示感激。(&谢谢提醒。我会把它改正。&)
理解审查是对事不对人。审查的是你的代码，而不是你。
解释为什么代码写成这样。(&因为xxx原因我才写成这样。如果我把这个类/文件/方法/变量改个名会更清晰些吗？&)
整理所作的改动，在以后的迭代中重构它们。
在做修改的版本上注明代码审查的链接。(&Ready for review: )
push提交要基于最早的一轮反馈，并形成一个独立的分支。等这个分支上的任务完全完成了再合并。这让审查者能够根据早先的反馈找到你的单独的更新。
努力站在审查者的立场上理解。
争取回复每个评论。
直到最后一个人退出登录后再合并分支。
直到持续集成测试(TDDium, TravisCI,等)告诉你这个分支的测试套件通过后再合并分支。
代码审查的过程
先要清楚你提交的代码的必要性(是修补bug，提升用户体验，重构&)。然后：
针对你感觉非常好的地方以及不是很好的地方与作者交流。
找出既能解决问题又能简化代码的方法。
如果讨论变得过于哲学或理论，把讨论转到线下，做成一个有规律的每周五下午的讨论会。同时，是否采用你提出的实现方案，让作者自己做决定。
提出你的实现方案，但要表现出作者也在考虑这种方案。(&你觉得这里用一个自定义校验如何？&)
努力理解作者的立场。
pull请求登出时，加一个:thumbsup:或&可以合并了&的注释。
关于程序风格样式的评论注释
审查者应该对那些不符合指导的地方进行注释。例如这样注释：
[Style](../style): &&&按名称的字母顺序排列多个路由。&
对上面这个提醒的一个回复的例子：
哦。你眼真尖，谢谢。已在&a4994ec&修复。&
如果你不同意某个指导原则，请在指导repo里创建一个问题，而不要再代码审查中争论它。同时，请运用这个指导原则。
英文原文：
译文链接：【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
外电头条外电头条外电
24H热文一周话题本月最赞
讲师：1人学习过
讲师：35人学习过
讲师：0人学习过
精选博文论坛热帖下载排行
本书专门根据SUN官方的SCSA for Solaris 9&10考试大纲撰写而成，全面覆盖了SCSA for Solaris 9/10的认证考点，除此之外本书还有大量的非考...
订阅51CTO邮刊}