主题： code-review

• Which code-review metrics predict escaped defects without being gamed?

  Open question: review turnaround, comment density and change size are easy to measure, but which of them actually predict defects found after merge, and which stop working once teams optimise for them?

  question · en · reviewed · 知识截至 2026-09-15

• Privacy review checklist for a feature

  Ten questions a reviewer answers before a feature ships: inventory of new personal data, minimisation decisions, retention job, access and access logging, export and deletion coverage, preference purposes, third-party flows, a short LINDDUN pass, test data, and a recorded result; engineering properties only, no legal assessment.

  methodology · en · reviewed · 知识截至 2026-09-17

• 将自动格式化和代码检查作为团队约定

  把布局交给格式化工具，把机械检查交给代码检查器，可以消除评审中的风格争论；EditorConfig、PEP 8 以及 Ruff 等工具展示了如何将约定编码到仓库中。

  methodology · zh · reviewed · 知识截至 2026-09-15

• Describing a change so that reviewers can review it

  A change description states the problem, the approach and its alternatives, how it was tested and what reviewers should look at; it links the ticket and lists risks and follow-ups, so review starts with understanding instead of archaeology.

  methodology · en · reviewed · 知识截至 2026-09-15

• Reviewing code written by an AI agent

  A proposed review protocol for generated changes: compare the diff with the request, confirm every API and dependency exists, verify test claims by running and breaking the tests, read tests before implementation, hunt for swallowed errors, and record what was checked.

  methodology · en · reviewed · 知识截至 2026-09-15

• Code-Review: eine Checkliste für Reviewer

  Eine kompakte Prüfliste für Code-Reviews: Zweck verstehen, Design vor Stil, Korrektheit und Randfälle, Tests, Lesbarkeit; Rückmeldung innerhalb eines Arbeitstags und Freigabe, sobald die Änderung den Code insgesamt verbessert.

  methodology · de · reviewed · 知识截至 2026-09-15

• 重构前识别代码异味

  代码异味是表面症状（长方法、大类、依恋情结、霰弹式修改、基本类型偏执），提示可能存在更深层的设计问题；为其命名可以形成评审的共同词汇，并成为重构的触发点。

  article · zh · reviewed · 知识截至 2026-09-15

• Kommentare schreiben, die der Code nicht sagen kann: Gründe, Randbedingungen, Fallen

  Ein Kommentar lohnt sich, wenn er etwas sagt, das im Code nicht steht: den Grund für eine überraschende Entscheidung, die äussere Randbedingung, die Falle für die nächste Person. Was der Code sagt, wiederholt er nicht; PEP 8 hält fest, dass Kommentare, die dem Code widersprechen, schlimmer sind als keine. Bevor man kommentiert, prüft man, ob ein besserer Name oder ein Test den Kommentar überflüssig macht.

  methodology · de · reviewed · 知识截至 2026-09-16

• 不可见与重排文本：代码和提示中的双向控制符、标签字符及形似字符

  Unicode 允许文本包含审查者看不见的字符，或改变显示顺序的字符。双向控制符可能使源码的视觉含义与编译器处理的含义不同；标签字符可隐藏模型仍会收到的指令，形似字符则模仿标识符。检测需要扫描码点，而不是查看渲染结果。

  methodology · zh · reviewed · 知识截至 2026-09-23

• 开展真正改善代码的代码审查

  依据 Google 工程实践制定的审查流程：判断改动是否改善代码的整体健康状况，先审查设计再审查风格，并在一个工作日内回应。

  methodology · zh · reviewed · 知识截至 2026-09-15

• 开展设计评审：评论期限、指定决策者与书面处理结论

  提案评审需要有界的评论期限、指定的决策个人或小组、附带理由的书面处理结论（接受、拒绝、推迟），以及重新开启的规则。Rust RFC 流程和 Python PEP 流程展示了基本形式，本文方法将其改编为适合单个团队的流程。

  methodology · zh · reviewed · 知识截至 2026-09-16

• 书面表达异议：先以最强形式重述立场，再反驳核心论点

  能够改变决策的书面异议，会以最强形式重述对方立场，准确指出争议所在，引用错误段落，明确证据层级，并提出替代方案。Paul Graham 的异议层级将回应从辱骂一直排列到反驳核心论点。

  methodology · zh · reviewed · 知识截至 2026-09-15

• 让 git blame 跳过重新格式化的提交：-w 与 ignore-revs 文件

  git blame -w 在追溯代码行时忽略空白差异；--ignore-rev 和提交到仓库的 .git-blame-ignore-revs 文件会跳过指定提交，例如批量重新格式化，使行归属于此前有实质意义的变更；-M/-C 跟踪移动或复制的行。GitHub 会自动读取同一文件。

  article · zh · reviewed · 知识截至 2026-09-16

• Schriftlich widersprechen, ohne zu verletzen: Zitat, Kernpunkt, Alternative

  Ein schriftlicher Widerspruch, der eine Entscheidung ändern kann, gibt die Gegenposition zuerst in ihrer stärksten Form wieder, zitiert die strittige Stelle, greift den Kernpunkt an statt Ton oder Person, stuft die eigene Evidenz ehrlich ein und schlägt eine Alternative vor. Paul Grahams Hierarchie des Widersprechens und Googles Leitfaden für Reviewer liefern die Massstäbe.

  methodology · de · reviewed · 知识截至 2026-09-16

• 用 Jev 为代码评审分配关注优先级，不让阻断项被平均掉

  使用独立的评审维度安排人工关注的优先级，同时保留强制检查；加权分数绝不能凌驾于这些检查之上。

  methodology · zh · reviewed · 知识截至 2026-09-22

• Refactoring in kleinen, geprüften Schritten

  Refactoring ändert die innere Struktur, nicht das beobachtbare Verhalten. Ein benanntes Refactoring aus dem Katalog nach dem anderen, Tests nach jedem Schritt grün, bei Rot rückgängig statt vorwärts debuggen, Struktur- und Verhaltensänderungen in getrennten Commits – so bleibt die Arbeit sicher und in Minuten prüfbar.

  methodology · de · reviewed · 知识截至 2026-09-16

• 快照测试与黄金文件测试：如何让它们保持可信

  快照测试将输出序列化并与保存的参考值比较；它检查所有内容，却不说明意图。保持快照精简，规范化易变字段，像审查代码一样审查快照差异，并选择性更新，否则快照会退化为被一味批准的噪声。

  article · zh · reviewed · 知识截至 2026-09-15

• A security-focused code review checklist for changes at trust boundaries

  A short list of questions a reviewer asks of any change that touches input, authentication, authorization, data access, outbound requests, files, secrets or dependencies: where does the untrusted data enter, who is allowed to do this, what does it query, where does it send or store, and what is logged. Applied to boundary-touching changes only, so that it stays short enough to be used.

  methodology · en · reviewed · 知识截至 2026-09-16

• Vier-Augen-Prinzip beim Deployment: Freigaben technisch erzwingen

  Kein Stand erreicht die Produktion, ohne dass eine zweite Person ihn gesehen und freigegeben hat – und zwar so, dass das Werkzeug es erzwingt statt die Disziplin: geschützte Zweige mit Pflicht-Review, Freigabepflicht für die Produktionsumgebung, keine Umgehung für Administratoren, und ein Notweg, der protokolliert statt verboten wird.

  methodology · de · reviewed · 知识截至 2026-09-15

• Mapping a code-review claim to the exact changed behavior it supports

  Build a compact review map that prevents unrelated passing checks from being used as evidence for a newly changed behavior.

  methodology · en · reviewed · 知识截至 2026-09-22

下一页

机器可读： JSON