Замедление из-за код-ревью

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

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

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

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

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

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

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

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

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

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

Я согласен с другим сообщением (что вам не следует слишком беспокоиться об этом, и что это хорошо отражается на вас). Но я бы также добавил, что я могу придумать два способа, которыми вы могли бы уменьшить объем «работы по проверке кода» для ваших коллег:

Убедитесь, что каждое изменение максимально тщательно протестировано.

В частности, если вы застряли в цикле:

1. Новая особенность
2. Обзор кода
3. Исправить 1 для новой функции
4. Обзор кода
5. Исправить 2 для новой функции
6. Обзор кода

и т. д. и т. д.

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

Минимизируйте количество нового/измененного кода на новую функцию

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

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

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

• Старайтесь вносить как можно меньше изменений в каждый PR, чтобы ускорить их рассмотрение.
• Сделайте PR-описание как можно более подробным относительно того, что вы меняете и почему. Любые изменения пользовательского интерфейса должны иметь скриншоты до и после. Это дает рецензентам контекст изменения, чтобы им было легче идентифицировать вещи, которые могут быть непреднамеренными.
• Новые PR публикуются на канале нашей команды в Slack для повышения видимости. Если вы работаете в домене другой команды, PR также публикуется в их канале Slack.
• Если вы работаете в домене другой команды, попросите помощи у этой команды в выполнении этой работы для начала, чтобы PR не стал неожиданностью. Вы также с гораздо меньшей вероятностью сделаете что-то, чего они предпочли бы, чтобы вы не делали.
• Каждое утро и после обеда каждый член команды тратит 15–30 минут на рассмотрение невыполненных PR. Обычно мы делали это первым делом утром и когда возвращались с обеда, чтобы было меньше шансов забыть.
• Если PR не был рассмотрен более 24 часов, устно напомните об этом команде.

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

Попробуйте упаковать свою работу и упростить рецензирование. Оцените время, необходимое для рассмотрения элементов.

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

С другой стороны, вы можете собрать все вместе в один растущий запрос на проверку. Но это своего рода толчок в направлении, в котором вы, кажется, не хотите идти. Каждый раз, когда вы завершаете новую единицу кода, добавляйте ее к этому отдельному запросу и обновляйте общее время. Возможно, люди просто не думают о росте отставания. Если ваш менеджер видит запрос на проверку кода и говорит: «Это запрос на проверку кода для элемента X, совершённого {x/x/x} | {21 дня назад}, элемента y, совершённого {x/x/x} | {20 days ago}, item... Просмотр этих 200 элементов займет примерно 40 часов", и это поможет понять суть дела.

Ваша цель — создать программное обеспечение, которое работает, и о котором известно, что оно работает, с наименьшими возможными затратами (и затратами обычно являются сотрудники, которым платят, и, надеюсь, никогда не стоимость недовольных клиентов). Если ваша производительность падает до 20% из-за код-ревью, похоже, что-то не так.

Ваши шаги перед обзором кода должны быть следующими: Напишите код, который компилируется. Поместите его в состояние, в котором вы бы его передали, если бы вам пришлось просмотреть его (за исключением ошибок, которые случаются). Протестируйте его, чтобы вы могли сказать, что «это работает», модульные тесты могут помочь, но они должны работать с вашим тестированием. (Предположим, что QA лучше тестирует, чем вы.) Объедините вашу текущую основную линию с вашей веткой, чтобы не возникало конфликтов слияния. А потом вы выставляете его на код-ревью.

Затем обсудите роль и полномочия рецензента. Вы должны исходить из того, что автор и рецензент одинаково способны. Таким образом, обзор должен найти ошибки, которые необходимо исправить, в самый ранний момент времени. Личные мнения автора и рецензента не должны иметь значения. У разных людей разные стили. Заставлять автора адаптировать код под стиль рецензента и делать наоборот в каком-то коде, где роли меняются, — это пустая трата времени. И важно: не просматривайте ничего, кроме изменения. Если вы являетесь рецензентом и обнаружили рядом с изменением что-то, что вам не нравится , сделайте заметку, предложите это как изменение команде или менеджеру по продукту, но держите это вне обзора .

