Как реагировать на замечания по коду при сжатых сроках

Что проверяют

Как вы ведёте себя, когда качество и сроки тянут в разные стороны: спорите, молча соглашаетесь со всем или умеете отделить важное от косметики. Следом обычно спрашивают, что стало с замечаниями, которые вы отложили.

Как отвечать

Это вопрос про опыт, поэтому стройте ответ на своей истории: какой был релиз, сколько оставалось времени, какие замечания пришли. Каркас такой:

• сортировка замечаний: блокирующие правятся до мержа всегда. Для Android это утечки Context и Activity в синглтонах, сеть или база на главном потоке, сбор Flow без учёта жизненного цикла (repeatOnLifecycle), потеря состояния при повороте экрана, падения на старых версиях API. Именование, мелкий рефакторинг и стиль могут подождать;
• договорённость с ревьюером: вы не решаете в одиночку, что отложить. Коротко созваниваетесь или пишете в треде, какие пункты уходят в следующий спринт, и получаете явное согласие;
• фиксация долга: на отложенное заводится задача со ссылкой на PR, иначе «потом» не наступает. Помогают пометки вроде nit: в комментариях, чтобы сразу было видно, что не блокирует;
• снижение риска: спорную часть, которую не успеваете переписать, закрывают фиче-флагом или выкатывают поэтапным релизом на небольшой процент пользователей;
• результат: что было с релизом, закрыли ли долг потом, сколько времени это заняло.

Нужны ваши реальные примеры и цифры. Если в команде не было ревью или сроки никогда не горели, скажите честно и опишите, как поступили бы, опираясь на ревью в пет-проекте или в open source.

Где спотыкаются

Говорят «я всегда исправляю все замечания». Звучит как отсутствие приоритизации и готовность сорвать срок из-за названия переменной.

Уходят в оборону: «ревьюер придирался». Интервьюер слышит будущий конфликт в команде.

Откладывают замечание про утечку или главный поток как косметику. Для Android это прямой путь к ANR и падениям у пользователей, которые потом всплывут в отчётах о стабильности.