коллеги не хотят делать код-ревью

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

То, как мы работаем с кодом в моей компании, заключается в том, что у нас есть репозиторий по командам (примерно), и каждый коммит должен сначала пройти этап проверки кода в gerrit, прежде чем его можно будет объединить в репозиторий команды. Единственные люди, которые имеют право принять слияние ожидающей фиксации в репозитории, — это люди из команды. У нас также есть неофициальное правило: ни одна фиксация не должна оставаться непроверенной более 24 часов или около того.

Теперь, за последние 10 дней или около того, я отправил более 15 коммитов и почти не получил отзывов ни по одному из них. В лучшем случае мой первоначальный коммит был объединен, но у меня все еще есть 14 не объединенных коммитов, которые требуют проверки кода уже более недели.

Что я могу сделать, чтобы решить эту проблему? Команда, с которой я работаю, состоит из 3 человек, один из которых является достаточно старшим, чтобы делать обзоры, но предпочел бы, чтобы другие младшие работали и делали обзоры. Двое других джуниоров очень не хотят делать обзор, так как чувствуют, что не могут достаточно понять код из-за отсутствия реальных знаний в языке, и в результате они не берут на себя ответственность за утверждение моего кода.

В течение последних ~ 5 дней мой статус на стендапе был «Я застрял из-за отсутствия проверки кода», и я даже забронировал 30-минутную встречу, чтобы провести команду по коду и объяснить, что я делаю. в обзорах. Теперь я нахожусь в точке, когда я не буду продолжать работу, поскольку это слишком сложно для работы с гигантским стеком накопленных коммитов, код которых может измениться.

Любая идея о том, как решить эту проблему? Спасибо!

Какова реакция команды, когда вы говорите, что застряли? Вы просили их взглянуть на ваш код СЕЙЧАС ?
Вы обсуждали это со своим начальником?
«Они чувствуют, что не могут достаточно понять код из-за отсутствия реальных знаний в языке». Выражал ли старший разработчик когда-либо озабоченность по этому поводу перед младшими?
Как это связано с вашим выступлением? Если коммиты не слиты/просмотрены и висят там, имеет ли это значение? Если кто-то спрашивает о вашем прогрессе, говорит ли, что вы отправляете свой код на проверку, законный ответ, который снимает вас с крючка?
@Konrad Когда ваши изменения накапливаются в нескольких запросах на вытягивание, ветвление и слияние становятся тяжелым обслуживанием, у вас появляются ветки ветвей из-за некоторых зависимостей, а также усиливается конфликт слияния. Эти элементы влияют на вашу производительность, потому что люди, которые не просматривают ваш код, несут накладные расходы. Я согласен с OP, что в какой-то момент лучше выполнять другие задачи, такие как обучение, добавление функций будущего и помощь перегруженным коллегам, чтобы они могли одобрить ваш PR :)
Обычно выход далеко за пределы необъединенной территории был бы проблемой, но рассматриваемая функция описывается как «отчасти автономная», поэтому, если проблема здесь в том, что у старших лидов нет времени на ее оценку, может быть необходимо просто продолжайте продвигать уникальную ветвь. Однако это следует делать с осознанием того, что может потребоваться существенная очистка и переписывание, прежде чем его можно будет снова объединить с основной работой. И пересматривать нужно не только код , но и всю стратегию того, что и как делается, что также может потребовать некоторого переписывания.
Наверняка есть менеджер или руководитель группы, которому вы можете сообщить об этом.

Ответы (5)

В этих сценариях нужно сделать несколько вещей, и я рекомендую сделать обе:

  1. Быть инициативным. Объясните преимущества того, что вы пытаетесь убедить их сделать. В вашем случае объясните, что проверка кода находит глупые ошибки и является отличным способом поделиться знаниями с коллегами. Изменить: кроме того, он может обеспечить обучение, как указывает @Upper_Case. Вот более длинный список преимуществ проверки кода .
  2. Четко объясните проблему руководителю или тому, кто имеет полномочия на внесение изменений. Должно быть очень легко объяснить вашему менеджеру (который одолжил вас этой команде) и менеджеру этой команды, что вы ничего не можете сделать, потому что никто не будет проверять ваш код. Не будьте слишком эмоциональны, но убедитесь, что они понимают, что вы не можете продуктивно продолжать работу, потому что будущий код строится на том, что вы уже сделали (люди, знакомые с программным обеспечением, должны легко понять это).

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

