Comments 16
Чтобы погрузиться в чужой код, нужно в среднем 15-20 минут. После ревью — еще столько же, чтобы вернуться к своей задаче.
Я сомневаюсь в этих числах.
Вывод: Один пулл-реквест стоит команде почти два дня задержки
С чего бы ожидание реквеста стоило всей команде задержки?
А это значит, что львиная доля времени сеньора тратится не на поиск критичных ошибок, а на наведение красоты. Ту самую красоту, которую мог бы и должен бы обеспечивать линтер, настроенный один раз на весь проект.
И почему в отсутствии линтера виновато review ?
Когда фича «висит» в ревью 2-3 дня, страдает вся команда. Разработчики теряют контекст, не могут двигаться дальше, вынуждены переключаться на другие задачи.
Как-то у вас разработчики быстро теряют контексты.
Статья - нейросетевой мусор с громкими заявлениями.
Ну так разработчики у них тоже нейросетевые, вот и теряют:)
Плюсанул статью. Я тоже сомневаюсь в числах, но в другую сторону. Чтобы погрузиться в контекст задачи, и понять, какая там должна была быть архитектура, иногда требуется пара дней. Не чистого времени, но все же... Почитать ТЗ, понять, что на самом деле хотели, посмотреть, как это повлияет на другие места системы, о влиянии на которые в команде никого даже не думал и не знал...
А есть ещё такой эффект, что ты написал замечаний, а их какие-то поняли не так, какое-то якобы поправили, а на самом деле нет, а вот там просто глупость написана... А на чистоту кода разработчику вообще плевать... И оказывается, что такое ревью просто откладываешь - смотришь тех, кто приличнее делает. А с точки зрения команды - необоснованный простой
5% — это найденные реальные баги
имхо этого достаточно для необходимости код-ревью
70% комментариев в ревью касаются стиля кода и форматирования.
а разве автоформатер кода не решит эту долю проблем?
Кроме самих багов, на ревью исправляются архитектурные ошибки, неудачные решения и т.п.
Да и впринципе нужно мониторить, что народ заливает, пасхалку зальют, или того хуже - бекдор сделают, кто будет отвечать?
Кажется у вас проблема с процессами, а не с ревью.
"Ожидание в очереди 10 часов" -- можно взять за правило, например, начинать рабочий день с проведения ревью. Тогда среднее время в худшем случае будет 8 часов. Можно придумать ещё какие-то соглашения.
"львиная доля времени senior'а тратится ... на наведение красоты" -- что мешает таки настроить один раз линтеры и статические анализаторы, чтобы больше не тратить это время?
"львиная доля времени senior'а тратится ..." -- есть мнение, что выполнять ревью могут не только сеньоры. Если не делать их узким горлышком, то они и не будут тормозить разработку.
"Среднее время жизни PR 2.5 дня" -- опять таки, возможно это специфика конкретных стеков/проектов/команд. Потому что так не везде -- особенно, если стремиться делать небольшие PR.
"Чистое время работы на PR 45 минут" -- см. предыдущий пункт. Если подавляющее число PR состоит из 3-5 файлов, с пятком изменений в каждом, то и ревью обычно требует меньше времени.
В компании не настроены процессы, виновато код ревью.
Почему бы
не настроить линтер/форматтер (предварительно один раз обсудив правила),
поставить pre commit/push чтобы в ПР не проходили исправления линтера,
разбивать задачи максимально на мелкие подзадачи (согласен не всегда это возможно),
не впихивать в ПР несколько изменений (сама задача + рефакторинг + TODO и ид), а только одно изменение на один ПР,
делать информативное описание что ПР делает и какие изменения привносит, чтобы проверяющий получил контекст,
сделать код ревью не уделом синьера, а вовлекать всю команду.
Можно ещё много чего написать, но посыл должен быть понятен.
Узкое горлышко будет если не делать код ревью и мержить всё подряд без разбора. Тогда в итоге рано или поздно проект докатится до состояния, что и этот сеньор не сможет разгрести все проблемы за адекватное время. Ну а если 70% комментов это правки кодстайла, то я вообще сомневаюсь, что там сеньор. Он бы один раз настроил линтеры и не тратил время на такую ерунду.
У нас ревью не отнимает много времени. Обычно мне(лиду) пишут, просят проверить, я сразу смотрю и пропускаю, либо пишу замечания. Если я не могу, либо нужно, чтобы посмотрели и другие заинтересованные разработчики, пишется сообщение в соответствующий чат. Если срочности нет, то вообще не пишется, в течение дня будет проверено. Два дня ничего не висит. Проверять могут все, ограничений по уровням грейда проверяющих мы не устанавливали. Вдумчиво вчитываться, в основном, приходится, когда разработчик менее опытный(доверия меньше)и реквест очень большой. Тогда, обычно, и замечаний много и времени на просмотр тоже. По соотношению - в основном замечания пишутся на организацию кода(разделение на классы, методы, дублирование, паттерны и т.д.). Либо ошибки при использовании фреймворков. На линтовку замечания единичные, обычно все выдерживают примерный стиль, править его приходится крайне редко. Это при том, что линтера на java у нас не установлено, достаточно того, как помогает ide. Польза от этих мероприятий, однозначно, есть. Качество кода прилично подросло с того момента, когда ревью не было, разработчики не тащат дрянь в зависимости, соблюдают архитектурные требования, даже стажеры пишут нормальный понятный код(после кучи замечаний). Команда больше в курсе, кто что разрабатывает и как это организовано. Баги на ревью ловятся крайне редко, ответственность за них больше на исполнителях.
Все эти аргументы из разряда эффективного менеджмента.
Все просто, чтобы не казалось, что время и деньги утекают из-за ревью кода, надо всего лишь закладывать время на ревью кода. Все. Это простая истина.
По поводу наведения красоты, а не поиск критических багов. Да, такая проблема имеет место быть. В прошлой моей команде 2-3 человека из 10 делали вдумчивое ревью кода, а не просто для галочки. И, что не удивительно, к таким людям и ходили с просьбой "посмотри мой код, пожалуйста, что думаешь?"
Проблема здесь не в том, что ревью не нужно, а в том, что ревью для галочки не нужно.
Есть ещё товарищи, которые не умеют и не хотят читать чужой код и плохо разбираются в "подкопотной" фундаментальной логике языка, на котором пишут код. И все потому, что в вакансиях есть строчка в требования "умение читать чужой код", но на деле это умение никто не проверяет, а фундаментальные вещи уже давно никто не спрашивает.
Столкнулась недавно с таким выпадом тимлида: "мы это заливать не будем, потому что много кода получилось" (строк 200). И неважно, что там самые базовые и простые вещи написаны с использованием стандартных библиотек, а количество строк идёт засчет переносов. Читай - мы не будем это заливать, потому что мне лень читать твой код, потому что от многабукв у меня случаются лапки.
Итого, дело не в том, что ревью кода это плохо, а в том, что качество кадров, делающих ревью, падает, а также в том, что эффективные менеджеры не учитывают время на ревью разработанного кода, им всем надо побыстрее влить фичу на прод любой ценой.
работаю в Pl/SQL, pgSQL. Лично мой кодревью ограничивается тем, что я нахлобучиваю джуниора, объясняя, как стоит и как не стоит писать, либо оптимизирую уже написанный код. К оформлению не придираюсь - зато по стилю сразу вижу, кто писал ))) своих коллег я бы отсылал на какие нить жесткие курсы, что бы их учили писать оптимальный и красивый код )))
Бред бредовый.. начиная с не настроенного литера. Выгорание на ревью серьезно?
Эффективного менеджера порвало
Код-ревью — самое узкое горлышко в разработке. И вот цифры, которые это доказывают