原文链接：https://dsx2016.com/?p=710微信公众号：大哥2016WhatisCodeReview中文是codereview，指的是有意识地、系统地调用其他程序员检查对方的代码是否存在是错误。通常CodeReview会有以下作用：更好的代码质量，提高代码的可维护性、统一性、可理解性等。发现缺陷，发现性能问题，安全漏洞，可能的后门和恶意代码等。最佳实践，更好完成的有效途径任务和要求。知识共享，审查别人的代码，也是学习有益技术的途径之一。你想要代码审查吗？CodeReview是一把双刃剑。用得好，就会事半功倍。如果用不好，会给团队和项目带来负面影响。有些原理和技术虽然好，但要看场合和环境。核心在于因势利导、求同存异。显然，评论和其他事情一样，需要花费很多时间。对于一个任务极其紧张的团队来说，如何选择是值得思考的。审稿也需要人与人之间的交流与合作，也比较技术深度。要知道，最难对付的是人。人是懒惰的，也有自己的一套行为准则和规范。如果强加于此，很容易产生抵触情绪。最后，怎么说呢，尽量不要吃亏，不要着急。完美主义、小步骤、快速迭代难道不是软件开发的第一精髓吗？CodeReview前提条件CodeReview本身是一项后期工作，具有查漏补缺的功能。但实施它也需要一些先决条件。设定条件可以让团队更快更好地接受和执行。建立团队规范，无论是代码层面还是协作层面，比如命名规则、语法检查、分支规范等。建立一个完整的文档，方便团队和新人查阅。在内容上，大家可以共同建设和建议，不能由一个人来决定。评审流程开发，设定职责、设定周期、设定目标，从轻量级代码评审开始，建立积极的评审文化。完成了上面的基本骨架之后，就可以开始尝试复习了。这个时期通常是刀耕火种的时期，大概率会遇到各种阻力。如果实施后收益低于之前，可以适时调整放弃。如何？有效的代码审查让我们不提细节。每个团队和技术架构都有自己的规范。从一般方法层面来说，要进行有效的评审，有以下几点：400行以下代码的一次评审时间不宜超过30分钟Checklist（上面提到的团队规范文档，可以进一步细化成一定的目标清单）人的精力是有限的，了解自己的现状尤为重要。一些常见的规范和评论要素：命名可读性最好，不言自明，英文单词尽量准确（命名是所有程序员头疼的事情之一）注释，恰到好处的注释，重要地方及时注释，不需要一些注释信息应该删除。代码不仅是给机器跑的，也是给人看的。gitcommit提交规范，不标注信息，不及时commit，是严重阻碍审核的因素之一。除了例程描述信息之外，还可以按类型等进行备注：feat：新特性/fix：修改问题/refactor：代码重构/docs：文档修改/chore：其他修改/test：测试casemodification/style:codeformatmodification等等等，大家有没有发现，以上都是信息层面的做文章，这也是有效沟通的方式之一。你的代码，你的评论，你的提交，不仅仅是业务，还包含了很多外部信息，是否对团队友好和可读，都潜移默化地表达了出来。一切都可以分为初级/中级/高级，也可以理解为草稿/文字/优化/美化等递进关系和阶段。从易到难，还可以做以下检查（多为通用类）：低级错误、语法错误、冗余变量、类型检查、全局污染、强耦合、代码格式化等，通常可以使用自动化插件先检查，其次是人工检查。最佳实践，避免过时的语法，避免过多的ifelse，避免过多的参数，尽量用新的特性、语法糖、更好的设计模式、数据结构等来重构代码。重复代码，主要看你是否提取了公共组件、函数和可重用的代码片段。仅此一项就可以节省大量时间，避免后期出错。代码的健壮性和优雅性，是否可扩展，低耦合，逻辑是否健壮，是否存在潜在的bug，保证数据和行为的统一，比如统一的错误提示，统一的缓存等。这个涵盖了一小部分复习，其余的可以自行扩展。它不是一个固定的标准。每个团队的实现和目标都不一样。秘诀是一句??老话，人人都是成年人，做什么，怎么做，都要独立思考，积极行动。团队的CodeReview是否实施并不重要。是的，当然可能会更好，不是的，也不妨碍你的自我提升。但是对于任何美好的事情都要主动去尝试和坚持，克服外在因素的影响。一个人也可以查看自己和同事的代码，尤其是自己的代码。
