1. 代码评审

1.1 什么样的是烂代码？

人的视角

1. 维护者脏话的频率高
2. 维护者脏话的类型丰富
3. 存在打架斗殴的可能性
4. 面向离职编程

代码视角

1.不遵守代码规约 2. 代码像迷宫 3. 代码流程脚踩西瓜皮 4. 代码执行效率低 5. 10行代码15个bug

1.2 代码的恶性循环

到处灭火，更是没有时间CodeRevew 业务催得紧，直接写代码 没时间填坑，却不断挖坑

1.3 代码评审

1. 熵减的过程，减少系统混乱
2. 团队成长 养成团队成员间的交流文化，有利于团队的知识共享
3. 提高代码质量 工程师互相review，扫除知识盲区，提升代码的质量
4. 提升代码的规范度 通过代码审查，发现纠正不规范的情况，慢慢形成良好开发规范

1.4 如何做Review

1. 统一的编码与设计规范
2. 完整的技术架构说明与事例
3. 不定期的Review会议
4. 小项目（3个月内）可以10天/次，大项目（6个月以上）15天/次，前期可以安排密集一些，后期考虑1月/次 推荐工具： Phbaricator: Facebook开源的代码审查工具 Gerrit: 非常强的CodeReview+代码托管工具 CheckStyle: 代码规范检查工具

CR建议：

1. 对事不对人
2. 至少一条正面评价
3. PR内容一定要少
4. 不要在review中讨论需求
5. 明确各模块负责人

2. 健壮性

异常情况 特殊环境 超限情况 依然能够稳定运行的能力

1. 架构 负载均衡容灾能力
2. 代码 参数校验异常处理 分支覆盖
3. 环境 混沌工程 异地多活

2.1 负载均衡

1. 轮询法 按顺序轮流分配到各个服务器上（可以加权）
2. 随机法 流量随机分发
3. 最小连接数法 根据服务器的连接数来分配流量
4. IP哈希法 保证IP地址请求到同一服务器上

负载均衡 是防止服务或者数据热点问题的出现，使得集群内的所欲服务器的负载水位在同一水平线上

2.2 容灾能力

1. 限流 有策略的丢弃部分用户请求
2. 熔断 服务全部停止响应 以保护核心流程
3. 降级 部分功能不可用活用户体验被降级
4. 灾备 赋值多分系统能力或解决数据和兴服务单点问题

2.3 数据健壮性

1. 逻辑删除 杜绝物理删除
2. 定时本地冷备份 可以作为数据日志快照
3. 主备准实时备份 快速切换服务能力
4. 定时云端离线备份 防地震 防水灾

2.4 代码健壮性

1. 所有的POJO类属性必须使用包装数据类型
2. 定义DO、DTO 、VO等POJO类时，不要设定任何属性默认值
3. 定义数据对象DO类时，属性类型要与数据库字段类型相匹配
4. getter、setter方法中，不要增加业务逻辑
5. 禁止在POJO 类汇总，同时对应属性xxx的isXxx()和getXxx()方法
6. 构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在init方法中

3. 面向失败的架构思维

从面向对象角度来看，这还是面向功能或者业务视角，是功能的性能，功能的容量，功能的稳定性，面向失败的设计，就是以 失败 为对象，天然为了失败而存在的设计思想

1. 任何环境都是不可信赖的
2. 任何外部依赖接口都有可能出错
3. 任何异常都需要响应和处理的
4. 任何行为都需要日志记录的
5. 任何系统的上线都需要严酷的测试

测试健壮性

1. 功能测试 想象用户的一切可能行为进行正确性的验证
2. 性能测试 系统能够提供的最大服务级别的能力
3. 稳定性测试 确定系统长时间在正常压力情况下运行的有效性
4. 混沌工程 确定线上系统故障的恢复能力

4. 混沌工程

混沌工程： 是在分布式系统上进行实验的学科，是一种未雨绸缪的心态，有薄弱环节上，做到自我发现，特点是放置一个炸弹进去，控制爆炸半径，评估损伤和自我修复能力

1. 建立稳定状态的假设
2. 多样化现实世界事件
3. 在生产环境运行实验
4. 持续自动化运行实验
5. 最小化 爆炸半径