Что делаешь, когда видишь плохую реализацию не по своей задаче?
Что проверяют
Баланс между заботой о качестве и уважением к границам задачи и чужому коду. Красные флаги: «молча переписываю» (раздутые PR, конфликты, обиды) и «не моё дело» (равнодушие к кодовой базе).
Скелет ответа
- Оценить масштаб и риск: это баг, который может выстрелить в проде, или просто некрасивый код?
- Мелкое и безопасное (опечатка, force unwrap в своём файле, очевидный утечка) — поправить попутно отдельным коммитом, чтобы ревьюеру было видно.
- Крупное — не трогать в текущем PR: завести тикет в техдолг с описанием последствий, обсудить с автором или владельцем модуля.
- Критичное (гонка, утечка данных, крэш) — сразу сказать команде, не ждать тикета.
- Тон: обсуждать код, а не человека; спросить «почему так» — часто есть причина.
Пример ответа
S: Делал фичу в экране профиля и увидел в соседнем модуле уведомлений DispatchQueue.main.sync внутри обработчика, который иногда вызывался с главного потока.
T: Это потенциальный дедлок, но модуль не мой и не относился к задаче.
A: Не стал править в своём PR. Написал автору в личку с минимальным воспроизведением — оказалось, он не знал, что обработчик может прийти с main. Завёл тикет с пометкой «риск зависания», приложил стек. Автор исправил в тот же день через MainActor.assumeIsolated-проверку и Task { @MainActor in }.
R: Мой PR остался в рамках задачи, баг починили до того, как он попал в прод, и команда договорилась включить -warn-concurrency, чтобы ловить похожее компилятором.