Бонус: контрольный список проверки, чтобы ускорить и углубить процесс проверки.

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

Оглавление:

· Что такое Code Review?
· Чем не является проверка кода
· Этикет проверки кода
· Контрольный список проверки
· Последствия

Что такое проверка кода?

Проверка кода Pull Request (PR) — это процесс оценки и проверки работы разработчика его коллегами. Это важный шаг в жизненном цикле разработки программного обеспечения (SDLC), который в конечном итоге способствует общему успеху проекта за счет достижения следующих целей:

1. Улучшить качество работы

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

2. Применение лучших практик

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

3. Содействие обучению и сотрудничеству:

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

4. Смягчение непредвиденных проблем

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

Чем не является код-ревью

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

1. Тестирование разрабатываемой функции

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

2. Обзор того, что автоматические инструменты уже обнаруживают:

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

Если вы полагаетесь на своего рецензента, который скажет вам, когда ваши фигурные скобки находятся не на той строке […], вы тратите его время впустую. — Майкл Линч в Как влюбить в себя рецензента кода

Этикет проверки кода

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

1. Одобрение коллег:

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

2. Используйте «Запросить изменения» с осторожностью:

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

3. Вежливость и уважение:

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

Самый быстрый способ испортить код-ревью — принять отзыв лично. — Майкл Линч в Как влюбить в себя рецензента кода

3. Информированные предложения

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

4. Ограничения рецензента:

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

5. Обзоры кода вне GitHub:

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

Проверка контрольного списка

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

✅ Проблемы с производительностью

  • Поиск проблем с производительностью N+1.
  • Использовал ли разработчик #each вместо #find_each (или аналогичный)?
  • Пробелы в нумерации страниц?
  • Какие-то файлы считываются в память?
  • Ненужная загрузка данных и сериализация.

✅ Вопросы безопасности

  • Любое использование незащищенных конечных точек?
  • Поиск рисков SQL Injection в пользовательских запросах SQL.
  • Какие-либо данные просачиваются в незашифрованные столбцы и журналы?

✅ Использование лучших практик языка и фреймворка

  • Делаются ли они в SQL вместо ActiveRecord?
  • Насколько плохо используются отношения ActiveRecord?
  • Можно ли использовать #map вместо #each и наоборот?
  • Вы находите какие-либо жестко запрограммированные человеческие сообщения? Должны ли они быть охвачены системой перевода?

✅ Согласованность данных

  • Покрывается ли каждая проверка уникальными индексами?
  • Достаточно ли транзакций при изменении более 1 данных?

✅ Тесты

  • Достаточно ли тестового покрытия?
  • В модульных тестах тестирование выходит за рамки тестируемого метода/класса?
  • Соблюдаются ли рекомендации команды по тестированию?

✅ Именование и написание

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

✅ Линтер (например, Rubocop/Codeclimate)

  • Проверьте, не применяются ли предупреждения должным образом

✅ Правильная структура кода

✅ Является ли код читабельным и поддерживаемым

✅ Дизайн решения

✅ Продукт проверен на покрытие интеграционными тестами

последствия

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

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

Дополнительные материалы на PlainEnglish.io.

Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .