Проверка кода - обычная практика в технологической индустрии. Когда вы выполняете Pull Request / Merge Request, кто-то должен его просмотреть, дать отзыв и утвердить его, когда он будет готов стать частью главной ветки - если, конечно, это ветка, на которую направлен PR -

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

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

С таким мышлением давайте посмотрим, как это сделать:

Иметь контекст

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

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

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

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

Независимо от того, какой подход вы выберете, всегда помните об этих двух вопросах:

  • Как я могу это улучшить?
  • Что может пойти не так?

Проверка по удобочитаемости

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

У каждого кода, который вы пишете, есть цена: обслуживание. Сделайте другим одолжение и внимательно проверьте.

Вот некоторые из вещей, которые вы можете просмотреть:

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

Например, это происходит со стилями case:

Убедитесь, что весь код гармоничен и что фрагмент, который они собираются добавить, не шумит.

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

Если вы видите такой код:

Вы можете реорганизовать его, выполнив следующие действия:

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

Обзор по функциональности

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

  • Имеет ли смысл поток?
  • Есть ли необходимые проверки, циклы и т. Д.?
  • Единая ответственность за методы и классы. Так что тестирование может быть более атомарным.
  • Подвержен ли он сбоям? Например, убедитесь, что он проверяет длину массива перед доступом к нему. Или, по крайней мере, убедитесь, что это не приведет к ошибке -NullPointer alert-
  • Как бы я это сделал? Так по-моему лучше? Может ли эта логика улучшить нынешнюю?
  • Тесты не меняются без причины. Например, если тест использовался для проверки того, что функция не выдает ошибку, но затем проверяет, что функция выдает ошибку, спросите, почему. Возможно, будут внесены критические изменения, которые повлияют на работу.
  • Не удаляйте тесты без причины. Спросите, почему, если вы не понимаете, почему тест был удален. Разве это больше не нужно? Почему?
  • Тестов достаточно, чтобы оценить влияние изменения. А также проверьте, подтверждают ли тесты то, что они должны.

Что мне делать, если я не знаю языка кода?

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

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

Хорошей отправной точкой является поверхностный обзор: ищите опечатки и удачные названия переменных.

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

И самый важный совет: Не следуйте слепо «передовым методам». Всегда думай первым. Каждый фрагмент кода пытается повысить ценность продукта. Подумайте, как это может повысить ценность и облегчить жизнь разработчику, который будет поддерживать этот код позже, может быть, это вы.