Отличный ответ! Еще одним преимуществом проверок кода будет то, что коллеги, которые не уверены в своих навыках владения этим языком, смогут немного их развить.
из интереса, что такое «тесты» в этом сценарии?
Тесты @Kilisi — это код, который гарантирует, что ожидающие коммиты работают правильно.
Тесты @dbeer должны выполняться одновременно с обзором, а не после. они также иллюстрируют, как работает код, а что нет.
@AndréWerlang согласился. Если вы посмотрите на мой комментарий от 24 октября, я имею в виду написание тестов для ожидающих коммитов. Я отредактирую ответ для ясности.

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

В остальном я проделал значительную работу самостоятельно, без сторонних рецензентов. Каждое изменение проверял лично я. Нужно немного сосредоточиться, чтобы избавиться от ощущения, что вы никогда не сделаете ошибок, но это намного лучше, чем полное отсутствие обзора.

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

Два возможных подхода:

Во-первых: попросите старшего разработчика (при условии, что он обладает необходимыми знаниями) просмотреть ваш код в установленные сроки (5 минут на коммит или сколько ему угодно). Если это будет отклонено, перейдите к 2:

Второе: объедините свой код и дождитесь отчетов о дефектах.

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

Если ни у кого нет времени или знаний, чтобы сделать это за вас, и крайне важно, чтобы ваши исправления были доведены до клиента, задрайте люки настолько, насколько сможете (т. и ждите ошибок.

Я .-1 это потому, что это кажется сюрреалистично неправильным. Если никто не имеет права делать это, это все равно не ИМ фетишизирует обзоры, это фундаментальная проблема, созданная плохим управлением, которую ЕГО не решить. Там тоже был - если менеджер не уберет фетиш, это требование. Бывает.
Нет, не нарушайте процедуру слияния кода (и вдвойне не в качестве нового и временного члена команды), это приведет к еще большему беспорядку для всех , особенно по наиболее вероятной причине, по которой старший разработчик не просматривает код. code заключается в том, что они либо находятся в разгаре чего-то сложного и более приоритетного, либо существуют довольно глубокие разногласия по поводу предлагаемых изменений, на которые у них пока нет времени вникать.
@ChrisStratton Если они не хотят проводить обзоры кода, возможно, это потому, что они не понимают его ценности. Для них вы как Ламберг, который хочет, чтобы они помещали титульные листы в отчеты TPS. Вот почему некоторые компании спрашивают об этом в процессе собеседования. Хорошие компании ценят опыт и понимание методологий, а не просто X лет опыта работы с языком Y и фреймворком Z.
@dan-klasson - я думаю, что более вероятно, что они не видят текущей выгоды от кода , который нужно проверить, т. Е. Проект ОП немного тангенциален к тому, о чем в настоящее время беспокоит эта занятая команда, поэтому, хотя в конечном итоге это необходимо и они, вероятно, очень заботятся о том, как это выглядит , это не то, с чем старшие люди хотят иметь дело прямо сейчас . Сброс несанкционированного и нежелательного слияния посреди того, о чем они беспокоятся, — отличный способ нажить себе врагов. ОП всегда может спросить: «Не возражаете, если я просто объединю это?» но определенно не должен просто делать это.
or the knowledge to review your work- это не может рассматриваться как уважительная причина. Обзоры кода помогают разделить бремя знаний. Один из тех, кого вы просите проверить, может быть вызван в 3 часа ночи, чтобы поддержать производственную проблему с кодом. Действительно ли они предпочли бы остаться без какой-либо информации или, по крайней мере, вооруженной ею?

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

Пришло время передать это руководству, если оно у вас есть, и указать, что команда блокирует вашу работу, потому что они отказываются проводить проверки кода, подробно описать ваши усилия по выполнению этого и попросить помощи в продвижении этого.

Если это действительно agile-команда, практически не имеющая контроля со стороны руководства, пришло время взять на себя ответственность. На стендапе нужно сказать:

Я заблокирован на этом. Мы НЕ МОЖЕМ продвигаться вперед по ЛЮБОЙ ДРУГОЙ РАБОТЕ, пока это не будет решено. Мы не покинем эту комнату, пока не будут проведены проверки кода, все готово, все будут участвовать.

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

Можно, конечно, спросить, но это необходимо, особенно в качестве нового и временного члена команды , чтобы быть открытым для того, чтобы ему сказали, что другая работа имеет более высокий приоритет. Хотя это может быть сбой процесса и использования ресурсов, это также может быть реальной реальностью.
  1. Объясните джуниорам важность проверки кода.
  2. Обучите джуниоров тому, как проводить код-ревью.
  3. Запланируйте личные встречи для проверки кода с вашими рецензентами. Обычно я отправляю приглашения в календарь Google.
коллеги не хотят делать код-ревью
СпросиСетьПолитика конфиденциальности1y, 0v