Comments 16
Жалко ничего не сказано про психологическую и стилистическую составляющую CR, а зря. При неправильном настрое CR может сильно ухудшить производительность и атмосферу в команде.
Хорошие статьи на эту тему
https://web.hypothes.is/blog/code-review-in-remote-teams/
https://medium.com/@mrjoelkemp/giving-better-code-reviews-16109e0fdd36
Хорошие статьи на эту тему
https://web.hypothes.is/blog/code-review-in-remote-teams/
https://medium.com/@mrjoelkemp/giving-better-code-reviews-16109e0fdd36
UFO just landed and posted this here
> А что вы здесь имели в виду?
Шуточка про «лучшее — враг хорошего». Такие штуки, если они действительно важны для проекта, стоит расценивать как техдолг и возвращаться к работе над ними позже.
> Всех членов команды? Не слишком ли большая нагрузка?
В случае команды из 3-4х человек — как раз самое оно.
Шуточка про «лучшее — враг хорошего». Такие штуки, если они действительно важны для проекта, стоит расценивать как техдолг и возвращаться к работе над ними позже.
> Всех членов команды? Не слишком ли большая нагрузка?
В случае команды из 3-4х человек — как раз самое оно.
Так все-таки возвращаться или «никогда больше не возвращаться»?
И получим мы после нескольких таких «невозвратов» веселый костыльный продукт, который через полгода такой разработки будет еле движим.
Если что-то пришло в голову во время ревью и времени/ресурсов нет запихнуть это в текущую версию — это должно быть сделано непременно в следующей, если с новой архитектурой согласны ведущие разработчики.
«Не возвращаться» — это путь в никуда.
И получим мы после нескольких таких «невозвратов» веселый костыльный продукт, который через полгода такой разработки будет еле движим.
Если что-то пришло в голову во время ревью и времени/ресурсов нет запихнуть это в текущую версию — это должно быть сделано непременно в следующей, если с новой архитектурой согласны ведущие разработчики.
«Не возвращаться» — это путь в никуда.
всегда найдется способ сделать лучше. Изменения в архитектуре обычно требуют рефакторинга, который делать часто затратнее, чем уйти в техдолг.
И когда настанет время «отдавать технические долги»? Или это подразумевает переписываение продукта с нуля, так как накопилось?
Работа с техническим долгом — это часть повседневной работы с проектом. Если вы не закладываете время на эту работу, то будьте готовы к переписыванию проекта.
на этот раз обратите внимание на формулировку:
Изменения в архитектуре обычно требуют рефакторинга, который делать часто затратнее, чем уйти в техдолг.
Я прочитал и понял как -"Не возвращаться в данном конкретном ревью, не отвлекаться."
Картинки в статье повеселили, спасибо!
Что уже удалось автоматизировать в самом процессе code review, а что не поддается автоматизации? Собираете какие-либо метрики качества кода(сложность, покрытие тестами)?
UFO just landed and posted this here
> Два моих любимых — Slack-чат Cocoa Developers Club и Telegram-чат iOS Good Talks.
Есть ещё большая группа iOS-разработчиков (где более 1000 человек): https://t.me/ios_ru
Есть ещё большая группа iOS-разработчиков (где более 1000 человек): https://t.me/ios_ru
Очень забавная статья, очень порадовали картинки
Sign up to leave a comment.
May the Code Review be with you