주제: 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

• Automated formatting and linting as a team contract

  Delegating layout to a formatter and mechanical checks to a linter removes style debates from review; EditorConfig, PEP 8 and tools such as Ruff show how the contract can be encoded in the repository.

  methodology · en · 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

• Recognising code smells before refactoring

  Code smells are surface symptoms (long methods, large classes, feature envy, shotgun surgery, primitive obsession) that suggest a deeper design problem; naming them gives a vocabulary for review and a trigger for refactoring.

  article · en · 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

• Invisible and reordered text: bidirectional controls, tag characters and confusables in code and prompts

  Unicode lets text contain characters a reviewer cannot see or that reorder what is displayed. Bidirectional controls can make source code read differently from how it compiles, tag characters can hide instructions that a model still receives, and confusables imitate identifiers. Detection means scanning the code points, not the rendering.

  methodology · en · reviewed · 지식 기준일 2026-09-23

• Conducting a code review that improves the code

  A reviewer's procedure derived from Google's engineering practices: judge whether the change improves overall code health, review design before style, and keep turnaround within a business day.

  methodology · en · reviewed · 지식 기준일 2026-09-15

• Running a design review: comment period, named decider and a recorded disposition

  A proposal review needs a bounded comment period, a named person or group who decides, a written disposition (accept, reject, postpone) with reasons, and a rule for reopening; the Rust RFC process and Python's PEP process show the shape and this methodology adapts it to a single team.

  methodology · en · reviewed · 지식 기준일 2026-09-16

• Disagreeing in writing: steelman the position, then refute the central point

  A written disagreement that can change a decision restates the other position in its strongest form, names exactly what is disputed, quotes the mistaken passage, gives graded evidence, and proposes an alternative; Paul Graham's disagreement hierarchy ranks replies from name-calling up to refuting the central point.

  methodology · en · reviewed · 지식 기준일 2026-09-15

• Keeping reformatting commits out of git blame: -w and ignore-revs files

  git blame -w ignores whitespace when tracing lines, --ignore-rev and a committed .git-blame-ignore-revs file skip named commits such as mass reformattings so lines are attributed to the previous meaningful change, and -M/-C follow moved or copied lines; GitHub reads the same file automatically.

  article · en · 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

• Ranking code-review attention with Jev without averaging away blockers

  Use separate review dimensions to prioritize human attention while retaining mandatory checks that a weighted score must never override.

  methodology · en · 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

• Snapshot and golden-file tests and how to keep them honest

  A snapshot test serialises an output and compares it with a stored reference; it covers everything and describes nothing. Keep snapshots small, normalise volatile fields, review snapshot diffs like code and update them selectively, or they decay into approved noise.

  article · en · 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