Check Levi9 best QA positions to Backbase team!
×Закрыть

Дослідження Code Review для дипломної роботи

Доброго дня,

Я проводжу дослідження того, як можна мотивувати девелоперів проводити Code Review на проекті для дипломної роботи.
Враховуючи, що геймифікація всього і всія зараз у тренді, то вирішив спробувати саме цей підхід. На проекті це дало поштовх для девів проводити то частіше і якісніше.
Але треба більше респондентів для того щоб результати були показові. Якщо буде вільних 2-3 хвилинки, буду дуже вдячний за проходження опитувальника: ee.kobotoolbox.org/single/Nu6vw9tQ

Також, цікаво послухати як ви вирішували кейси відсутності бажання проводити Code Review у вашій команді.

👍НравитсяПонравилось0
В избранноеВ избранном1
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

В одній з попередніх команд ми домовились описувати пул-реквести (на гатхабі можна сетапити pr-template), щоб рев’юверам було легше зрозуміти що до чого
— Скрішноти/скрінкасти розробленого фунціоналу або посилання на тестовий енв де можна покляцати
— Посилання на на ключові фрагменти коду
— Опис того які фрагменти є чисто «технічними» — переіменування/клінап ітд
— Основні юз-кейси, покриття автотестами
Звісно це все може працювати коли в статичний аналіз коду працює автоматично, і рев’ювер може зосередитись на дійсно важливих моментах.
Але мабуть найважливіше — це культура комунікації і принципи лідерства в компанії. Якщо розробник бачить профіт в проактивній позиції — то він буде зацікавлений і отримувати фідбек і давати його.
Також, з мого досвіду можу сказати що наявність в команді хоча б однієї токсичної людини може обнулити будь-які старання.

У нас на проекте используется скрипт, который раз в какое-то время проходит по всем пулл-реквестам и добавляет двух рандомных ревьюеров там, где их ещё нет.

Я пытался протолкнуть плашки [big]/[small]/[medium]/[tiny] в сабже, но их редко используют.

як можна мотивувати девелоперів проводити Code Review на проекті

1. В настройках проекта на гитхабе выбираешь минимум 2 аппрувала на PR в master.
2. ???
3. PROFIT

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

+ Закрити коміти в мастер, і хай вчаться в бренчі. Можна невеличкий лікбез для них на ту тему зробити.
А от гейміфікація, мотивація — ото все тут зайве.

Максимум зашедулити мітінг, зробити детальну презентацію по новому процессу. Описати переваги, вислухати всіх — домовитись і далі по пунках.

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

Не треба нічого вливати в мастер. git flow вирішує ці проблеми.

git flow зло, потому что long-living branches, trunk-based development FTW.

потому что long-living branches,

сколько в ваших репозиториях живет «master» ?

trunk-based development

это когда вся команда использует единственный бранч, и любой comit требует merge

git flow зло

вам стоит немного глубже разобраться в предмете

сколько в ваших репозиториях живет «master» ?

Имелось в виду feature branches, очевидно.

это когда вся команда использует единственный бранч, и любой comit требует merge

Не в каждой реализации. Если интрумент позволяют делать 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». В то же время, если подбодрить именно желание заниматься этим, играя любовью мозговой обезянки к «заработаным» картинкам и увеличивающимся циферкам, то что-то может и получится, как на меня.

вопрос стоит не «как заставить», а «как мотивировать».

Никак. Или люди понимают, зачем это нужно, или нет.

если это вынести в обязаности
подбодрить именно желание заниматься этим,
что-то может и получится,

Может получиться угробить кучу времени, качество и мотивацию.
Вот вы себе придумали, что «ревью надо», и дальше педалите.
А ревью, само по себе совсем не надо, это типичный культ карго.

як можна мотивувати девелоперів проводити Code Review на проекті... Враховуючи, що геймифікація всього і всія зараз у тренді, то вирішив спробувати саме цей підхід.

Подмена смысла ачивками? Отличный план (нет). Если у взрослых людей нет желания делать нечто, что вообще-то составляет часть их профессиональных обязанностей, то нужно не кровати в борделе переставлять, а разбираться в реальных причинах происходящего.

Распространенная ситуация — люди не глядя ставят Approve на пулл реквесты. То есть там внутри могут быть баги, ошибки безопасности — а ставится approve.

Причины такие:
а) Человек очень сильно доверяет второму («Это ж Колян! Он всегда хорошо пишет»)
б) Человек не знает, что именно нужно ревьювить («Код выровнен красиво — approve»)
в) Человек очень занят своей какой-то задачей, ему не хочется отвлекаться на ревью (но можно же договориться и сделать ревью попозже)
г) Не понимает какие серьезные могут быть последствия и что тесты ловят не все ошибки (это до первых серьезных факапов)

при таком approve ревью формально делается, а практически нет

Я проводжу дослідження того, як можна мотивувати девелоперів

Нащо дослідження, коли є підручник

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

Подписаться на комментарии