review time
自从上次定时任务把服务器访问崩溃后，我们组内的review大家都重视起来了，这是一个好兆头。
需求
先说需求，本期任务是替换一个老的服务，由于以下几个原因并没有做兼容：
- 该服务日活百万，新服务的稳定性还不确定
- 老服务代码耦合在其他团队的模块，趁这次机会拿回我们模块
所以我们确定的方案是新服务放到我们模块，出于稳定性考虑采用开关配置分批上线，遇到问题即时关闭开关避免事故。
因为这个版本需求比较多，排期两个月，在这期间对开关做了细分，所以需要业务逻辑适配增加开关的逻辑。
有意思的来了
同一个业务开关没统一
随着开关不断变化，业务同学也一直改逻辑，虽然他写了配置类，但是入口太多，每个地方都需要加开关适配新老服务，改着改着就出问题了，同一个业务两个入口开关没对齐。
开发同学解释是粗心了，但有经验的同学一眼就发现了问题，配置类的意义本来就是统一开关的，但是粒度太小了，导致业务调用的时候甚至需要使用组合开关，而且一旦开关有改动就需要每个地方都改，这是大忌啊。
最后在同事们的指导下，这位同学完善了配置类，内部做了开关的封装
又是配置类
开关是从服务端获取的，当服务异常时采用上次的配置，这是一个很简单的逃生手段。
BUT 这是一个会员相关的服务，开发同学持久化的方案是sharedpreference，但是文件名是固定的！！！
SO 不出意外的话意外来了，测试同学多个账号登录同一个设备发现开关有问题，而这个测试用例也是用户反馈后添加的
产品经理：把他给我拉出去毙了
解决方案：文件名加上账号或其他唯一标识
总结一下
有几年开发经验的同学可能觉得好笑，这么简单的错误也能犯，但是我们并没有批评这位同学，而是希望通过经验的积累他能够成为团队的顶梁柱，也相信早晚有这么一天
