1. 代码评审注意事项
1.1. 始终保持代码评审的意识
1.2. 保证代码构建成功
1.3. 确保所有的测试都是通过的
1.4. 注意YAGNI原则
1.5. 检查重复代码
1.6. 使用静态分析器
1.7. 在代码开发完成之后，进入QA部门进行测试之前执行
1.8. 小步提交是有效传递信息的方式
1.9. 少量的代码比大量的代码更容易评审
1.10. 需要审查的代码越多，越容易出现漏网之鱼
1.11. 在等待代码审查时，请不要再对代码进行任何更改
2. 代码评审人员技能和知识
2.1. 技术权威性
2.2. 具备良好的软技能
2.3. 不要过于挑剔
3. 评审内容
3.1. 应当仅限于开发人员更改并提交的代码
3.2. 公司编码规范与业务需求
3.3. 命名规则
3.3.1. 命名是否足够长，使人容易阅读和理解
3.3.2. 体现代码意图又足够短
3.3.3. 评审人必须能够读懂代码
3.4. 代码格式
3.5. 测试
3.5.1. 易于理解并涵盖尽可能多的用例
3.6. 性能和安全性
3.6.1. 是否存在性能瓶颈
3.6.2. 是否能够防范SQL注入或者拒绝服务（Denial-of-Service，DoS）攻击
3.6.3. 是否对数据进行了充分的验证以保证数据的清洁
3.6.4. 是否只有验证通过的数据才能存储在数据库中
3.6.5. 是否检查了用户界面、文档和错误消息中的拼写错误
3.6.6. 是否有魔法数字（magic number）或者硬编码的值
3.6.7. 配置数据是否正确
3.6.8. 是否有意外提交的密钥
3.7. 架构规范和设计模式
3.7.1. GoF设计模式
3.7.1.1. Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides
4. 设计模式
4.1. 创建型
4.1.1. 单例设计模式（singleton）
4.1.1.1. 确保在应用程序级别只会创建一个实例
4.1.2. 工厂方法设计模式（factory method）
4.1.2.1. 在不使用具体类的前提下创建对象
4.1.3. 抽象工厂设计模式（abstract factory）
4.1.3.1. 无须指定具体类而创建一组相关的或者依赖的对象
4.1.4. 原型设计模式（prototype）
4.1.4.1. 指定要创建的原型的类型来创建原型的副本
4.1.5. 建造者设计模式（builder）
4.1.5.1. 将对象的创建和对象的表示区分开
4.2. 结构型
4.2.1. 适配器模式
4.2.1.1. 令接口不兼容的类顺畅地协同工作
4.2.2. 桥接模式
4.2.2.1. 抽象和实现解耦以降低代码的耦合度
4.2.3. 组合模式
4.2.3.1. 将对象组合并使用统一的方式使用各个对象或对象的组合
4.2.4. 装饰器模式
4.2.4.1. 在保持接口一致性的同时动态地向对象添加新的功能
4.2.5. 外观模式
4.2.5.1. 简化庞大的或复杂的接口
4.2.6. 享元模式
4.2.6.1. 节省内存并在对象之间传递共享数据
4.2.7. 代理模式
4.2.7.1. 可以截获客户端和API之间的调用
4.3. 行为型
4.3.1. 职责链模式
4.3.1.1. 对象顺序组成一个流水线来处理传入的请求
4.3.2. 命令模式
4.3.2.1. 将对象某个时间点需要调用方法的所有信息封装起来
4.3.3. 解释器模式
4.3.3.1. 解释特定语法
4.3.4. 迭代器模式
4.3.4.1. 用于顺序访问聚合对象的每一个元素而无须暴露对象的内部表示
4.3.5. 中介者模式
4.3.5.1. 对象通过中介互相通信
4.3.6. 备忘录模式
4.3.6.1. 捕获并存储对象的状态
4.3.7. 观察者模式
4.3.7.1. 观察对象，并在被观察对象的状态发生改变时通知观察者
4.3.8. 状态模式
4.3.8.1. 在状态变化时更改对象行为
4.3.9. 策略模式
4.3.9.1. 定义了一类可更换的封装算法
4.3.10. 模板方法
4.3.10.1. 定义了可以在子类中重写的算法及算法中的步骤
4.3.11. 访问者模式
4.3.11.1. 可以在现有的一组对象中添加新的操作而无须更改这些对象
扫一扫
8981
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
