1. Согласовывать, что такое хороший код, по каким пунктам оценивать ревью, какие замечения являются критичными. Нужен фасилитатор, как правило это тимлид

2. Можно делать неблокирующие ревью с исправлениями после релиза

3. Можно править только критичные замечания, а на правки по MR создавать задачу техдолга, которая выполняется следом

80%, что 3 не исправится никогда ))

ну если в компании потогонка, то да

но там и ревью обычно нет

а так это задача приоритетов

Могут быть оговорены, но иногда проще показать в коде.При условии, что задача не писалась несколько месяцев. :)

Можно обсудить до PR, но, как мне кажется, обсуждение в рамках PR удобно еще тем, что сохраняется история обсуждения и можно посмотреть в результате какие обсуждения были и почему было сделано так.

Это больше относится к области удобства команды и каких-то особенностей конкретного проекта. Процесс должны быть адаптивными под текущие потребности. :)

а если после QA были изменения в коде и нужно опять код ревью и так до бесконечности?

Дайте совет, я может зря спрашиваю это на собеседованиях, но как-то большинство не может дать нормальных ответов на следующие вопросы.
1. Какие фазы преобразования исходников в бинарник происходят помимо компиляции, когда жмёшь кнопку билд (в рамках обжектив-с допустим)
2. Зачем нужен дев сертификат (что такое code signing)
3. Как работает https примерно (виды шифрования туда же)
Ну и другие вещи, которые не обязательно знать чтобы накодить приложеньку, но достаточно важные, чтобы понимать как на самом деле что-то работает.

Может я устарел как-то, но мне кажется что без понимания внутреннестей каких-либо вещей или процессов невозможно быть хорошим специалистом

Мне кажется это очень узкоспециализированный вопрос)

какой именно?

Так спрашивайте, что действительно важно для позиции, на которую ищете человека. Если он будет с этим работать на таком уровне, то это нужно. Если нет, то нет. Это все равно что спрашивать бэкендера как работает dns или сети вцелом, а на деле человеку потом приходится просто CRUD'ы фигачить, не вылезая за пределы кода. :)

Ну у вас три вопроса из вашей предметной области, я вот из другой, я не знаю и мне кажется, что это ок)

ну мы делаем фреймворк например, котрый нужно собрать и отправить. если не понимать как фреймворк становится фреймворком из кода, то надо или чтобы кто-то другой занимался билд пайплайном или же ничего не получится

но ведь это общие вопросы, не касающиеся предметной области

если я задам вопрос вам на сложный запрос к БД - ответите?

зависит от вопроса, но я не писал запросы к БД уже лет так 10

И я о чём. Для меня БД - вполне общий запрос, для моей сферы

те вопросы которые я задал имеют отношения к разработке под ios в целом, просто идут глубже, чем просто использование

Если у вас есть уверенность, что эти вопросы нужны для данной позиции - то конечно задавайте их.