Size: a a a

2021 April 06

O

Oleg in atinfo chat
А их можно будет увидеть? Список всех PR, которые я не проревьюил?  Сейчас выглядит как-то так. Делается фича в ветке, когда она готова, на нее создается ревью. Когда ревью просмотрено(хотя бы одним человеком, но и то не всегда, как минимум тесты прошли), она мержится в дев. В конце проекта ветка дев мержится в релизную ветку. Так вот я в прицнипе могу смотреть свои ревью до того, как будет отрезан релиз, потому что в принципе ничего не поздно поменять, а скорее всего серьезных проблем там не найдется, потому что кто-то другой уже проревьюил.
источник

O

Oleg in atinfo chat
Так MR в фича ветку же не делается. Это совсем беспредел. Если и делать, то в дев ветку, куда сливается фича ветка.
источник

ЕГ

Евгений Горбоконенко... in atinfo chat
"хотя бы одним человеком, но и то не всегда, как минимум тесты прошли" Звучит как так себе практика. Смысл от ревью, если на него забивать можно?)
источник

O

Oleg in atinfo chat
Невозможно никого заставить делать хорошее ревью. Смысла от плохого ревью тоже никого.
источник

O

Oleg in atinfo chat
В любом случае ревью будет добровольное. Искуственные ограничения не помогут
источник

ИС

Игорь Середа... in atinfo chat
Именно в fеature-ветку делать MR'ы. Можно даже для них настроить правила мержа, как для master. И тогда туда будут попадать только проверенные задачи. А фичу уже можно будет мержить без CR, только на тестировании.
источник

ЕГ

Евгений Горбоконенко... in atinfo chat
Возвращаемся к предыдущему тезису - вопрос культуры) Оно и не должно быть принудительным. Я понимаю, что далеко не все команды дружно и слаженно работают, но это не мешает стремиться к идеалу
источник

O

Oleg in atinfo chat
В нашем случае ревью делается, если разработчику кажется, что он мог написать что-то не так. Если это типовая задача, то скорее всего ревью ничего не найдет и его можно опустить
источник

O

Oleg in atinfo chat
Да и в принципе, зачастую ревью больше служит для ознакомления с кодом
источник

ИС

Игорь Середа... in atinfo chat
Есть вариант получше. Feature toggle. Каждая сабтаска делается независимо и вливается в основную ветку. Но работает только под флагом, который будет выключен до тех пор, пока все задачи не будут готовы. Так не будет накапливаться development hell в виде постоянных ребейзов и конфликтов, сопровождающих все таски до тех пор, пока последний разработчик не сделает последнюю задачу из эпика.
источник

O

Oleg in atinfo chat
это не тот вариант
источник

O

Oleg in atinfo chat
feature toggle имеет смысл в мастере. Я говорю, про дев ветку, которая еще не смержена в релиз
источник

ЕГ

Евгений Горбоконенко... in atinfo chat
В корне не согласен. Ознакомление с кодом - это наименьший из приоритетов код-ревью. В первую очередь это для повышения качества кода и развития разработчика как специалиста
источник

ИС

Игорь Середа... in atinfo chat
А я говорю про способы, в которых будет ревьюиться не весь код, а непосредственно правки одного разработчика в одной задаче.
источник

O

Oleg in atinfo chat
Но я же описываю практику. Я согласен про приоритет. Приоритет не связан с частотой
источник

ЕГ

Евгений Горбоконенко... in atinfo chat
Вы описываете свою практику, как построено у вас на проектах. Это не значит, что оно так и должно быть) А я описал то, для чего код-ревью задумывался и должен использоваться
источник

O

Oleg in atinfo chat
Да нет же, он для этого и используется, причем в первую очередь. Просто если ревью на код, в котором создается поджо,  или копипаста из другого места, то там нечего уже улучшать.
источник

ЕГ

Евгений Горбоконенко... in atinfo chat
Поджики понятно. Насчёт копипасты - это уже место для улучшения потенциальное. Может быть можно эту копипасту вынести в единое место и не копипастить? Ревью такие проблемы как раз может подсветить
источник

O

Oleg in atinfo chat
Может
источник

O

Oleg in atinfo chat
Но ЧАЩЕ проблем нет. Это не значит, что ревью их не решает, когда они есть.
источник