Представьте, что внутри корпорации ваш коллега попросил вас просмотреть кусок кода, написанный им. Это может немного нервировать вас, если вы не очень хорошо знакомы с рецензированием чужого кода, поскольку это может показаться проверкой ваших собственных способностей. Но в буквальном смысле это просто еще один эффективный метод, используемый почти каждой компанией-разработчиком программного обеспечения для обнаружения ошибок на более ранней стадии жизненного цикла разработки программного обеспечения. В этой статье представлены некоторые рекомендации, которые вы можете использовать при просмотре кода.
Что такое проверка кода?
Код-ревью также известен как коллегиальный код-ревью. Это систематический совместный процесс, в котором один или несколько членов команды проверяют работу другого товарища по команде, чтобы предоставить некоторые комментарии, потенциальные улучшения или список вопросов, на которые нужно ответить.
Существует четыре распространенных подхода к проверке кода.
1. Тема электронной почты
Когда код будет готов для проверки, файл будет отправлен по электронной почте соответствующим партнерам для оценки. Этот подход является более гибким и техническим, чем традиционные методы, такие как сбор пяти человек в комнате для проверки кода. Но цепочка предложений и различных мнений по электронной почте может быстро усложниться, а первоначальный кодировщик должен будет все это упорядочить.
2. Парное программирование
Как следует из названия, парное программирование — это когда два разработчика вместе работают над одним и тем же кодом, используя одну машину. Здесь один программист пишет код, а другой наблюдает за написанным кодом, корректирует его и проверяет орфографию, а также решает следующие шаги. Эти две роли можно поменять местами в любой момент, когда автор становится наблюдателем и наоборот. Это хороший способ для старших разработчиков наставлять младших разработчиков, поскольку это эффективный способ обмена знаниями и развития их навыков межличностного общения.
3. Через плечо
Это самый простой и неформальный обзор кода. Как только код будет готов, просто найдите квалифицированных разработчиков, которые будут стоять у рабочей станции автора и просматривать код, пока автор объясняет цель кода и разъясняет ее рецензенту. Проверка через плечо позволяет команде учиться и обмениваться знаниями между разработчиками, и ее легко развернуть, когда вам это нужно. Но с другой стороны, нет документации, метрик или инструментов для отслеживания и измерения этой процедуры.
4. С помощью инструментов
Проверка кода с помощью инструментов включает использование программных инструментов для облегчения процесса проверки кода. В целом, эти инструменты могут помочь вам организовать и отобразить обновленные файлы, способствуя эффективному общению между разработчиками и рецензентами, предоставляя автоматизированные показатели для понимания процесса. Инструмент проверки кода автоматизирует инструмент проверки кода, позволяя рецензенту полностью сосредоточиться на коде. Чтобы без труда интегрировать инструмент в свой рабочий процесс, вы можете выбрать тот, который совместим с вашими технологиями.
Зачем код-ревью?
Независимо от того, являетесь ли вы ведущим разработчиком программного обеспечения или программистом, вы можете игнорировать преимущества проверки кода. При правильном проведении коллегиальная проверка экономит время и сокращает значительный объем работы, требуемой от групп контроля качества. Проверка кода — это часть процесса разработки программного обеспечения, которая включает в себя тестирование исходного кода и проверку того, что ваш код не содержит ошибок на ранней стадии. Это снижает вероятность получения каких-либо дефектов позже. Кроме того, это повышает эффективность кода и подтверждает, что новый код соответствует рекомендациям. Обзор кода помогает улучшить знания членов команды. Поскольку обзор кода часто выполняется старшими разработчиками программного обеспечения, младший разработчик может использовать советы или комментарии для улучшения своих собственных навыков кодирования.
Лучшие практики проверки кода
Проверка кода — это сотрудничество, а не конкуренция. У нас есть несколько простых советов и лучших практик, которые могут помочь вам сделать так, чтобы члены вашей команды доверяли вам проверку кода, который они написали.
1. Поймите, что делает код.
Первое и самое важное, что вы должны сделать при обзоре кода, — это определить назначение кода. Знание цели кода имеет решающее значение, поскольку это позволит вам предоставить идеальный обзор кода с полезными комментариями.
Обычно автор объясняет код до того, как происходит проверка, и проводит рецензента по изменениям, важным файлам и предоставляет подробный контекст. В этом процессе ищите такие ключевые вещи, как структура кода, логика, производительность, дизайн и стили, читабельность и ремонтопригодность, функциональные возможности и покрытие тестами.
Вы можете автоматизировать определенные задачи, такие как просмотр структуры и логики, но есть некоторые факторы, такие как дизайн и функциональность, для оценки которых требуется вмешательство человека. В конце процесса пошагового руководства вы можете сами задать следующие вопросы, чтобы убедиться, что вы понимаете код.
● Есть ли у вас вся необходимая справочная информация?
● Правильно ли вы понимаете требования кодекса?
● Вы понимаете, как код способствует полному выполнению этих требований?
Тщательно просматривая код, помня об этих вопросах, вы можете гарантировать, что правильно проверили то, что нужно.
2. Ставьте цели, используйте контрольный список и измеряйте прогресс
Перед внедрением процесса команда должна четко определить цели проведения проверки и ожидания рецензентов. Трудно привлечь всю команду к анализу кода. Он должен быть включен в распорядок дня сотрудников.
Чрезвычайно полезно иметь контрольный список с наиболее важными вещами для проверки в коде. Если код не так чист в начале, лучшим подходом будет использование короткого контрольного списка. Это поможет команде быстро и легко улучшить качество кода. Здесь мы привели пример краткого контрольного списка.
● Убедитесь, что код, который вы читаете, понятен.
● Убедитесь, что имена переменных выбраны правильно.
● Убедитесь, что методы правильно названы и параметризованы.
● Убедитесь, что код соответствует общим принципам кодирования.
● Убедитесь, что код соответствует указанному требованию.
Как только основные вопросы будут решены, вы можете добавить дополнительные критерии в контрольный список. Нравиться,
● Убедитесь, что код соответствует принципам SOLID.
● Убедитесь, что в коде нет ненужных дубликатов.
● Убедитесь, что код правильно обрабатывает исключения.
● Убедитесь, что в исходный код добавлены все необходимые комментарии.
Это лишь некоторые распространенные примеры, которые вы можете использовать при просмотре кода, но не забывайте систематически обновлять свой контрольный список, поскольку технологии быстро совершенствуются, а наши знания также развиваются очень быстро.
Контрольные списки проверки кода предоставят членам команды четкие ожидания и последовательность. Таким образом, программисты могут просматривать код друг друга с учетом одних и тех же критериев. Четко сообщая о целях и ожиданиях, команда может сэкономить время в процессе проверки. Для измерения прогресса вы можете использовать следующие индикаторы, но они могут отличаться от одного кода к другому.
● Скорость завершения обзора.
● Количество ошибок, обнаруженных в час.
● Среднее количество дефектов, обнаруженных на строку кода.
Существуют автоматизированные инструменты, которые собирают данные автоматически, что может гарантировать правильность информации и отсутствие ошибок, связанных с человеческим фактором.
3. Просматривайте не более 400 строк за раз
Сосредоточение внимания на менее чем 400 строках за раз повышает эффективность проверки кода. Способность мозга находить дефекты уменьшится, если вы попытаетесь оценить слишком много строк одновременно. Следовательно, удобнее анализировать небольшие фрагменты кода, что приводит к короткому обзору кода и улучшению кода. При проверке кода каждая сессия должна быть ограничена 200–400 строками и известна как строка кода (LOC).
4. Не просматривайте более 60 минут
Итак, сколько времени вы можете практически выделить на каждую сессию обзора? 60 минут — это хорошее число, когда вы можете просто сосредоточиться на задаче, не уставая. Код-ревью лучше проводить короткими сессиями. Через час сделайте перерыв, выпейте чашечку кофе и расслабьтесь. Затем вернитесь к работе с обновленным умом. Небольшие перерывы позволят вашему мозгу перезарядиться, и в результате вы сможете пройти через все заново с новыми глазами. Вы будете более эффективно находить ошибки и дефекты. В конечном итоге это повысит качество кодовой базы.
5. Развивайте позитивную культуру
Старайтесь распространять положительные эмоции вокруг отзывов. Это очень важно, потому что коллегиальная оценка имеет тенденцию влиять на межличностные связи между членами команды, поскольку есть группа людей с разным поведением, и некоторые из них могут воспринимать критику лично. Таким образом, менеджер несет ответственность за создание культуры сотрудничества и обучения с позитивным настроем. Что действительно важно, так это ошибка, которая была обнаружена до выпуска продукта. Не тот автор, который внес ошибку. Есть за что благодарить и праздновать. Воспитание позитивной культуры поможет команде ценить своих коллег, избавиться от вредных привычек и расширить свои возможности.
6. Позвольте всем участвовать в процессе проверки кода
Все в команде, от младшего до старшего, должны проверять код других и быть проверенными товарищами по команде. Люди, как правило, работают лучше, когда знают, что кто-то будет оценивать их работу. Такова человеческая природа, но это улучшает качество работы. При проведении обзоров привлекайте инженера-программиста, архитектора программного обеспечения, инженера UI/UX, даже младших разработчиков и стажеров. По сути, это должно быть сочетание разных должностей. Таким образом, они могут выявлять различные проблемы не только в кодовой базе, но и в общем дизайне программного обеспечения.
Еще одним особым преимуществом является то, что младшие разработчики могут учиться у старших разработчиков в процессе проверки. Особенно когда речь идет о новых столярах, им может быть немного сложно и тяжело начать новую работу в новой фирме. Их стиль программирования может быть разным, и кодовая база тоже для них новая. Так что хорошо, если команда может уделить дополнительное внимание тому, чтобы первые несколько обзоров были более мягкими, чтобы новые участники могли привыкнуть к новой среде. Рецензенты должны понимать, что новичок может быть не знаком со всеми правилами кодирования. Они должны быть достаточно любезны, чтобы объяснять новичкам альтернативные подходы весьма ободряющим тоном.
7. Создайте процесс исправления дефектов
Должна существовать подходящая процедура для исправления дефектов и подтверждения их устранения. Самый идеальный подход — использование платформы для совместной работы, такой как GitHub. Это позволяет вашей команде создавать процессы проверки, которые улучшают качество кода и хорошо вписываются в ваш рабочий процесс. В GitHub вы можете просто оставлять подробные комментарии к синтаксису кода, задавать вопросы или оставлять отзывы вместе со своим кодом. Есть несколько фактов, которые следует учитывать при добавлении комментариев и утверждении изменений.
Один придирается. Это относится к неважным комментариям, например,
● Объявление переменных не в алфавитном порядке,
● Модульные тесты не соответствуют определенному формату.
● Скобки не на одной линии.
Эти простые ошибки можно исправить с помощью автоматизированного линтинга. Слишком много придирок может раздражать и отвлекать внимание от критических частей проверки кода.
Второй совет: будьте уважительны. Всегда старайтесь избегать негативного поведения и абсолютных суждений. Не обижайтесь на предложения, которые дает вам рецензент, даже если вы с ними не согласны. Отвечайте на каждый комментарий и придерживайтесь хорошей рабочей этики. Делая свои комментарии, постарайтесь быть конкретными и описательными. Иногда уместно дать немного больше пояснений, поскольку разработчику будет полезно понять ваши намерения.
Обычно изменения должны быть отправлены в ту же ветку, но в другой коммит. Разные компании используют разные политики, когда дело доходит до слияния. Некоторые команды позволяют руководителям проектов объединяться, в то время как другие позволяют участникам объединяться после утверждения изменения.
Заключение
В конце концов, проверка кода может стать неотъемлемой частью культуры вашей организации. Обсуждения и обмен знаниями, которые происходят во время рецензирования, сделают вас лучшим программистом, независимо от того, проверяется ваш код или код кого-то другого. Сделайте проверку кода возможностью для новичков улучшить и адаптироваться к новой системе. Код-ревью — отличный способ улучшить свои способности, наставить своих джуниоров и развить эффективные коммуникативные навыки. Наконец, большинство современных организаций поддерживают инвестиции в легкие автоматизированные инструменты для оптимизации времени и эффективного измерения результатов. Проведите еще несколько исследований по обзору кода и новейшим процессам с помощью инструментов в отрасли, пообщайтесь с членами вашей команды и определите идеальное соответствие для вашей компании.
