Как сделать лучшие обзоры кода при больших запросах?

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

проблема

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

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

У меня проблемы с мыслительным процессом автора кода. Это довольно сложно, когда изменения многочисленны и распространяются на несколько файлов. Я стараюсь сосредоточиться на группах файлов, связанных с определенной частью изменений. Затем просмотрите группы по одной. К сожалению, инструмент, который я использую (Atlassian Bitbucket), не очень полезен. Всякий раз, когда я посещаю файл, он помечается как видимый, хотя часто оказывается, что он не связан с рассматриваемым фрагментом изменений. Не говоря уже о том, что некоторые файлы нужно посещать несколько раз, а их изменения анализировать по частям. Также возвращаться к соответствующим файлам, когда вы идете по неверному пути, нелегко.

Возможные решения и почему они не работают для меня

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

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

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

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

Вопросов

• У вас есть похожие проблемы с вашими отзывами кода? Как ты с ними сталкиваешься?
• Может быть, у вас есть лучшие инструменты?

У нас были эти проблемы, и заданный ниже вопрос работал хорошо для нас:

PR делает одну вещь, которая может быть объединена и может быть независимо протестирована?

Мы пытаемся сломать PR единоличной ответственностью (SR). После первоначального толчка люди были удивлены, обнаружив, что даже что-то маленькое, хотя и одиночное, может быть большим.

СР позволяет действительно легко анализировать, а также распространять знания об ожидаемой реализации.

Это также учитывает инкрементные рефакторы, так как добавляется больше и время обработки PR резко сокращается!

Я бы посоветовал разбить их по СР, если это возможно, и посмотреть, сработает ли это для вас. Требуется некоторая практика, чтобы сделать это таким образом.

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

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

Как и в случае с любым другим аргументом, у него должна быть четкая идея. Это либо:

• рефакторинг,
• оптимизация,
• или новый функционал.

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

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

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

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

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

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

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

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

«Часто» расплывчато, но если вы тратите слишком много времени на просмотр кода, который не нашел пути к окончательному пересмотру запроса на извлечение, вы можете использовать два метода:

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

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

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

^{Imagine Например, представьте, что вы смотрите на файл, в котором некоторая переменная была переименована. Что это говорит тебе? Как вы должны проверить это изменение? Однако, если бы вы просматривали коммит с фиксацией, вы увидите, что один коммит переименовал одну и ту же переменную в двадцати файлах, и комментарий указывает, что имя было изменено, чтобы использовать правильный бизнес-термин. Это изменение имеет смысл и может быть рассмотрено.}

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

Например, вы можете захотеть

• Обеспечить соблюдение стандартов
• Проверьте работоспособность
• Убедитесь, что несколько человек понимают код
• Тренировка юниоров

и т. д.

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

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

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

Вам не нужно проверять все вещи в каждом PR, если у вас есть многоуровневый подход к QA