А раз вы за этим следите - зачем вам два рецензента? Один рецензент будет полезен. Насколько вообще помогает второй рецензент?

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

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

Что хотелось бы добавить от себя:

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

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

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

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

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

• Вы также можете потратить больше времени на увеличение покрытия кода тестами.

Редактировать

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

Наша команда разработчиков согласилась с тем, что весь код, внесенный в проект, должен быть проверен.

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

Как мы это делаем в нашем (меньшем) магазине:

Фаза 1: Первые 3 месяца (испытательный срок), все проверяется. Разработчик узнает, как мы работаем, как устроена система, как найти существующий код, который следует использовать повторно (в отличие от переписывания/дублирования), соглашения об именах, форматирование и т. д. Мы оцениваем способности/талант разработчика. По истечении этого периода разработчика либо оставляют, либо отпускают.

Предполагая, что разработчик сохранен, мы переходим ко второму этапу:

Фаза 2: Как только разработчик понимает, как мы кодируем в конкретной кодовой базе, он самостоятельно проверяет. У разработчика есть возможность запросить проверку в любое время, но они не являются обязательными. Они возвращаются, смотрят на свой коммит и убеждаются, что все в порядке. Мы доверяем разработчику, и он несет ответственность за усердие на этом этапе. Коммиты доступны всем, поэтому менеджер или руководитель могут продолжать отслеживать коммиты или пробовать их. Это снижает стоимость вдвое. Если разработчик не проявляет усердия на этом этапе, с ним нужно поговорить.

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

Так что я собираюсь принять противоположную точку зрения здесь. Я работал с [УДАЛЕНО КРУПНАЯ КОМПАНИЯ ПО ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ] в течение 6 лет и, пройдя этап наращивания производительности, обнаружил, что моя производительность стабилизировалась примерно на 20% от того, что было до (и после), из-за обязательных проверок кода, происходящих в разные часовые пояса.

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

Стратегии выживания, которые я нашел, следующие:

• Если у вас есть право голоса в тех, кто проверяет ваш код , используйте это право с умом. Заставить кого-то доверять вам, чтобы ваши обзоры кода были быстро подтверждены, — это хорошо; лучше утолить чей-то зуд (каким бы он ни был) до такой степени, что он передаст вам Perforce OWNERShip кода и оставит ваши руки свободными для реализации любых ваших злых планов.
• Используйте Git и частные ветки и опережайте рецензентов кода настолько, насколько это возможно. Если ваш магазин не использует Git, потратьте столько времени, сколько потребуется, чтобы установить/создать шлюз между внутренней системой контроля версий и Git.
• Смиритесь с этим и планируйте отставание выпущенного кода на дни или недели от вашего совета Git, потраченное время на перебазирование поверх изменений других людей с лучшими связями или EQ , как у вас, и т. д. и т. д.

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

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

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

Теперь есть два предостережения, о которых следует помнить: одно относится непосредственно к вашей ответственности, а другое — с точки зрения эффективности компании.
1. Во-первых, личное, вы, очевидно, хотите, чтобы переделок было как можно меньше. Что-то ожидаемо, возможно, даже желательно, многое - проблема.
2. Во-вторых, и это более специфично для отрасли, вы хотите максимально упростить рецензирование своей работы. Если проверка качества занимает больше времени из-за того, что вы не предприняли дополнительных шагов, необходимых для того, чтобы тестирование было простым и понятным, это можно свалить на ваши ноги, особенно если ваши коллеги предпримут шаги, чтобы помочь тестировщикам. Таким образом, сделать его легко тестируемым можно считать частью подготовки к обзору.