May the Code Review be with you

[sgrekov]

Жалко ничего не сказано про психологическую и стилистическую составляющую CR, а зря. При неправильном настрое CR может сильно ухудшить производительность и атмосферу в команде.
Хорошие статьи на эту тему
https://web.hypothes.is/blog/code-review-in-remote-teams/
https://medium.com/@mrjoelkemp/giving-better-code-reviews-16109e0fdd36

[YourDestiny]

Сознательно опустил эту часть — материалов есть довольно много, в том числе и те ссылки, которые приложили к комменту. Ну и, если что, есть задел для второй части материала :)

[YourDestiny]

> А что вы здесь имели в виду?

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

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

В случае команды из 3-4х человек — как раз самое оно.

[fregate]

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

[Antervis]

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

[fregate]

И когда настанет время «отдавать технические долги»? Или это подразумевает переписываение продукта с нуля, так как накопилось?

[AleksandrKu]

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

[Antervis]

на этот раз обратите внимание на формулировку:

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

[AleksandrKu]

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

[AleksandrKu]

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

[YourDestiny]

Да, считаем сейчас и покрытие тестами, и ряд других метрик с помощью SwiftLint. Для него же и пишем разные кастомные правила, которые позволяют автоматизировать разные проверки кода на Swift.

[YourDestiny]

Пробовал, всегда работало хуже — возможно, просто неправильно строил процесс. Советы из статьи, на самом деле, не жестко привязаны к блокирующему ревью — все применимы и к неблокирующему.

[DenisIzmaylov]

> Два моих любимых — Slack-чат Cocoa Developers Club и Telegram-чат iOS Good Talks.

Есть ещё большая группа iOS-разработчиков (где более 1000 человек): https://t.me/ios_ru

[TheMisterPanek]

Очень забавная статья, очень порадовали картинки