Comments
Жалко ничего не сказано про психологическую и стилистическую составляющую CR, а зря. При неправильном настрое CR может сильно ухудшить производительность и атмосферу в команде.
Хорошие статьи на эту тему
https://web.hypothes.is/blog/code-review-in-remote-teams/
https://medium.com/@mrjoelkemp/giving-better-code-reviews-16109e0fdd36
Сознательно опустил эту часть — материалов есть довольно много, в том числе и те ссылки, которые приложили к комменту. Ну и, если что, есть задел для второй части материала :)
UFO landed and left these words here
> А что вы здесь имели в виду?

Шуточка про «лучшее — враг хорошего». Такие штуки, если они действительно важны для проекта, стоит расценивать как техдолг и возвращаться к работе над ними позже.

> Всех членов команды? Не слишком ли большая нагрузка?

В случае команды из 3-4х человек — как раз самое оно.
Так все-таки возвращаться или «никогда больше не возвращаться»?
И получим мы после нескольких таких «невозвратов» веселый костыльный продукт, который через полгода такой разработки будет еле движим.
Если что-то пришло в голову во время ревью и времени/ресурсов нет запихнуть это в текущую версию — это должно быть сделано непременно в следующей, если с новой архитектурой согласны ведущие разработчики.
«Не возвращаться» — это путь в никуда.
всегда найдется способ сделать лучше. Изменения в архитектуре обычно требуют рефакторинга, который делать часто затратнее, чем уйти в техдолг.
И когда настанет время «отдавать технические долги»? Или это подразумевает переписываение продукта с нуля, так как накопилось?

Работа с техническим долгом — это часть повседневной работы с проектом. Если вы не закладываете время на эту работу, то будьте готовы к переписыванию проекта.

на этот раз обратите внимание на формулировку:
Изменения в архитектуре обычно требуют рефакторинга, который делать часто затратнее, чем уйти в техдолг.

Я прочитал и понял как -"Не возвращаться в данном конкретном ревью, не отвлекаться."

Картинки в статье повеселили, спасибо!
Что уже удалось автоматизировать в самом процессе code review, а что не поддается автоматизации? Собираете какие-либо метрики качества кода(сложность, покрытие тестами)?

Да, считаем сейчас и покрытие тестами, и ряд других метрик с помощью SwiftLint. Для него же и пишем разные кастомные правила, которые позволяют автоматизировать разные проверки кода на Swift.
У вас я так понял описан процесс «блокирующего» ревью. У него есть несколько критических недостатков.
Неблокирующее пробовали? http://beust.com/weblog/2006/06/22/why-code-reviews-are-good-for-you/
Пробовал, всегда работало хуже — возможно, просто неправильно строил процесс. Советы из статьи, на самом деле, не жестко привязаны к блокирующему ревью — все применимы и к неблокирующему.
> Два моих любимых — Slack-чат Cocoa Developers Club и Telegram-чат iOS Good Talks.

Есть ещё большая группа iOS-разработчиков (где более 1000 человек): https://t.me/ios_ru
Only those users with full accounts are able to leave comments. Log in, please.