1.
2.
3.
4.
1.
2.
code review 怎么做？
Code review的作用和目标
首先，我们先来看看Code Reivew的用处：
Code reviews 中，可以通过大家的建议增进代码的质量。
Code reviews 是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。
Code reviews 也鼓励程序员们相互学习对方的长处和优点。
Code reviews 也可以被用来确认自己的设计和实现是一个清楚和简单的。
Code Review 时该关注的
代码审查者在审查代码时有非常多的东西需要关注。一个团队需要明确对于自己的项目哪些点是重要的，并不断在审查中就这些点进行检查。
1. 体系结构和代码设计
代码复用: 根据“三振法”,
如果代码被复制一次，虽然不喜欢这种方式，但通常没什么问题。但如果再一次被复制，就应该通过提取公共的部分来重构它。
用更好的代码: 如果在一块混乱的代码做修改，添加几行代码也许更容易，但建议更进一步，用比原来更好的代码。
潜在的bugs: 是否会引起的其他错误？循环是否以我们期望的方式终止？
错误处理: 错误确定被优雅的修改？会导致其他错误？如果这样，修改是否有用？
效率: 如果代码中包含算法，这种算法是否是高效？ 例如，在字典中使用迭代，遍历一个期望的值，这是一种低效的方式。
新代码与全局的架构是否保持一致？
基础代码是否有结合使用了一些标准或设计样式，新的代码是否遵循当前的规范？代码是否正确迁移，或参照了因不规范而淘汰的旧代码
？
代码的位置是否正确？比如涉及订单的新代码是否在订单服务相关的位置？
新代码是否重用了现存的代码？新代码是否可以被现有代码重用？新代码是否有重复代码？如果是的话，是否应该重构成一个更可被重用
的模式，还是当前还可以接受？
新代码是否被过度设计了？是否引入现在还不需要的重用设计？
2. 可读性和可维护性
字段、变量、参数、方法、类的命名是否真实反映它们所代表的事物, 是否能够望文生义?
是否可以通过读代码理解它做了什么？
是否理解测试用例测了什么？
测试是否很好地覆盖了用例的各种情况？它们是否覆盖了正常和异常用例？是否有忽略的情况？
错误信息是否可被理解？ log打的是否正确和足够?
不清晰的代码是否被文档、注释或容易理解的测试用例所覆盖？具体可以根据团队自身的喜好决定使用哪种方式。
3. 功能
代码是否真的达到了预期的目标？如果有自动化测试来确保代码的正确性，测试的代码是否真的可以验证代码达到了协定的需求？
代码看上去是否包含不明显的bug，比如使用错误的变量进行检查，或误把and写成or？
作者是否需要创建公共文档或修改现存的帮助文档？
是否检查了面向用户的信息的正确性？
是否有会在生产环境中导致应用停止运行的明显错误？代码是否会错误地指向测试数据库，是否存在应在真实服务中移除的硬编码的stub
代码？
你对性能的需求是什么，你是否考虑了安全问题？
这个新增或修复的功能是否会反向影响到现存的性能测试结果
外部调用很昂贵(a. 数据库调用. b. 不必要的远程调用. c. 移动或穿戴设备过频繁地调用后端程序)
4. 安全
检查是否新的路径和服务需要认证
数据是否需要加密
密码是否被很好地控制？
这里的密码包含密码（如用户密码、数据库密码或其他系统的密码）、秘钥、令牌等等。这些永远不应该存放在会提交到
源码控制系统的代码或配置文件中，有其他方式管理这些密码，例如通过密码服务器（secret
server）。当审查代码时，要确保这些密码不会悄悄进入你的版本控制系统中
评论0