Code review应该怎么作

代码评审有两种不一样的方法，一种是代码走查，一种是代码审查，咱们这里讨论的仅指代码走查。一般本身写的代码都难以发现问题，须要以第二双眼睛再次检查代码，帮助咱们及时地发现潜在的问题。

 作代码审查以前，团队成员间须要达成一个共识，制定一份合理的代码规范标准。以此为前提，后续再补充，不然会事倍功半,能够如下面为例：

1. Code review 不该该承担发现代码错误的职责。Code Review主要是审核代码的质量以及团队内部知识共享而不是以缺陷和错误来批判他人，也不须要评论，表扬或是批评；如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。代码中的bug和错误应该由单元测试，功能测试，性能测 试，回归测试来保证的（其中主要是单元测试，由于那是最接近Bug，也是Bug没有扩散的地方）
2. Code review 不该该成为保证代码风格和编码标准的手段，代码规范与代码优化必定要区分开，不可相提并论。首先每一个程序员的提交review的代码就应该是符合规范的，属于每一个人本身的事情，不该该交由团队来完成。其次，做为一个审查者，你的任务不是确保被审查的代码都采用你的编码风格，由于它不可能跟你写的如出一辙，而是要确保被审查的代码的正确性。
3. Code review不该该仅仅只是走查，评审就完事了，还须要进行质量分析，CODING企业版产品集成了代码评审和质量分析功能。

1. 体系结构和代码设计的注意事项以及常见问题

• 代码复用: 若是代码被复制一次，虽然不喜欢这种方式，但一般没什么问题。但若是再一次被复制，就应该经过提取公共的部分来重构它。
• 用更好的代码: 若是在一块混乱的代码作修改，添加几行代码也许更容易，但建议更进一步，用比原来更好的代码。
• 检查new 操做的结果是否为null，Java编程新手有时候会检查new操做的结果是否为null。可能的检查代码为：

1. Integer i = new Integer (400);  
2. if (i == null)  
3. 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. 其余方面

1. 是否存在内存无限增加? 例如, 若是审查者看到不断有变量被追加到list或map中, 那么就要考虑下这个list或map何时失效, 或清除无用数据
2. 代码是否及时关闭了链接或数据流?
3. 资源池配置是不是否正确? 有没有过大或者太小?
4. 调用接口出错的时候, 是否有出错处理逻辑, 而且处理正确?
5. 进程意外重启后, 是否可以恢复到崩溃前的环境?
6. 正确性(主要与多线程环境关系密切)
7. 代码是否使用了正确的适合多线程的数据结构
8. 代码是否在不须要的地方使用同步或锁操做？若是代码始终运行在单线程中，锁每每是没必要要的
9. 条件判断语句或其余逻辑是否能够将最高效的求值语句放在前面来使其余语句短路？
10. 代码是否存在许多字符串格式化？是否有方法可使之更高效？
11. 日志语句是否使用了字符串格式化？是否先使用条件判断语句校验了日志等级，或使用延迟求值？

6. Code Review 的实际操做建议

1. 代码审查是应该在互相沟通中进行讨论的，而不是相互对抗。预先肯定哪些是要点哪些不是，能够减小冲突并拟定预期。
2. 常常进行Code Review, 不要攒了1w行才让同事帮你review, 这是坑队友.

• 要Review的代码越多，那么要重构，重写的代码就会越多。而越不被程序做者接受的建议也会越多，唾沫口水战也会越多。
• 程序员代码写得时候越长，程序员就会在代码中加入愈来愈多的我的的东西。 程序员最大的问题就是“自负”，不管何时，什么状况下，有太多的机会会让这种“自负蔓延开来，并开始影响团队影响整个项目，以致于听不见别人的建议，从而让Code Review变成了口水战。
• 越接近软件发布的最终期限，代码也就不能改得太多。

1. Code Review要简短、轻量，不要太正式

• 平时工做量也比较忙，审查太长时间会影响工做进度，形成延期交付，得不偿失。
• 就算review时间没有形成什么影响，增长review时间也不会明显增长发现问题数量。
• 只用让代码审查简短、轻量，才能有效的发现问题,这样更适合迭代、增量开发，为开发者提供更快的反馈。

4. 减小代码审查人数量，且让不一样人review，建议三人组。

• 并非代码审查人员越多就能发现越多Bug，第一我的审查完后，第二我的发现的bug仅为剩下问题的一半，再多我的发现问题数量也没有明显变化，因此通常不超过三人。
• 更多代码审查人员意味着多人在寻找一样的问题，形成重复工做量，另外因为期望其余人员，使得审查人员积极性、主动性不高，更加不利于代码审查工做的有效进行。
• 三我的我认为是最合适最高效的数量，能够从不一样的方向评审。保持积极的正面的态度

代码审查对于代码做者，审查人以及团队都是有益的，常常阅读本身代码并修改重构本身代码的习惯，由于编写者都会以为本身代码写的很完美，这是正常的现象。不过若是你过段时间再次看本身当初觉得写的很牛的代码能够发现好多吐槽点，好多能够优化重构的地方，保持这种常常阅读本身代码并重构的习惯能够提升本身的代码能力。也能够常常阅读别人的代码看别人的代码风格有何借鉴之处，正所谓三人行必有吾师。

 

7. 代码审查工具：

一般，代码审查工具大体分为两类，一类是按照预先定义号的规则来审查代码，自动执行并生成报告，另外一种是合做共同检查和讨论变动的场景，并且须要将这过程的历史也存储下来以备未来参考。须要说明的是，没有最好的工具，只有适合本身的工具，适合就是最好，请你们根据本身的项目状况来作出选择。

这里说一下第二种方式，借助的是CODING企业版工具。

CODING 企业版提供整套企业级的软件研发管理系统，让企业的管理人员能够更好地进⾏研发团队的项目管理，便捷而深刻地把握开发进度，让开发流程高效可控。
CODING 企业版从项目的管理，到代码管理，直到代码的推送和部署，CODING 企业版提供了一整套的完整解决方案。

企业管理：企业管理提供企业个性化定制、企业概览和统计、项目及成员批量管理、项目权限一键开关、安全管理等能知足企业基本管理的需求。

项目管理：提供当前企业最前沿的敏捷开发，全生命周期项目和任务管理，帮助企业更好的管理项目和任务，以应对快速变化的 IT 项目管理需求。

• 简洁高效的任务指派

• 云端共享的项目文件

• 系统化的 Wiki 知识库

• 多维度的项目统计

代码管理：代码管理提供以 Git 为基础的平常开发源代码版本管理，包括代码浏览、分支管理、发布管理、版本对比、合并请求、项目网络等等，提供强于 Git 的代码管理使用体验。

• 代码仓库

• 代码评审

• 发布管理

另外价格也比较合适，免费试用15天，免费期事后是1元/人/天。