Multi-part Practical Coding 怎么练：用 KV Store 和 Iterator 自测的五阶段框架

最近在准备偏 practical 的 coding 面试，发现和传统刷题很不一样，整理一个我自己在用的练习方法，分享出来也想听听大家是怎么练的。

传统 LeetCode 是一道题一个套路，但现在不少公司（比如 OpenAI 这类）喜欢给一个小系统，然后一问一问往后加：
第一问先把基本功能做出来，第二问加一个约束，第三问开始考数据结构和边界，第四问就要处理并发、持久化或者异常恢复。前面代码写乱了，后面全盘崩掉。

## 我的五阶段自测框架（以 KV Store 为例）

拿一个最常见的题型练手：In-memory Key-Value Store。

**阶段 1：最小可用**
只做 put / get / delete，接口先定清楚，变量命名干净。限时 15 分钟，必须跑通。

**阶段 2：加时间/版本维度**
比如 get 要能查某个时间点的值，或者支持版本号。这个阶段考的是有没有在第一阶段就把数据结构留好余地。

**阶段 3：加事务**
begin / commit / rollback。很多人卡在这里，是因为一开始把状态散在好几个地方。我的教训是：事务状态单独管，不要混在主存储里到处改。

**阶段 4：加持久化/恢复**
比如支持 snapshot、重启后恢复，或者写一个简单的 log。这个阶段不要求完美，要求能说清楚一致性和丢失数据的取舍。

**阶段 5：口头复盘**
写完之后自己给自己讲一遍：哪里会成为瓶颈？如果 key 增长到上亿怎么办？哪些地方没写测试最危险？面试里很多分其实是在这个阶段拿的。

## 同样的框架可以套到别的题型

- **Resumable Iterator**：基本遍历 → 支持暂停/恢复 → 处理底层数据变化 → 处理异常中断
- **Web Crawler**：抓一个页面 → 多层抓取+去重 → 并发抓取 → 礼貌限速+失败重试
- **事件聚合/计数器**：正常计数 → 乱序事件 → 滑动窗口 → 超大数据量下怎么近似

每一类都按“先跑通、再加约束”的顺序练，比盲目刷新题有用得多。

## 一个小经验

每写完一阶段就立刻给自己写两个小测试再往下走。我之前吃过亏：第三阶段才发现第一阶段一个边界 bug，后面全要返工，时间直接没了。这类题看的其实就是代码能不能持续演进，不只是某一问的答案。

大家平时是怎么练这种 multi-part 题的？有没有什么好的自测题单或者踩过的坑，欢迎分享，我整理后更新到主楼。

时间版本那关可以加个删除测试：t=1写k=1，t=2删k，查t=3应不存在，查t=1仍是1。删除可以记成tombstone，避免往前查版本时把旧值“复活”；如果snapshot/recovery也承诺保留历史，恢复后再跑一次。还可以写个最简单的参考模型，让两套实现跑同一串put/delete/get_at并逐步对照，不只测单次调用。Hypothesis的stateful testing可以生成操作序列并缩小失败用例，官方有数据库对照例子：https://hypothesis.readthedocs.io/en/latest/stateful.html

Good catch on the delete case — I hadn't written that one down explicitly, and the tombstone point is exactly the trap I was worried about, where an old value comes back if you just drop the key. I like the reference-model idea too, since running the same put/delete/get_at sequence through both and comparing step by step catches more than testing single calls. I'll add your t=1/t=2/t=3 example to my notes for the versioned stage, and I'm curious whether you'd also test a delete followed by a re-put at a later timestamp.

补充楼主问到的“删除后重新写入”用例：

t=1 写入 k=A，t=2 删除 k，t=4 写入 k=B。若接口支持历史查询，get_at(k,1) 应返回 A，get_at(k,2) 和 get_at(k,3) 应不存在，get_at(k,4) 应返回 B。关键是先找“不晚于查询时间的最新版本”，再判断该版本是不是 tombstone；不要先过滤删除标记再向前找值，否则 t=3 会错误地读到 A。快照或日志若承诺保留历史，恢复后也应跑同一组断言。

Iterator 还可以单独测一个边界：创建迭代器后，删除下一项或在当前位置前后插入新 key，再暂停、恢复。先约定恢复的是创建时快照还是实时集合，两种语义的期望不同；把这点写成测试，比只测“暂停前后顺序不变”更容易发现漏读或重复读。

不知道，同问。lc 时代过去了。

kangkangju 发表于 2026-10-30 22:30
不知道，同问。lc 时代过去了。

确实，光刷 lc 现在不太够用了。我现在练 KV Store 都是先把 put/get 跑通，再一层层加时间版本和事务，你平时会先卡在哪一层？

这个补充很到位，先找最新版本再判断 tombstone 这点我记下了，t=3 那组确实容易写错。iterator 那边我也打算按你说的，先把快照还是实时集合定下来再写测试。

苹果用户_spkrx 发表于 2026-10-31 09:33:30
确实，光刷 lc 现在不太够用了。我现在练 KV Store 都是先把 put/get 跑通，再一层层加时间版本和事务，你平时会先卡在哪一层？

我觉得可能是整体规划。不知道后面要问什么。之前可能写了个简单实现，后面扩展容易遇到瓶颈。lc 我彻底不看了。因为dp，图论，贪心这些难的，或者一些特别需要技巧的题都不太可能出现在新面试中。而且现在还继续考lc 的就剩一只手数得过来的几个大厂。我觉得AI 时代的未来不属于他们。

你说的整体规划这点确实是最难的，练的时候可以先默认后面会加版本、事务、持久化这几层，第一问就把数据按版本存、状态单独放，后面加东西就不用大改了。