RinaRish
commented
7 years ago Согласна, еще когда смотришь большое ревью часто не хватает логического описания задачи и из-за этого сложно понять, что и как работает и почему сделано именно так, а не иначе.
Я не люблю делать code review. Когда я открываю ревью в апсорсе я первым делом смотрю сколько файлов изменено. И если это число больше 30, то мне становится грустно, и я иду тыкать в фейсбук.
Во всяких статьях по правильному проведению ревью пишут, что верхняя планка адекватного восприятия ревью - 200 строк. Если больше, то сфокусироваться трудно, и ревью становится неэффективным. У нас это довольно редко соблюдается - сегодня смотрел ревью по 500++ строк.
Давайте с этим что-то делать :) Решения для автоматизации у меня пока нет. Можно начинать с тупого подсчета числа изменений ручками (http://stackoverflow.com/questions/2528111/how-can-i-calculate-the-number-of-lines-changed-between-two-commits-in-git). Наверняка что-то подобное можно будет прикрутить к Danger, которую изучать будет Костя Мордань (https://github.com/rambler-ios/team/issues/44). А пока нет автоматического решения давайте будем следить за размером ревью сами, и при необходимости дробить ветку на несколько ревью поменьше.