Как давать feedback, этикет, работа с критикой, психология review
Code review — это про людей, а не про код. Умение давать и принимать feedback важнее технических знаний.
❌ «Ты забыл обработку ошибок»
✅ «Здесь нет обработки ошибок — добавь try/except»
❌ «Это ужасное решение»
✅ «Рассмотри альтернативный подход: ...»
❌ «Кто вообще это писал?»
✅ «Давайте обсудим эту часть кода»
Правило: Критикуй код, а не автора.
[Наблюдение] + [Объяснение] + [Предложение] + [Обоснование]
Примеры:
❌ «Перепиши эту функцию»
✅ «Я заметил, что функция process_data() делает 5 разных вещей
(наблюдение). Это усложняет тестирование и понимание
(объяснение). Предлагаю разбить на 3 функции: parse, validate,
save (предложение). Так каждую часть можно будет протестировать
отдельно (обоснование).»
| Тон | Пример | Реакция |
|---|---|---|
| Директивный | «Исправь это» | Сопротивление |
| Вопрос | «Что если попробовать ...?» | Открытость |
| Предложение | «Рассмотри вариант ...» | Сотрудничество |
| Объяснение | «Рекомендую ... потому что ...» | Понимание |
❌ «Используй здесь list comprehension»
✅ «Что если использовать list comprehension? Это сделает код
короче и понятнее: `[x*2 for x in items]`»
Критические (Blocking):
🚫 [BLOCKING] Здесь возможна SQL-инъекция. Используй
параметризованные запросы перед мержем.
Важные (Should fix):
⚠️ [IMPORTANT] Рекомендую вынести эту логику в отдельный сервис.
Сейчас она дублируется в 3 местах.
Рекомендации (Nice to have):
💡 [SUGGESTION] Можно упростить условие, используя `.get()`:
`config.get('key', default)`
Ниты (Nitpicks):
📝 [NIT] `calc_result` → `calculate_result` для консистентности.
Не блокирует, на усмотрение автора.
❌ «Они придираются ко мне»
✅ «Они помогают сделать код лучше»
❌ «Я должен защитить свой код»
✅ «Мы вместе делаем код лучше»
❌ «Они не правы»
✅ «Почему они так думают? Что я упускаю?»
✅ «Хорошее замечание, исправлю»
✅ «Понял, спасибо! А что если ещё добавить ...?»
✅ «Согласен с первой частью, но по второй есть вопрос:
почему ты предлагаешь именно этот подход?»
✅ «Можешь привести пример, как это должно выглядеть?»
✅ «Я сделал так потому что [причина]. Но твой вариант
тоже имеет смысл, давай обсудим»
❌ Игнорировать замечания без ответа
❌ Отвечать агрессивно: «Сам дурак»
❌ Оправдываться: «Я не виноват, это легаси»
❌ Переходить на личности: «Ты вообще ничего не понимаешь»
❌ Спорить ради спора о вкусовщине
Ситуация: Рецензент предлагает рефакторинг, автор не согласен.
❌ Плохо:
Author: «Нет, я хочу оставить как есть»
Reviewer: «Это ужасный код, надо переделать»
*спор на 50 комментариев*
✅ Хорошо:
Author: «Я понимаю твой пункт о читаемости. Я сделал так
потому что [техническая причина: производительность,
совместимость]. Предлагаю оставить сейчас, а рефакторинг
вынести в отдельную задачу»
Reviewer: «Понял, спасибо за объяснение. Тогда LGTM с
комментарием о техническом долге»
Если не удаётся договориться:
Признаки здоровой культуры:
Как создавать безопасность:
✅ Хвалите хороший код: «Отличное использование паттерна!»
✅ Признавайте свои ошибки: «Я пропустил это в прошлом review,
моя вина»
✅ Задавайте вопросы, а не утверждайте: «Что если ...?»
вместо «Это неправильно»
✅ Благодарите за feedback: «Спасибо, что заметил!»
Ключевая мысль: Code review — это диалог равных, направленный на улучшение кода. Уважение, эмпатия и готовность учиться важнее технического перфекционизма.
Вопросы ещё не добавлены
Вопросы для этой подтемы ещё не добавлены.