代码评审有两种不同的方法，一种是代码走查，一种是代码审查，我们这里讨论的仅指代码走查。通常自己写的代码都难以发现问题，需要以第二双眼睛再次检查代码，帮助我们及时地发现潜在的问题。
做代码审查之前，团队成员间需要达成一个共识，制定一份合理的代码规范标准。以此为前提，后续再补充，否则会事倍功半,可以以下面为例：
- Code review 不应该承担发现代码错误的职责。Code Review主要是审核代码的质量以及团队内部知识共享而不是以缺陷和错误来批判他人，也不需要评论，表扬或是批评；如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。代码中的bug和错误应该由单元测试，功能测试，性能测 试，回归测试来保证的（其中主要是单元测试，因为那是最接近Bug，也是Bug没有扩散的地方）
- Code review 不应该成为保证代码风格和编码标准的手段，代码规范与代码优化一定要区分开，不可相提并论。首先每个程序员的提交review的代码就应该是符合规范的，属于每个人自己的事情，不应该交由团队来完成。其次，作为一个审查者，你的任务不是确保被审查的代码都采用你的编码风格，因为它不可能跟你写的一模一样，而是要确保被审查的代码的正确性。
- Code review不应该仅仅只是走查，评审就完事了，还需要进行质量分析，CODING企业版产品集成了代码评审和质量分析功能。
1. 体系结构和代码设计的注意事项以及常见问题
- 代码复用: 如果代码被复制一次，虽然不喜欢这种方式，但通常没什么问题。但如果再一次被复制，就应该通过提取公共的部分来重构它。
- 用更好的代码: 如果在一块混乱的代码做修改，添加几行代码也许更容易，但建议更进一步，用比原来更好的代码。
- 检查new 操作的结果是否为null，Java编程新手有时候会检查new操作的结果是否为null。可能的检查代码为：
- Integer i = new Integer (400);
- if (i == null)
- throw new NullPointerException();
检查当然没什么错误，但却不必要，if和throw这两行代码完全是浪费，他们的唯一功用是让整个程序更臃肿，运行更慢。
- 用== 替代.equals，在Java中，有两种方式检查两个数据是否相等：通过使用==操作符，或者使用所有对象都实现的.equals方法。原子类型(int, flosat, char 等)不是对象，因此他们只能使用==操作符
- 在catch 块中作清除工作
- 没有正确实现equals，hashCode，或者clone 等方法。方法equals，hashCode，和clone 由java.lang.Object提供的缺省实现是正确的。不幸地是，这些缺省实现在大部分时候毫无用处，因此许多类覆盖其中的若干个方法以提供更有用的功能。但是，问题又来了，当继承一个覆盖了若干个这些方法的父类的时候，子类通常也需要覆盖这些方法。在进行代码审查时，应该确保如果父类实现了equals，hashCode，或者clone等方法，那么子类也必须正确。
- 潜在的bugs: 是否会引起的其他错误？循环是否以我们期望的方式终止？
- 错误处理: 错误确定被优雅的修改？会导致其他错误？如果这样，修改是否有用？
- 效率: 如果代码中包含算法，这种算法是否是高效？ 例如，在字典中使用迭代，遍历一个期望的值，这是一种低效的方式。
- 新代码与全局的架构是否保持一致？
- 基础代码是否有结合使用了一些标准或设计样式，新的代码是否遵循当前的规范？代码是否正确迁移，或参照了因不规范而淘汰的旧代码？
- 代码的位置是否正确？比如涉及订单的新代码是否在订单服务相关的位置？
- 新代码是否重用了现存的代码？新代码是否可以被现有代码重用？新代码是否有重复代码？如果是的话，是否应该重构成一个更可被重用的模式，还是当前还可以接受？
- 新代码是否被过度设计了？是否引入现在还不需要的重用设计？
2. 可读性和可维护性
- 很多人图方便不写注释，自己方便了，可以别人看人看起来就费劲了。恰到好处的注释是很有必要的，第一，不能太多或太少，注释的形式根据代码具体的情况有不同； 其次避免用注释包裹代码； 最后尽量留下简明扼要的注释
- 代码清晰表达意图，写别人看得懂的单词，如果选用英语，那么避免日语、法语和汉语拼音等，尽量使用语义化的命名组合。
- 避免写一些现在不需要、将来也不太可能需要的功能
- 字段、变量、参数、方法、类的命名是否真实反映它们所代表的事物, 是否能够望文生义?
- 避免大段代码，要写高内聚、低耦合的代码，这是我们一直要追求的目标。
- 测试是否很好地覆盖了用例的各种情况？它们是否覆盖了正常和异常用例？是否有忽略的情况？
- 错误信息是否可被理解？ log打的是否正确和足够?
- 不清晰的代码是否被文档、注释或容易理解的测试用例所覆盖？具体可以根据团队自身的喜好决定使用哪种方式。
- 简单就是美，避免简单的功能写出复杂的代码
- 不要把代码写死，预测可能发生的变化
- 通过提高代码的复用性提高代码的可维护性
3. 功能
- 代码是否真的达到了预期的目标？如果有自动化测试来确保代码的正确性，测试的代码是否真的可以验证代码达到了协定的需求？
- 代码看上去是否包含不明显的bug，比如使用错误的变量进行检查，或误把and写成or？
- 是否有会在生产环境中导致应用停止运行的明显错误？代码是否会错误地指向测试数据库，是否存在应在真实服务中移除的硬编码的stub代码？
- 你对性能的需求是什么，你是否考虑了安全问题？
- 这个新增或修复的功能是否会反向影响到现存的性能测试结果
- 外部调用很昂贵(a. 数据库调用. b. 不必要的远程调用. c. 移动或穿戴设备过频繁地调用后端程序)
4. 安全
- 代码的常规审查不可少，安全审查也不可少，对安全性要求较高的程序尤其要注意。如果缺少了这道流程，万一遭受攻击，带来的损失将远超过我们的想象，包括识别威胁，检查是否存在常见安全漏洞，以及遭受安全威胁时如何应对和补救等，这是一个很打的话题，这里就不做展开。
- 识别可能受到的威胁，STRIDE 可用来识别对上述元素的威胁。STRIDE，是“假冒身份、篡改数据、否认、信息泄露、拒绝服务和权限提升”英文单词的缩写。
- 检查是否新的路径和服务需要认证
- 数据是否需要加密
- 密码是否被很好地控制？
- 这里的密码包含密码（如用户密码、数据库密码或其他系统的密码）、秘钥、令牌等等。这些永远不应该存放在会提交到源码控制系统的代码或配置文件 中，有其他方式管理这些密码，例如通过密码服务器（secret server）。当审查代码时，要确保这些密码不会悄悄进入你的版本控制系统中
- 代码的运行是否应该被日志记录或监控？是否正确地使用？
日志和监控需求因各个项目而不同，一些需要合规，一些拥有比别人严格的行为、事件日志规范。如果你有规章规定哪些需要记录日志，何时、如何记录，那么作为代码审查者你应该检查提交的代码是否满足要求。如果你没有固定的规章，那么就考虑：
- 代码是否改变了数据（如增删改操作）？是否应该记录由谁何时改变了什么？
- 代码是否涉及关键性能的部分？是否应该在性能监控系统中记录开始时间和结束时间？
- 每条日志的日志等级是否恰当？一个好的经验法则是“ERROR”触发一个提示发送到某处，如果你不想这些消息在凌晨3点叫醒谁，那么就将之降 级为“INFO”或“DEBUG”。当在循环中或一条数据可能产生多条输出的情况下，一般不需要将它们记录到生产日志文件中，它们更应该被放在 “DEBUG”级别。
5. 其他方面
- 是否存在内存无限增长? 例如, 如果审查者看到不断有变量被追加到list或map中, 那么就要考虑下这个list或map什么时候失效, 或清除无用数据
- 代码是否及时关闭了连接或数据流?
- 资源池配置是否是否正确? 有没有过大或者过小?
- 调用接口出错的时候, 是否有出错处理逻辑, 并且处理正确?
- 进程意外重启后, 是否能够恢复到崩溃前的环境?
- 正确性(主要与多线程环境关系密切)
- 代码是否使用了正确的适合多线程的数据结构
- 代码是否在不需要的地方使用同步或锁操作？如果代码始终运行在单线程中，锁往往是不必要的
- 条件判断语句或其他逻辑是否可以将最高效的求值语句放在前面来使其他语句短路？
- 代码是否存在许多字符串格式化？是否有方法可以使之更高效？
- 日志语句是否使用了字符串格式化？是否先使用条件判断语句校验了日志等级，或使用延迟求值？
6. Code Review 的实际操作建议
- 代码审查是应该在互相沟通中进行讨论的，而不是相互对抗。预先确定哪些是要点哪些不是，可以减少冲突并拟定预期。
- 经常进行Code Review, 不要攒了1w行才让同事帮你review, 这是坑队友.
- 要Review的代码越多，那么要重构，重写的代码就会越多。而越不被程序作者接受的建议也会越多，唾沫口水战也会越多。
- 程序员代码写得时候越长，程序员就会在代码中加入越来越多的个人的东西。 程序员最大的问题就是“自负”，无论什么时候，什么情况下，有太多的机会会让这种“自负蔓延开来，并开始影响团队影响整个项目，以至于听不见别人的建议，从而让Code Review变成了口水战。
- 越接近软件发布的最终期限，代码也就不能改得太多。
- Code Review要简短、轻量，不要太正式
- 平时工作量也比较忙，审查太长时间会影响工作进度，造成延期交付，得不偿失。
- 就算review时间没有造成什么影响，增加review时间也不会明显增加发现问题数量。
- 只用让代码审查简短、轻量，才能有效的发现问题,这样更适合迭代、增量开发，为开发者提供更快的反馈。
4. 减少代码审查人数量，且让不同人review，建议三人组。
- 并不是代码审查人员越多就能发现越多Bug，第一个人审查完后，第二个人发现的bug仅为剩下问题的一半，再多个人发现问题数量也没有明显变化，所以一般不超过三人。
- 更多代码审查人员意味着多人在寻找同样的问题，造成重复工作量，另外由于指望其他人员，使得审查人员积极性、主动性不高，更加不利于代码审查工作的有效进行。
- 三个人我认为是最合适最高效的数量，可以从不同的方向评审。保持积极的正面的态度
代码审查对于代码作者，审查人以及团队都是有益的，经常阅读自己代码并修改重构自己代码的习惯，因为编写者都会觉得自己代码写的很完美，这是正常的现象。不过如果你过段时间再次看自己当初以为写的很牛的代码可以发现好多吐槽点，好多可以优化重构的地方，保持这种经常阅读自己代码并重构的习惯可以提高自己的代码能力。也可以经常阅读别人的代码看别人的代码风格有何借鉴之处，正所谓三人行必有吾师。
7. 代码审查工具：
通常，代码审查工具大致分为两类，一类是按照预先定义号的规则来审查代码，自动执行并生成报告，另一种是合作共同检查和讨论变更的场景，而且需要将这过程的历史也存储下来以备将来参考。需要说明的是，没有最好的工具，只有适合自己的工具，适合就是最好，请大家根据自己的项目情况来做出选择。
这里说一下第二种方式，借助的是CODING企业版工具。
CODING 企业版提供整套企业级的软件研发管理系统，让企业的管理人员可以更好地进⾏研发团队的项目管理，便捷而深入地把握开发进度，让开发流程高效可控。
CODING 企业版从项目的管理，到代码管理，直到代码的推送和部署，CODING 企业版提供了一整套的完整解决方案。
企业管理：企业管理提供企业个性化定制、企业概览和统计、项目及成员批量管理、项目权限一键开关、安全管理等能满足企业基本管理的需求。
项目管理：提供当前企业最前沿的敏捷开发，全生命周期项目和任务管理，帮助企业更好的管理项目和任务，以应对快速变化的 IT 项目管理需求。
• 简洁高效的任务指派
• 云端共享的项目文件
• 系统化的 Wiki 知识库
• 多维度的项目统计
代码管理：代码管理提供以 Git 为基础的日常开发源代码版本管理，包括代码浏览、分支管理、发布管理、版本对比、合并请求、项目网络等等，提供强于 Git 的代码管理使用体验。
• 代码仓库
• 代码评审
• 发布管理
另外价格也比较合适，免费试用15天，免费期过后是1元/人/天。
来源：https://www.cnblogs.com/clarke157/p/7897162.html