Проверка кода

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

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

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

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

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

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

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

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

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

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

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

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

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

// camelCase
// PascalCase
// snake_case
// kebab-case

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

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

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

var myVar = "I am a variable"

if strings.ContainsAny("a", myVar){
   return myVar
}

return nil

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

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

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

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

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

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

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