Kacam.net

Code review

评审一段重试代码

「失败了就重试三次」——那第一次超时的那笔,对面到底收到没有?

Copy the prompt, then pick a model. It plays the interviewer and asks you through it scene by scene instead of handing you the answer.

On a phone with the app installed, the system opens the app directly. Links cannot open external apps inside WeChat — open it in a browser first.

The copied text ends with the answer key the model grades you against. Don't read it yourself first — working it out on your own is the point.

一段二十行的重试代码,几乎每个项目里都有一段长得差不多的。

它会揪住一件事不放:超时不等于对面没收到。想明白这一句,才轮到讨论重试怎么写;想不明白,重试就是在把同一笔单下两遍。

另一条是规模:它会让你算一百个客户端同时超时,对面会收到多少 QPS —— 重试到底是在救火还是在浇油,是一个能算出来的数。

★★★★☆ · about 35 min · Tests: 重试的前提是幂等、超时、退避与抖动、放大倍数、异常被吞掉

Mostly planted here

Retries and timeouts Idempotency Resources and capacity

Have you done this one?

Sign in to mark this one as practised — next time you come back you'll see when you did it.

Notes from people who did this one

Nobody has written yet. After you run it, say what came out of the conversation — which scene stumped you, which conclusion you changed afterwards.

Sign in to write a note.

How to use this

The material is ours: a few dozen lines that look like working code, with about ten defects planted in order of severity. So this series needs nothing from you — open one and start.

The stance is interrogation: no spoilers, no praise, and being unable to answer is a normal outcome. Say "there is a race here" and it will not let it go — it wants two columns of timeline and the size of the damage.

How to start

  1. Pick one, open it, copy the prompt.
  2. Paste it into a fresh, empty chat; it will paste the code back to you as-is.
  3. Read it yourself and name every problem you find — in the first scene it will not interrupt or hint. Say "that is all" when you are done.

Four commands you can call out any time

  • 跳过 Move on to the next scene
  • 提示 Give me a direction, not the answer
  • 直说吧 Give the full answer for this point, then keep pressing on the cost
  • 复盘 Jump straight to the wrap-up card

The wrap-up is a number

A find rate: how many you caught, out of how many, and how many were false alarms. Plus one uglier number — how many of the ones you missed are in the top severity band (loses money, leaks data, takes the service down). That number is worth more than the score.

Three traps

  • The answer key at the end is that list of defects. Do not read it first — once you have, this drill is spent.
  • Do not report naming or style. What counts here is whether money is lost or data leaks; style reports are recorded as false alarms.
  • The moment it praises you, point it back at the "do not praise me" rule. Feeling validated drowns out "what did I miss".

Start with the transfer one — it has the densest set of defects. If you write API endpoints all day, go straight to the list endpoint: its broken access control and sort-parameter injection are the easiest to find a twin of in your own code. Whichever you do, go grep your own repo afterwards — the real output is those three take-away checks.