=Start=

---

思考点

自问一：自测了吗？

没有什么比自测更可靠。每一个单测，都是一份保障。多跑一个单测，就多一分把握。

自测绝对是对付问题性价比最高的一种方式。所以，他应该排在首位。

自问二：Review了吗？

Revive 又分为 自Revive 与 他人Review, 如自测一样，自Review 的作用绝对高于他人Review。因为没有谁比你更懂这次你写了什么，为什么要这么写。没有谁比你更懂这三行代码和之前的四行代码的区别不是只有代码量的大小。（有时候通过给其他人阐释你的解决问题思路，然后再自己去看自己的代码，让别人去看自己的代码，有时会发现有不少可以改进的点，也算是一种peer review吧）

Review 是一种以全局的视角看待此次代码的行为，开发时沉浸在细节里，想的是为什么是这样写而不是那样写，Review 是对之前细节的总体把握与检验。

自问三：发布顺序有影响吗？接口先后兼容吗？

如果有系统依赖，双方都要上线，那么发布先后顺序有没有依赖？

如果是同一个接口，接口前后逻辑兼容吗？

本次上线是否会影响旧的逻辑？

自问四：灰度发布有影响吗？

灰度发布是降低问题影响率的有效手段。但是灰度也有自身的负面效果，或者说怎样控制这种负面效果的发生。

比如之前遇到过的情况，同学A迁移数据需要双读双写，更新操作是通过单机任务发生的，写是全机器发生，怎样上线才能控制到不会产生双 数据源的不一致情形？灰度发布时应该是怎样的发布策略？

自问五：有问题怎么办？

真的产生了问题，有没有比回滚更优雅的方式？比如加个开关逻辑。

如果有问题，是否会影响数据？如果影响了，有没有快速修复方案？

上线后怎么验证效果是否是预期的？什么情况下需要切回旧逻辑？

自问六：有监控吗？有复盘吗？

监控与复盘是预期效果与真正效果的对比，没有监控自然就没法知道效果，没有复盘自然就没有对比。

关键位置有打点吗？效果符合预期吗？不符合问题出在哪了？

=END=