一、背景
程序的定义：程序=数据+算法+接口
二、常用技巧
技巧1 - 按目标设计接口做幂等设计
- 场景
背景：做任务赚积分。前端发出增加积分请求，如果收不到响应会重试。
后台开发人员：怎么判断是重试还是另一次请求？
解决方案：接口定义中需要传入原来积分是多少，增加到多少。开发人员直接将目标结果入库。
疑问：那实际生产环境发现了原来积分一样，增加到多少不一样的结果怎么办？
答疑：这说明上线的产品中肯定有漏洞或bug。怎么办？改bug呗！
- 解析
幂等性设计的定义：一次和多次请求某一个资源应该具有相同的副作用。直白点讲就是多次重试可以多次查询，但是修改更新应该只进行一次。
作为开发正确的观念应该是外部调用失败是常态，并且失败之后必然有重试。
不要靠巧合编程 --《程序员修炼之道》
技巧2 - 多版本并发控制解决并发问题
- 场景
背景：上文中的做任务赚积分，后台收到了增加积分请求。
开发人员：为了避免重试，我该怎么写代码呢？
解决方案：
update XXX set score=XX where score=X
- 解析
多版本并发控制MVCC(MultiVersion Concurrency Control)的定义：该策略主要使用update with condition（更新带条件来防止）来保证多次外部请求调用对系统的影响是一致的。这也是「乐观锁」的主要思想。
乐观锁的定义：假设最好的情况，数据在变更的时候不会被别人更新，如果更新了，某个值就会改变。所以就用这个值来作为判断条件，只有条件为真才更新成功。
总是为并发进行设计 --《程序员修炼之道》
技巧3 - 预判断准入控制避免「箭头型」代码
- 场景
背景：上文中后台收到了增加积分请求，传入了一个负数的积分。
开发人员：我就if 正数 才往下执行就好了呀？
结果：一层层的判断下来，代码变成这个样子。
疑问：怎么解决这种复杂的「箭头型」代码问题呢？
答疑：「卫语句」在预判断时做准入控制。
- 解析
卫语句(guard clause)的定义：先对异常情况做检查，异常则直接返回。
最终一个请求被完美的分成预判断检查和正式执行两个部分，逻辑清晰，简单明了。
早重构，常重构 --《程序员修炼之道》
技巧4 - 异步设计分离响应和执行
- 场景
背景：上文的增加积分，并发量太大，因此采用了队列设计，大量请求排队等待数据库变更。
开发人员：这样后台接口部分很容易都在等着响应，服务被拖死。
解决方案：准入校验做充分，请求放到队列里后直接给用户返回操作成功。
疑问：万一最后失败了呢？
答疑：知道失败了还不修数据吗？数据补偿保证最终与对用户承诺一致撒。
- 解析
1/3/5秒原则：在1s以内得到响应，用户会觉得系统响应很快，体验非常好；1-3秒得到响应，用户可以接受，体验还不错；3-5秒才响应，用户就感觉慢了，体验有点糟糕；一旦响应超过5秒，用户就会认为是个失败的体验，选择离开或重新发起请求。
三、总结
思考！你的工作！ --《程序员修炼之道》
