Дослідження Code Review для дипломної роботи
Доброго дня,
Я проводжу дослідження того, як можна мотивувати девелоперів проводити Code Review на проекті для дипломної роботи.
Враховуючи, що геймифікація всього і всія зараз у тренді, то вирішив спробувати саме цей підхід. На проекті це дало поштовх для девів проводити то частіше і якісніше.
Але треба більше респондентів для того щоб результати були показові. Якщо буде вільних
Також, цікаво послухати як ви вирішували кейси відсутності бажання проводити Code Review у вашій команді.
28 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівВ одній з попередніх команд ми домовились описувати пул-реквести (на гатхабі можна сетапити pr-template), щоб рев’юверам було легше зрозуміти що до чого
— Скрішноти/скрінкасти розробленого фунціоналу або посилання на тестовий енв де можна покляцати
— Посилання на на ключові фрагменти коду
— Опис того які фрагменти є чисто «технічними» — переіменування/клінап ітд
— Основні юз-кейси, покриття автотестами
Звісно це все може працювати коли в статичний аналіз коду працює автоматично, і рев’ювер може зосередитись на дійсно важливих моментах.
Але мабуть найважливіше — це культура комунікації і принципи лідерства в компанії. Якщо розробник бачить профіт в проактивній позиції — то він буде зацікавлений і отримувати фідбек і давати його.
Також, з мого досвіду можу сказати що наявність в команді хоча б однієї токсичної людини може обнулити будь-які старання.
У нас на проекте используется скрипт, который раз в какое-то время проходит по всем пулл-реквестам и добавляет двух рандомных ревьюеров там, где их ещё нет.
Я пытался протолкнуть плашки [big]/[small]/[medium]/[tiny] в сабже, но их редко используют.
1. В настройках проекта на гитхабе выбираешь минимум 2 аппрувала на PR в master.
2. ???
3. PROFIT
К сожалению, не работает если делите репозиторий с другой командой со стороны клиента, которая не умеет в бренчи, что уж говорить о PRах.
+ Закрити коміти в мастер, і хай вчаться в бренчі. Можна невеличкий лікбез для них на ту тему зробити.
А от гейміфікація, мотивація — ото все тут зайве.
Максимум зашедулити мітінг, зробити детальну презентацію по новому процессу. Описати переваги, вислухати всіх — домовитись і далі по пунках.
Мой дядя самых честных правил
И без ревью в продакшн ставил.
git flow зло, потому что long-living branches, trunk-based development FTW.
сколько в ваших репозиториях живет «master» ?
это когда вся команда использует единственный бранч, и любой comit требует merge
вам стоит немного глубже разобраться в предмете
Имелось в виду feature branches, очевидно.
Не в каждой реализации. Если интрумент позволяют делать peer review, проганять CI и разные Quality Gate для каждого коммита, то, да, можно и без бранчей. Если нет, то конечно, без short-lived веток не обойтись. Я думаю разница между short-lived и long-lived веткаим понятна, если нет, спрашивай. Вот норм ресурс trunkbaseddevelopment.com если интересны детали.
Я достаточно глубоко разбирался в вопросе, но спасибо за рекомендацию 😉
Речь о том, то github позволяет настроить разрешения для merge into master, только для пулл риквестов, прошедших ревью.
git flow не имеет к этому отношения.
Что значит відсутність бажання, лол? ) Ревью кода — такая же рабочая обязанность, как и его написание.
Человеческая цивилизация в итоге погибнет от инфантилизма, а не от какого-то там ядерного апокалипсиса.
Надо перечислить в официальном документе компании ОБЯЗАННОСТИ
— ревью
— документирование
— покрытие тестами
Например, у вас не сходятся взгяды с коллегой, и вы знаете, что ваш фидбек будет проигнорирован. Зачем тратить свое время?
Как только вы начнете включать в эстимейты время на ревью, эта «почетная обязанность» исчезает.
Ну, или, как уже писали, approve не глядя.
p.s. например, ваш коллега-синьйор «родил» метод, работающий, за O(n^2), когда можно и за O(1). Вы ему про это пишете, а он спрашивает «что такое O(1) и зачем оно тут нужно» (пример из жизни).
Будете дальше тратить свое время, и за него все переделывать?
Просто не нужно работать там, где фидбек молча игнорируется и синьоры не знают про O-нотацию. В таких местах желание/нежелание проводить код ревью — наименьшая из проблем.
Очевидно, что ревью, как и любой другой инструмент, может приносить пользу только там, где хоть как-то налажены процессы: программисты умеют программировать и разговаривать друг с другом, как минимум.
— Доктор, когда я делаю вот так, у меня тут болит.
— А Вы так не делайте.
Это где ты такое видел?
Code Review это инструмент, а не обязанность, в большинстве случаев полезный, но не незаменимый. И в данном случае такой карго культ ничем не лучше чем
такой же инфантилизм, только вид с другой стороны.
Этот трюизм можно применить к чему угодно: написание тестов, соблюдение кодстайла, следование best practices — все это «инструмент, а не обязанность», «в большинстве случаев полезно, но не незаменимо». И?
Если задачи на проекте чуть сложнее передвигания кнопочек на фронте, и есть необходимость развивать/поддерживать его в будущем — код ревью является необходимым условием для поддержания приемлемого уровня качества. Если команда действительно в код смотрит, конечно, а не просто молча жмет на approve.
В подавляющем большинстве случаев моих личных наблюдений люди оперирующие абсолютными категориями в отношении инструментов (обязанность, необходимое условие, и т.п.) в лучшем случае слабо представляют границы применимости инструмента, а в худшем не понимают зачем они его используют. И то и другое проявления инженерного инфантилизма.
Code review, как правило, имеет 3 цели:
— knowledge sharing — возможность что-то показатать, тому, кто про это иначе бы не узнал
— responsibility sharing — возможность заручится поддержкой реализованного решения
— feedback — как следствие 2х предыдущих, кто-то может поделиться собственным knowledge или отказаться от responsibility (при этом обосновав почему)
Но это всего лишь инструмент, просто применяя code review вы не можете никого заставить смотреть ваш код, или давать фидбек.
Между самим процессом code review, и code quality нет вообще никакой кореляции.
Кореляция есть между code quality и желанием команды заниматься knowledge sharing, responsibility sharing и давать взаимный feedback.
Вот именно поэтому тут вопрос стоит не «как заставить», а «как мотивировать». Есть подозрения что если это вынести в обязаности, и ПМ будет ходить делать бо-бо тем, кто не делает ревью, то все закончится тем, что люди просто будут заходить поставить галочку «Approve». В то же время, если подбодрить именно желание заниматься этим, играя любовью мозговой обезянки к «заработаным» картинкам и увеличивающимся циферкам, то что-то может и получится, как на меня.
Никак. Или люди понимают, зачем это нужно, или нет.
Может получиться угробить кучу времени, качество и мотивацию.
Вот вы себе придумали, что «ревью надо», и дальше педалите.
А ревью, само по себе совсем не надо, это типичный культ карго.
Подмена смысла ачивками? Отличный план (нет). Если у взрослых людей нет желания делать нечто, что вообще-то составляет часть их профессиональных обязанностей, то нужно не кровати в борделе переставлять, а разбираться в реальных причинах происходящего.
Распространенная ситуация — люди не глядя ставят Approve на пулл реквесты. То есть там внутри могут быть баги, ошибки безопасности — а ставится approve.
Причины такие:
а) Человек очень сильно доверяет второму («Это ж Колян! Он всегда хорошо пишет»)
б) Человек не знает, что именно нужно ревьювить («Код выровнен красиво — approve»)
в) Человек очень занят своей какой-то задачей, ему не хочется отвлекаться на ревью (но можно же договориться и сделать ревью попозже)
г) Не понимает какие серьезные могут быть последствия и что тесты ловят не все ошибки (это до первых серьезных факапов)
при таком approve ревью формально делается, а практически нет
послухайте — www.se-radio.net/...-greiler-on-code-reviews
Нащо дослідження, коли є підручник
Да, да. А еще в Египте думали, что высушенные тела можно через некоторое время оживить. Возможно их жреческая медицина дошла там до определенного уровня взаимодействия. Вот только...