1. code review 的流程

我本人做 code review ，得细分看什么类型的 pr ，如果是 fix 类的 pr ，那么只做逻辑上的验证即可。
但如果是 feature 类的 pr ，会先把 branch 拉下来，看本身测试 case 跑一下。然后找到"入口"，一般来说都是接口，如果不是接口，那么回想着能不能改成接口？

有了"入口"之后，那么基本就是接口->实现->调用者这样去看，我会一行行读，主要看几个方面
- 当前接口在哪个层级？放得位置是否合理？抽象接口做的是否足够合理？
- 实现函数是否合理？注释/命名是否符合目前的 code style ？参数和返回是否能改的更合理？
- 当前实现逻辑是否正确？是否存在风险？参数有无验证？
- 是否存在极端 case 出现问题？

当然还有很多，一时半会可能总结不出来，但如果你让别人多 review 你的代码，你也能找到自己的经验

2. code review 的频率

每个 PR

@kinsou 好的，感谢，我再忍忍

@fredsunme 对，但独立 ip 不开东西就能很安稳。成本并不算是很高

真的不推荐 TMS ，前段时间才锁了 +086 。当然你实在要玩，台湾电话卡 100+ 一年（可以找几个 TMS 群/NGA 找找看）。

推荐 GMSR ，GMSR 现在大斗燃+3 个 149 斗燃。外挂也比 TMS 少，我玩了半个月 GSMR ，感觉还不错。

三年了，LZ 还没找到吗？

myprotein + 1

《水果篮子》 《魔法咪路咪路》

对称加密要做 round function 置换的，在没有 key 的情况下，初始值是啥都不知道。

有 key 的话，AI 推导出来，是存在一定可能性的

还有个类似的小说 《怪谈游戏设计师》

@ucando
"快照读明明就是有可能发生幻读"，我理解这一点上不是绝对。

pg 有些存储插件的做法是把数据本身做成不可改的，比如 gp 的 aoco ，对于 aoco 来说快照读只发生在辅助表内，也就是读 heap 表的部分，这部分发不发生幻读，取决于隔离级别的。

之前看到有做法把 aoco 的辅助表改到了直接拿个 log-base 的引擎在存，隔离级别在这一层面会失效，且只有 vacuum 发生才会上锁。

歪下楼，纯讨论技术

1. 首先“幻读”是否一定要加锁？
我的答案是：否，完全可以以空间换时间来解决"幻读"的问题。拿 pg 举例，xlog 中记录了每一条 insert/update/delete 语句且带有了 xmin/xmax/tid ，假设我们不存在 heap 表，将数据只存在 xlog 中，那么同一个事务只需要去扫当前 tid 事务 id 命中的 xlog 进行还原就行，这个时候是无需锁的，因为 xlog 中不会做 in-place update/delete 。

像现在的 [neon db]( https://github.com/neondatabase/neon) 做法是类似的。

2. mysql 中“幻读”是否一定要加锁？
不了解 mysql ，不知道

lz 什么公司啊？让我避个雷哈