Тема: 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?
-
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.
-
Автоматическое форматирование и линтинг как командное соглашение
Передача оформления форматтеру, а механических проверок линтеру убирает споры о стиле из ревью; EditorConfig, PEP 8 и инструменты вроде Ruff показывают, как закрепить соглашение в репозитории.
-
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.
-
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.
-
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.
-
Как распознавать запахи кода перед рефакторингом
Запахи кода — внешние симптомы (длинные методы, большие классы, завистливые функции, стрельба дробью, одержимость примитивами), которые указывают на возможную более глубокую проблему проектирования; их названия дают общий язык для ревью и повод для рефакторинга.
-
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.
-
Невидимый и переставленный текст: двунаправленные управляющие символы, теги и похожие знаки в коде и промптах
Unicode позволяет включать в текст символы, невидимые рецензенту или меняющие порядок отображения. Двунаправленные управляющие символы могут заставить читать код иначе, чем он компилируется; символы-теги скрывают инструкции, которые модель всё равно получает, а похожие знаки имитируют идентификаторы. Для обнаружения нужно проверять кодовые точки, а не отображение.
-
Как проводить ревью, которое улучшает код
Порядок работы ревьюера на основе инженерных практик Google: оценить, улучшает ли изменение общее состояние кода, проверить проектные решения прежде стиля и дать ответ в течение одного рабочего дня.
-
Проведение проектного ревью: срок обсуждения, ответственный за решение и записанный итог
Рассмотрению предложения нужны ограниченный срок комментариев, назначенный человек или группа с правом решения, письменный итог — принять, отклонить, отложить — с причинами и правило повторного рассмотрения. Процессы Rust RFC и Python PEP показывают общий подход, а эта методика адаптирует его для одной команды.
-
Письменное несогласие: изложите позицию в сильнейшем виде, затем опровергните главное
Письменное возражение, способное изменить решение, передаёт чужую позицию в её сильнейшей форме, точно указывает предмет спора, цитирует ошибочный фрагмент, различает уровни доказательств и предлагает альтернативу. Иерархия несогласия Пола Грэма ранжирует ответы от оскорблений до опровержения главного тезиса.
-
Как исключить коммиты переформатирования из git blame: -w и файлы ignore-revs
git blame -w игнорирует пробельные различия при отслеживании строк; --ignore-rev и включённый в репозиторий файл .git-blame-ignore-revs пропускают заданные коммиты, например массовое переформатирование, относя строки к предыдущему содержательному изменению; -M/-C отслеживают перемещённые и скопированные строки. GitHub автоматически читает тот же файл.
-
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.
-
Приоритеты проверки кода с Jev: не скрывайте блокирующие проблемы усреднением
Используйте отдельные измерения проверки, чтобы направлять внимание людей по приоритету, сохраняя обязательные проверки, которые взвешенная оценка никогда не должна отменять.
-
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.
-
Снимки и эталонные файлы в тестах: как сохранить их полезность
Тест со снимком сериализует вывод и сравнивает его с сохранённым эталоном: проверяет всё, но не объясняет замысел. Делайте снимки небольшими, нормализуйте изменчивые поля, проверяйте diff как код и обновляйте выборочно, иначе снимки превращаются в одобренный шум.
-
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.
-
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.
-
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.
Машиночитаемо: JSON