Вхід і реєстрація
Навчання · 8 листопада 2020, 13:47 896
Andrii Yushchenko, Software Engineer в SoftServe

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

Доброго дня,

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

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

Теми: 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
Anton Shanyuk Frontend Team Leader в Giftcard Group 14.11.2020 15:43

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

Відповісти
Підтримати
Konstantin Uvarin Perl developer в WebbyLab 11.11.2020 16:14

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

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

Відповісти
Підтримати
Roman Gorodishcher Principal Engineer в Twilio 09.11.2020 12:15
як можна мотивувати девелоперів проводити Code Review на проекті

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

Відповісти
Підтримати
Andrii Yushchenko Software Engineer в SoftServe 09.11.2020 12:52

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

Відповісти
Підтримати
Roman Gorodishcher
Леголас Трандуилович 09.11.2020 13:20

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

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

Відповісти
Підтримати
Andrii Yushchenko
Konstantin Uvarin Perl developer в WebbyLab 11.11.2020 16:18

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

Відповісти
Підтримати
Andrii Yushchenko
Андрей Литвинов C Señor 14.11.2020 14:44

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

Відповісти
Підтримати
anonymous
Java Bee 16.11.2020 13:13
потому что long-living branches,

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

trunk-based development

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

git flow зло

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

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 16.11.2020 13:41
сколько в ваших репозиториях живет «master» ?

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

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

Не в каждой реализации. Если интрумент позволяют делать peer review, проганять CI и разные Quality Gate для каждого коммита, то, да, можно и без бранчей. Если нет, то конечно, без short-lived веток не обойтись. Я думаю разница между short-lived и long-lived веткаим понятна, если нет, спрашивай. Вот норм ресурс trunkbaseddevelopment.com если интересны детали.

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

Я достаточно глубоко разбирался в вопросе, но спасибо за рекомендацию 😉

Відповісти
Підтримати
Java Bee
Java Bee 16.11.2020 13:18

Речь о том, то github позволяет настроить разрешения для merge into master, только для пулл риквестов, прошедших ревью.
git flow не имеет к этому отношения.

Відповісти
Підтримати
anonymous
Sergei Starovoi senior C++ developer в Intellias 09.11.2020 11:51

Что значит відсутність бажання, лол? ) Ревью кода — такая же рабочая обязанность, как и его написание.

Человеческая цивилизация в итоге погибнет от инфантилизма, а не от какого-то там ядерного апокалипсиса.

Відповісти
Підтримати
Олег Дорожко 09.11.2020 11:56

Надо перечислить в официальном документе компании ОБЯЗАННОСТИ
— ревью
— документирование
— покрытие тестами

Відповісти
Підтримати
Sergei Starovoi
Java Bee 09.11.2020 14:10
Что значит відсутність бажання, лол? )

Например, у вас не сходятся взгяды с коллегой, и вы знаете, что ваш фидбек будет проигнорирован. Зачем тратить свое время?

Ревью кода — такая же рабочая обязанность, как и его написание.

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

p.s. например, ваш коллега-синьйор «родил» метод, работающий, за O(n^2), когда можно и за O(1). Вы ему про это пишете, а он спрашивает «что такое O(1) и зачем оно тут нужно» (пример из жизни).
Будете дальше тратить свое время, и за него все переделывать?

Відповісти
Підтримати
Sergei Starovoi
Sergei Starovoi senior C++ developer в Intellias 09.11.2020 15:29

Просто не нужно работать там, где фидбек молча игнорируется и синьоры не знают про O-нотацию. В таких местах желание/нежелание проводить код ревью — наименьшая из проблем.
Очевидно, что ревью, как и любой другой инструмент, может приносить пользу только там, где хоть как-то налажены процессы: программисты умеют программировать и разговаривать друг с другом, как минимум.

Відповісти
Підтримати
Java Bee
Java Bee 09.11.2020 18:16
Просто не нужно работать там, где ...

— Доктор, когда я делаю вот так, у меня тут болит.
— А Вы так не делайте.

Відповісти
Підтримати
Sergei Starovoi
Андрей Литвинов C Señor 14.11.2020 14:45
программисты умеют программировать

Это где ты такое видел?

Відповісти
Підтримати
Sergei Starovoi
honeybadger 09.11.2020 15:12

Code Review это инструмент, а не обязанность, в большинстве случаев полезный, но не незаменимый. И в данном случае такой карго культ ничем не лучше чем

відсутність бажання

такой же инфантилизм, только вид с другой стороны.

Відповісти
Підтримати
Sergei Starovoi
Sergei Starovoi senior C++ developer в Intellias 09.11.2020 16:11
это инструмент, а не обязанность, в большинстве случаев полезный, но не незаменимый

Этот трюизм можно применить к чему угодно: написание тестов, соблюдение кодстайла, следование best practices — все это «инструмент, а не обязанность», «в большинстве случаев полезно, но не незаменимо». И?
Если задачи на проекте чуть сложнее передвигания кнопочек на фронте, и есть необходимость развивать/поддерживать его в будущем — код ревью является необходимым условием для поддержания приемлемого уровня качества. Если команда действительно в код смотрит, конечно, а не просто молча жмет на approve.

Відповісти
Підтримати
honeybadger
honeybadger 09.11.2020 16:47

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

Відповісти
Підтримати
Sergei Starovoi
Java Bee 09.11.2020 11:04

Code review, как правило, имеет 3 цели:
— knowledge sharing — возможность что-то показатать, тому, кто про это иначе бы не узнал
— responsibility sharing — возможность заручится поддержкой реализованного решения
— feedback — как следствие 2х предыдущих, кто-то может поделиться собственным knowledge или отказаться от responsibility (при этом обосновав почему)

Но это всего лишь инструмент, просто применяя code review вы не можете никого заставить смотреть ваш код, или давать фидбек.
Между самим процессом code review, и code quality нет вообще никакой кореляции.

Кореляция есть между code quality и желанием команды заниматься knowledge sharing, responsibility sharing и давать взаимный feedback.

Відповісти
Підтримати
Andrii Yushchenko Software Engineer в SoftServe 09.11.2020 12:58

Вот именно поэтому тут вопрос стоит не «как заставить», а «как мотивировать». Есть подозрения что если это вынести в обязаности, и ПМ будет ходить делать бо-бо тем, кто не делает ревью, то все закончится тем, что люди просто будут заходить поставить галочку «Approve». В то же время, если подбодрить именно желание заниматься этим, играя любовью мозговой обезянки к «заработаным» картинкам и увеличивающимся циферкам, то что-то может и получится, как на меня.

Відповісти
Підтримати
Java Bee
Java Bee 09.11.2020 14:01
вопрос стоит не «как заставить», а «как мотивировать».

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

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

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

Відповісти
Підтримати
Andrii Yushchenko
Konstantin Strukov 09.11.2020 10:51
як можна мотивувати девелоперів проводити Code Review на проекті... Враховуючи, що геймифікація всього і всія зараз у тренді, то вирішив спробувати саме цей підхід.

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

Відповісти
Підтримати
Olena Sharovar Node.js/JS в Waverley 09.11.2020 08:16

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

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

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

Відповісти
Підтримати
Олексій Пєніє 09.11.2020 04:12
Я проводжу дослідження того, як можна мотивувати девелоперів

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

Відповісти
Підтримати
Олег Дорожко 09.11.2020 11:46

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

Відповісти
Підтримати
Олексій Пєніє

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.