1. 代码评审
1. 烂代码的定义
- 不遵守代码规约
- 代码像迷宫
- 代码流程不清晰
- 代码执行效率低
- 逻辑混乱bug多
2. 促成烂代码的恶性循环
- 业务催得紧，直接不加以考虑直接写代码
- 到处灭火，没有时间CR
- 没有时间去填坑，却不断的挖坑
3. 程序员的自我修养
写出好代码 --精雕细琢--> 技术水平不断提高 --Review别人代码--> 帮助别人成长 --取长补短-->写出好代码
4. 代码评审的好处
- 团队成长。养成团队成员间的交流文化，有利于团队的知识共享。
- 提高代码规范度。通过代码审查，发现并纠正不规范的情况，慢慢养成良好的开发习惯。
- 提高代码质量。扫除知识盲区，提高代码质量。
- 熵减的过程。减少代码的混乱。
5. 如何做CR
- 统一的编码与设计规范
- 完整的技术架构说明和事例
- 不定期的Review会议，小项目可以10天一次，大项目可以15天一次，前期可以安排的紧密一些，后期考虑一月一次
6. CR建议
- 对事不对人
- 至少一条正面评价
- PR内容一定要少
- 不要在过程中讨论需求
- 明确各模块的负责人
2. 代码的健壮性
1. 什么样的代码才健壮
对于异常情况，特殊环境，超限情况，依然能够稳定运行的能力。
2. 度量健壮性的指标
- 架构。负载均衡，容灾能力
- 代码。参数校验，异常处理，分支覆盖
- 环境。混沌工程，异地多活
3.负载均衡
负载均衡是防止服务或者数据热点问题的出现，使得集群内的所有服务器的负载水位在统一水平线上。有以下方法：
- 轮询法：按照顺序轮流的分配到各个服务器上，可以加权
- 随机法：流量随机分配
- 最小连接数法：根据服务器的连接数来分配流量
- IP哈希法：保证IP地址请求到同一个服务器上
4.容灾能力
- 限流：有策略的丢弃部分用户请求
- 降级：部分功能不可用或用户体验被降级
- 熔断：服务全部停止相应，以保护核心流程
- 灾备：复制多分系统能力或解决数据核心服务单点问题 可以使用Sentinel来进行流量监控，熔断降级，系统负载，通过多个维度来保护服务之间的稳定性。
3. 如果构建健壮性的系统
1. 数据的健壮性
- 逻辑删除。杜绝物理删除
- 定时本地冷备份。可以作为数据日志快照
- 主备准实时备份。快速切换服务的能力
- 定时云端离线备份。防地震，防火灾
2. 代码的健壮性
- 使用的POJO类属性必须使用包装类
- 定义DTO/DO/VO等POJO类时，不要设定任何属性默认值
- 定义数据对象DO类时，属性类型要与数据库字段类型相匹配
- getter/setter方法中，不要增加业务逻辑
- 禁止在POJO类中，同时存在对应属性的isXxx个getXxx方法
- 构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在init方法中
