Коротка відповідь та порада
Конструктивно поясніть технічні компроміси без переходу в захисну позицію. Визнайте слушність думки рев'юера, після чого покажіть дані чи граничні випадки, які визначили ваш вибір.
Ситуація
Колега залишив коментар у вашому PR із пропозицією іншої бібліотеки чи патерну. Ви вже перевіряли цей варіант раніше і відкинули через низьку швидкість.
Загальна порада
Визнайте слушність думки рев'юера, після чого покажіть дані чи граничні випадки, які визначили ваш вибір.
Фрази, які працюють
Good question! I tested that approach initially, but it caused memory spikes.
Чудове питання! Я спочатку тестував цей підхід, але він викликав стрибки пам'яті.
Демонструє, що ви ретельно дослідили варіанти заздалегідь.
The trade-off here is slightly more boilerplate for predictable O(1) lookups.
Компроміс тут — трохи більше коду заради стабільного пошуку за O(1).
Happy to jump on a quick huddle if you want to walk through the benchmark.
З радістю зідзвонюся на пару хвилин, якщо хочеш разом глянути бенчмарк.
Let me know if you see an edge case I might have overlooked.
Дай знати, якщо помітиш граничний випадок, який я міг пропустити.
У справжній розмові
Рев'юерWhy not use the existing ORM helper instead of raw SQL queries here?Чому не використати стандартний хелпер ORM замість чистого SQL?
ВиGood question! I tested the ORM helper initially, but it triggered an N+1 query loading thousands of rows. The raw query keeps the response under 50ms.Слушне запитання! Я спочатку пробував ORM, але він спричиняв проблему N+1 і тягнув тисячі рядків. Чистий запит утримує відповідь у межах 50 мс.
Рев'юерMakes total sense. Thanks for clarifying—approved.Цілком логічно. Дякую за пояснення — апрув.
Типові помилки
ЗамістьBecause my way is much better and cleaner.
КажітьThe trade-off here is slightly more boilerplate for predictable O(1) lookups.
Суб'єктивні оцінки провокують суперечки під час код-рев'ю.
ЗамістьFine, whatever, I will rewrite it your way.
КажітьGood question! I tested that approach initially, but it caused memory spikes.
Пасивна агресія шкодить архітектурі; захищайте рішення фактами та цифрами.
Код-рев'ю — це інженерний діалог, а не змагання его. Аргументуйте рішення через вимірювані показники: затримку, пам'ять і надійність.