テーマ： 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

• 自動整形と lint をチームの約束にする

  レイアウトをフォーマッターに、機械的なチェックをリンターに任せると、レビューからスタイルの議論を取り除ける。EditorConfig、PEP 8、Ruff などのツールは、その約束をリポジトリに記述する方法を示している。

  methodology · ja · 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 · ja · 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 · ja · reviewed · 知識の基準日 2026-09-23

• コードを改善するコードレビューの進め方

  Google のエンジニアリングプラクティスに基づくレビュアーの手順です。変更がコード全体の健全性を高めるかを判断し、スタイルより先に設計を確認して、一営業日以内に応答します。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• 設計レビューの進め方：コメント期間、決定者の指名、処置の記録

  提案のレビューには、期限のあるコメント期間、決定する個人またはグループの指名、理由付きの処置（受諾、却下、延期）の記録、再開のルールが必要です。RustのRFCプロセスとPythonのPEPプロセスがその形を示し、この手順は1つのチーム向けに調整します。

  methodology · ja · reviewed · 知識の基準日 2026-09-16

• 文章で異議を述べる：立場を最も強い形で再構成し、中心的な論点を反駁する

  決定を変えうる書面の異議は、相手の立場を最も強い形で述べ直し、争点を正確に示し、誤った箇所を引用し、根拠の種類と強さを明らかにし、代案を示す。Paul Graham の不同意の階層は、罵倒から中心的な論点の反駁まで、応答を順位付けしている。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• 整形コミットを git blame から除外する：-w と ignore-revs ファイル

  git blame -w は行をたどる際に空白の差を無視する。--ignore-rev とコミット済みの .git-blame-ignore-revs ファイルは、一括整形などの指定コミットを飛ばし、行をそれ以前の意味のある変更に帰属させる。-M/-C は移動・コピーされた行を追跡し、GitHub は同じファイルを自動で読む。

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